A certificate that renewed on time, but was weak underneath
cert-manager considered this certificate perfectly healthy — it was renewing on schedule and had not expired. A deeper check available on paid plans looked inside the certificate itself and found the key was too weak to trust.
What happened
This is not a fix SreNix applies on its own. Read why on the right, then below.
- Detect: a deeper certificate check — part of the Enterprise catalog — reads the actual key and certificate chain behind every TLS Secret, not just whether cert-manager marked it healthy.
- Cause: this certificate used a 1024-bit RSA key. cert-manager does not check key strength; it only tracks whether a certificate is issued and current.
- Decision: replacing a certificate's key algorithm means editing the Certificate resource that a GitOps pipeline owns. That is outside the default closed list on purpose.
- Escalate: SreNix sent a signed, expiring approval link to the on-call security engineer, with the full diagnosis attached.
- Verify: once the stronger key was issued, the same check ran again and confirmed the new certificate met the required key strength.
Why this one waits for a person
Anything that touches certificate or key material beyond a straightforward reissue is deliberately kept out of the closed list. SreNix's job here is to find what nobody else was looking for, explain it clearly, and get it in front of the right person fast — not to make cryptographic decisions on its own.
A fix class only becomes automatic once it has a track record of working, in your environment, with a way to pull it back the moment it doesn't. That's true everywhere in SreNix, not just for certificates. Read how autonomy is earned.
On-call should be quieter every week
Helm install in 5 minutes. No telemetry exfiltration. No per-investigation surprises.