Certificate Automation
Why certificate renewal automation fails when deployment is still manual
Issued is not installed. Installed is not served. A CA webhook that says renewed does not prove port 443.
sslcertificates.io Editorial · Published 2026-09-21 · Fact-checked 2026-09-21 · Topic window 2026-08-25
A certificate authority can return 200 and a PEM and you can still have an outage. The failure mode is consistent: the new leaf sits in object storage, a ticket, or a control-plane row, while port 443 still presents the previous fingerprint.
Issued ≠ installed ≠ served.
Manual deploy after automated issuance fails because:
- the person who can reload Nginx is not the person who saw the webhook;
- the panel API accepted a certificate object that the vhost does not reference;
- SNI still points at an old secret;
- rollback was “we still have the email.”
A working path is: write the files atomically, test configuration, reload, then open a TLS handshake from outside the host and compare SHA-256. sslcertificates.io records that fingerprint on supported SSH deploys and keeps a .prev copy. HTTP 200 from the panel is not that check.
If you do not connect a target, inventory will not invent a green verified state. That is deliberate.
Sources
Related
Automate the lifecycle this article describes
Inventory, renewals and verified deployment are product surfaces — not adjectives.