Automated SSL certificate renewal for Kubernetes

Your ingress serves whatever the TLS secret holds. CertKit keeps it current.

Kubernetes terminates TLS from a secret of type kubernetes.io/tls, referenced by name from your ingress. When the certificate renews, the secret keeps holding the old one until someone rebuilds it from the new cert and key. Every 47 days. In every namespace, in every cluster.

CertKit centralizes certificate issuance and renewal, then applies the renewed certificate to your TLS secrets via the CertKit Agent and kubectl. Ingresses and workloads that reference the secret pick up the change on their own.

Start free trial Watch demo

Built for Kubernetes

The pre-built Kubernetes TLS secret template ships in your CertKit account. No scripting required.

The CertKit Agent applies the renewed certificate and key to the TLS secret with kubectl, as a create-or-replace, so the same deployment works whether the secret exists yet or not. Ingress controllers watch their secrets, so the rollover happens without a restart, a redeploy, or a dropped connection.

The pre-built template ships with your CertKit account. Set the secret name and namespace once. CertKit handles every renewal after that.

How to install an SSL certificate on a Kubernetes ingress

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

Get the renewed certificate and key. As PEM files. A wildcard certificate covers every host rule in the ingress with one secret.
Create the TLS secret. kubectl create secret tls my-tls --cert=tls.crt --key=tls.key -n my-namespace. The certificate file needs the full chain, leaf first.
Reference it from the ingress. spec.tls with the covered hosts and the secretName. The ingress controller picks it up from there.
Replace the secret on every renewal. kubectl create secret tls fails with "already exists" the second time. The working pattern is create with --dry-run=client -o yaml piped to kubectl apply.
Repeat everywhere the certificate lives. Secrets are namespaced, so the same certificate gets duplicated into every namespace and every cluster that serves the domain. Each copy goes stale separately.

Every one of these steps is manual, and Kubernetes won't repeat any of them for you when the certificate renews. With lifetimes shrinking to 47 days, installation stops being an annual chore and becomes a recurring task: eight times a year, per secret, per namespace, per cluster. Miss one copy and that ingress serves an expired certificate while the others look fine.

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

How it works

 Your cluster              CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│  ┌─────────────┐  │     │                  │    │             │
│  │CertKit Agent│◄─┼─────┤  Issue & Renew   │◄──►│             │
│  └──────┬──────┘  │     │   Certificates   │    │             │
│         │ kubectl │     │                ┌───┐  └─────────────┘
│         ▼         │     └───────────┬────│DNS│
│ ┌──────────────┐  │                 │    └───┘
│ │ TLS secret   │  │                 │
│ │ [x] Applied  │  │                 │
│ │ Ingress      │  │ ◄───────────────┘
│ │ [x] Rolled   │  │       Verify
│ └──────────────┘  │
└───────────────────┘

CertKit manages issuance and renewal centrally using delegated DNS validation. You create a one-time CNAME record and CertKit handles every ACME challenge after that. The agent runs on a host with a kubectl context for the cluster and applies the secret from outside. Nothing runs inside the cluster, no controller to deploy, no CRDs to install, no in-cluster DNS credentials.

Using CertKit to manage our public-facing SSL certificates has been an excellent decision. The platform is user-friendly, certificates are easy to deploy, and the automation agent streamlines the entire certificate lifecycle, eliminating concerns around shortening certificate validity periods.

Chris Austin, IT Engineer, Buckman

What CertKit handles

Issue certificates via ACME, centrally. Your clusters have no ACME solvers, no challenge ingress rules, no DNS provider credentials stored in secrets. One CNAME record is all your domain contributes.
Renew automatically before expiry. That one-time CNAME covers every renewal challenge going forward. No intervention required in any cluster.
Apply the TLS secret idempotently. The agent applies the renewed cert and key as a create-or-replace, so the first deployment and the fiftieth renewal are the same operation.
Let the controller do the rollover. Ingress controllers watch their secrets and reload when the secret changes. No pod restarts, no redeploys, no dropped connections.
Stay inside your RBAC. The agent uses whatever kubectl context you give it. Scope it to managing secrets in the target namespace and that's the entire footprint.
Cover every copy of the certificate. The same renewed certificate can deploy to multiple secrets, namespaces, and clusters, plus the load balancers and servers outside Kubernetes that share it.
Verify the deployment, not just the script. After each renewal, CertKit connects to your ingress endpoint and confirms the new certificate is actually being served. It checks the serial number, SANs, and expiry. If something is wrong, you find out before your users do.
Alert on failure. Apply failures, verification mismatches, and upcoming expirations all generate alerts before they become incidents.
Audit every change. Every issuance, renewal, and deployment is logged with timestamp, certificate, and target. 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. Every renewal challenge after that is automatic.
Install the CertKit Agent. One command on a Linux host with a kubectl context for the cluster and permission to manage secrets in the target namespace.
Add the Kubernetes deployment script. The pre-built TLS secret template is in your account. Set the secret name and namespace. CertKit runs it on every renewal.

See the full architecture →

Why not cert-manager?

cert-manager is the standard in-cluster answer, and inside one cluster it's a good one. Its trade-offs show up at the edges: HTTP-01 solvers need the cluster reachable from the internet, DNS-01 means DNS provider credentials stored as cluster secrets, and each cluster becomes its own certificate silo with its own issuers to configure and its own controller to keep upgraded. Private clusters, and there are a lot of private clusters, can't answer HTTP-01 at all.

The bigger issue is that the cluster is rarely the whole estate. The same organizations run IIS, appliances, and load balancers that cert-manager will never touch. CertKit issues via delegated DNS validation and deploys the same renewed certificate to the TLS secret and to everything outside the cluster, from one account, with no ACME machinery to operate anywhere.

Kubernetes is just one part of your stack

Most infrastructures have more than one place where certificates live: the nginx and Apache servers that never made it into the cluster, self-hosted apps like GitLab, and certificates pushed to Azure Key Vault for cloud services. CertKit automates all of it from one account.

See all integrations

Start automating Kubernetes 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