Automated SSL certificate renewal for Sisense

Sisense serves HTTPS from a Kubernetes secret that won't renew itself. CertKit will.

A self-hosted Sisense install on Linux runs in Kubernetes. The installer reads the certificate and key from ssl_cer_path and ssl_key_path in its config file, builds a TLS secret from them, and the ingress controller serves that secret on port 443. A renewed certificate does nothing until someone replaces the files, rebuilds the secret, and checks that Sisense picked it up. Every 47 days.

CertKit issues and renews the certificate centrally, then the CertKit Agent on the Sisense node writes it to the installer's files and replaces the TLS secret with kubectl.

Start free trial Watch demo

Built for Sisense Beta

The pre-built Sisense template ships in your CertKit account, currently in beta.

On every renewal, the agent writes the certificate and key to the files your installer config points at, finds the TLS secret the Sisense Ingress or Gateway uses, and replaces it. Then it checks what port 443 presents. If the controller still serves the old certificate, the agent restarts the ingress-nginx pods and checks again.

The agent also reads your installer config and warns you when is_ssl, ssl_cer_path, or ssl_key_path would undo the renewal at the next upgrade.

How to install an SSL certificate on Sisense for Linux

The manual process, if you want to do it yourself:

Get the certificate and key as PEM files. Include the intermediate chain in the certificate file and keep the private key unencrypted. A wildcard certificate works if it covers the name users browse to.
Edit the installer config. In single_config.yaml or cluster_config.yaml, set update: true, is_ssl: true, ssl_cer_path and ssl_key_path to the new files, and application_dns_name to the certificate's common name.
Run the installer. From the installer directory, run ./sisense.sh single_config.yaml (or your cluster config). The installer rebuilds the TLS secret from the files in the config.
Or replace the secret between upgrades. Run kubectl create secret tls with --dry-run=client -o yaml and pipe it to kubectl apply. A mismatched pair fails with "tls: private key does not match public key".
Check what port 443 serves. Use openssl s_client with the Sisense host name. Older releases running ingress-nginx can keep the old certificate until the controller pods restart, which is when users see NET::ERR_CERT_DATE_INVALID or "x509: certificate has expired or is not yet valid".

Every one of these steps is manual, and Sisense won't repeat any of them when the certificate renews. With lifetimes shrinking to 47 days, that's twelve times a year, on every Sisense install. Miss one and every dashboard embedded in your product or intranet stops loading behind a certificate error.

At 47 days, automation is the only sustainable way to run Sisense certificates. Here's how CertKit does it.

From an operational perspective, CertKit is easy to deploy and manage. The ability to configure unique and specialized certificates is key to replacing our manual certificate processes.

Laura Thomas, Senior Central Systems Administrator, University of St. Thomas

How it works

 Your Sisense node         CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│                   │     │                  │    │             │
│     ┌───────────────┐   │  Issue & Renew   │◄──►│             │
│     │ CertKit Agent │◄──┤   Certificates   │    │             │
│     └─────────┬─┬───┘   │                ┌───┐  └─────────────┘
│               │ │ │     └───────────┬────│DNS│
│ PEM files   ◄─┘ │ │                 │    └───┘
│ [x] Written     │ │                 │
│                 │ │                 │
│ TLS secret    ◄─┘ │ ◄───────────────┘
│ [x] Replaced      │       Verify
└───────────────────┘

CertKit issues and renews certificates centrally using delegated DNS validation. You create a one-time CNAME record, and CertKit handles every ACME challenge after that.

The agent runs on the Sisense node, pulls each renewal over outbound HTTPS, and uses the kubeconfig the Sisense installer already set up. Nothing is deployed inside the cluster, and Sisense never runs ACME or holds DNS credentials.

Two generations of Sisense on Linux

Sisense changed how it serves HTTPS. The pre-built template handles both without any extra settings.

Older releases ingress-nginx serves the TLS secret as its default certificate Newer releases NGINX Gateway Fabric serves the secret named on the sisense-gateway Gateway

The secret can live in a different namespace on each release, so a hardcoded kubectl command that works on one install misses on the next. The agent finds the secret through the Sisense Ingress or Gateway, and falls back to a secret named sisense-tls in whichever namespace holds it.

What CertKit handles

Issue and renew centrally. The one-time CNAME covers every renewal challenge. The Sisense node needs no ACME client and no open port 80.
Write the files the installer reads. The certificate and key land at your ssl_cer_path and ssl_key_path, owned by the sisense user, so the next upgrade installs the current certificate.
Replace the TLS secret. The agent finds the secret automatically or uses the one you name, replaces it with kubectl, and skips the change when the secret already holds the certificate.
Verify what port 443 serves. The agent compares the served certificate's fingerprint to the new one. If the old certificate is still there after 30 seconds, it restarts the ingress-nginx controller pods with a short grace period and checks again before reporting success.
Catch installer config drift. Each run warns when the installer config has is_ssl off or points at different certificate files.
Alert on failure. Deployment failures, a certificate that won't serve, and upcoming expirations all generate alerts before they become incidents.
Audit every change. Every issuance, renewal, and deployment is logged. With certificate lifetimes heading to 47 days, that log is your compliance record.

Setup takes about ten minutes

Connect your domain. Add a one-time CNAME record to delegate DNS validation to CertKit.
Install the CertKit Agent. One command on the Sisense node where the installer set up kubectl. The agent needs no inbound firewall rules.
Add the Sisense deployment script. Choose the Sisense template and set the certificate and key destinations to the ssl_cer_path and ssl_key_path from your installer config. Secret discovery is automatic.

See the full architecture →

Sisense deployment requirements and troubleshooting →

Questions about the beta? Talk to the engineering team →

Why a kubectl one-liner doesn't stick

Replacing the TLS secret by hand gets the new certificate served today. It also leaves a trap. Every installer run, whether an upgrade, a reconfigure, or a restore, deletes the secret and rebuilds it from the files named in the installer config. If those files still hold last quarter's certificate, the upgrade quietly puts an expired certificate back in front of every dashboard.

CertKit writes each renewal to the same files the installer reads, then replaces the secret. The secret and the config agree after every renewal, so an upgrade installs the certificate you already have.

Sisense is just one part of your analytics stack

Most analytics and reporting stacks have more than one place where certificates live: other Kubernetes workloads in the same cluster, Elasticsearch clusters behind your search and log analytics, and SQL Server Reporting Services for paginated reports. CertKit automates all of it from one account.

See all integrations

Start automating Sisense certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing