cert manager and certificates

cert-manager and certificates

Sextant shows cert-manager objects with their state explained in plain words, follows a certificate's issuance step by step, and shows the certificate inside any TLS Secret — with or without cert-manager — including when it expires.

Everything here is read-only. cert-manager objects have the usual Edit and Delete actions and nothing else: there is no Renew (cert-manager's renew changes the object's status, which Sextant does not write, and deleting the Secret would take the certificate away until a new one is issued).

Contents: The cert-manager section · Details and the issuance chain · The certificate in a TLS Secret · TLS certificates page · Expiry warning · Problems and notifications · Privacy: private keys

The cert-manager section

The cert-manager section appears in the sidebar only when the cluster serves cert-manager's kinds (installed after you connected? It shows up without reconnecting). Its header counts the certificates that need attention.

Entry	Columns
Certificates	Name, namespace, Ready (with its reason), Secret, issuer, expires (days left, coloured by the expiry warning), status, age
Certificate Requests	Name, namespace, approval (Approved / Denied / Waiting), Ready, reason, certificate, issuer, status, age
Issuers, Cluster Issuers	Name, namespace (Issuers), Ready, type (ACME, CA, Self-signed, Vault, Venafi), reason, status, age
Orders	Name, namespace, ACME state, certificate request, reason, age
Challenges	Name, namespace, ACME state, domain, type (HTTP-01, DNS-01), reason, age

Tick Only problems above a table to keep only the objects in trouble.

Details and the issuance chain

• Certificate: what is going on in plain words ("The Secret shop-tls does not exist yet: cert-manager has not issued this certificate", "Issuing failed…", "A new certificate (revision 4) is being issued"), links to the Secret and the issuer, the names asked for, validity with the days left, renewal time, private key settings, revision, and the last failure with the number of failed attempts.
• Certificate Request: approval and readiness in plain words ("Waiting for approval: an approver has not approved the request yet"), its Certificate and issuer.
• Issuer / Cluster Issuer: type, readiness, the ACME server, email and account, or the CA Secret.
• Order / Challenge: ACME state and reason explained, the domain and the solver.

The Issuance chain in the details of a Certificate, Certificate Request, Order or Challenge shows Certificate → Certificate Request → Order → Challenge, newest request first, so you can see at which step an issuance stopped.

The certificate in a TLS Secret

The details of any TLS Secret (type kubernetes.io/tls, or any Secret with a tls.crt key) have a Certificate section, also when cert-manager is not installed:

• Subject, Issued by, DNS names, IP addresses, URIs, Email addresses;
• Not before, Not after with the days left, coloured by the expiry warning;
• Public key (type and size), Signature, Serial number, SHA-256 fingerprint, CA certificate, Self-signed;
• the Chain in tls.crt (the leaf first, then intermediates) and the CA (ca.crt) when the Secret has one;
• a link to the cert-manager Certificate that issued it, when there is one.

Sextant shows what the certificate says; it does not check signatures or whether a client would trust it. The section is read again when the Secret changes.

TLS certificates page

Config → TLS Certificates lists the TLS Secrets of the namespaces in the namespace filter, the soonest to expire first: name, namespace, names, issuer, not after, and how long until it expires. Secrets whose tls.crt cannot be read are marked Unreadable. The total at the top counts the expiring, expired and unreadable ones.

The list is read when the page opens, when you change the namespace filter, and when you press Refresh — never in the background (see Privacy). If you may not list Secrets in all namespaces, choose namespaces in the filter; namespaces you may not read are named. At most 1000 Secrets of 200 namespaces are read.

Expiry warning

Warn this many days before a certificate expires (default 14, from 1 to 365) decides when a certificate counts as expiring, everywhere: cert-manager Certificates on the Problems and notifications screen and in notifications, the Certificates table and details, the Certificate section of TLS Secrets and the TLS certificates page. Set it in Settings → General → Notifications or right on the TLS certificates page.

Problems and notifications

cert-manager Certificates that are not ready (not while being issued), whose issuance failed, that expire within the warning, or that expired are problems and can notify you (category Certificates).

TLS Secrets without cert-manager are not watched for expiry in the background, so they never notify: see them in their details or on the TLS certificates page.

Privacy: private keys

Kubernetes cannot send only part of a Secret: reading tls.crt means receiving the whole Secret, private key included. So the reading happens in Sextant's backend, never in the window:

• only tls.crt and ca.crt are parsed;
• the private key, every other value and the annotations are overwritten in memory as soon as the Secret arrives, and the certificates after they are parsed;
• only the certificates' fields (names, dates, issuer, fingerprint…) reach the window; nothing of a key is shown, logged or kept;
• the Secret is read with your own credentials: if you may not read it, the section says so.

This is also why Sextant does not scan TLS Secrets in the background: it would read every private key of every connected cluster on a timer. The certificate views are not available to AI agents or extensions. An agent sees cert-manager Certificate problems through get_problems, and the TLS step of diagnose_service only with Secret values on Secrets of that namespace (see Diagnostic tools).

Next: Problems and notifications, Settings.