cert-manager
Valid. For somebody else.
A certificate answers one question on its own: is it good. The questions that matter are whether it is good for this host, who signed it, when it renews, and where the chain stopped when it did not. Four certificates from the repo's specimens, read live with cert-manager installed. Every row is a page; click through.
90 days · renews 30 days before the end · CA-issued
- Message
- Certificate is up to date and has not expired
- Not before
- 2026-09-05 04:25 UTC
- Not after
- 2026-12-04 04:25 UTC
- Renews
- 2026-11-04 04:25 UTC
- dnsNames
- shop.k8s-gui.test, www.shop.k8s-gui.test
- Private key
- ECDSA, never shown
Issued by
Issues into
Serving · the hosts this certificate is mounted for, and whether it names them
Made by, and makes
Covers, or does not
Good for this host?
Rubick checks every host an Ingress serves against the names the certificate carries, with the browser's rule: an exact name, or one label under a wildcard. Pick a certificate and a host.
certificate
shop-tls
the specimen above: Ready, 90 days, renews 30 days out.
- dnsNames
- shop.k8s-gui.test
- www.shop.k8s-gui.test
host on the Ingress
api.shop.k8s-gui.test
The certificate names shop.k8s-gui.test and www.shop.k8s-gui.test; api.shop.k8s-gui.test is neither.
The Secret is mounted, the dates are fine, every other screen draws it healthy, and the browser refuses the connection. Rubick's row says: mounted but not covering.
Matching a host is a statement about names, not about the connection: whether TLS actually terminates there is a separate check. The specimens need cert-manager installed, so they are not part of lies.yaml.