The Cert Renewed. Was It Actually Deployed?
The cert renewed. Your automation says so. The new cert exists, with the right SANs, signed by the right CA, valid for the right window. Renewal succeeded.
Was it actually deployed?
At 47-day validity, that question matters more than ever. The gap between "issued" and "deployed to every edge, every container, every load balancer that needs it" is where most certificate outages now happen - because expiry is the failure mode teams plan for, and deployment is the failure mode that quietly defeats their planning.
Where deployment fails
A non-exhaustive tour of the failure modes:
The CDN didn't pull. Your cert lives in cert-manager or ACME automation. The new cert is in object storage. The CDN was supposed to pull it on next refresh. It didn't, because the pull job has been failing for two weeks with a permission error that's logged but not alerted on.
The kubernetes secret didn't sync. Cert-manager renewed the cert and updated the Secret object. The ingress controller is supposed to watch the secret and reload. The watch missed an event, or the reload silently failed, or three pods reloaded and the fourth didn't. Most traffic gets the new cert; a sliver gets the old one.
The load balancer config didn't reload. nginx, HAProxy, Envoy - all support cert reloading. All depend on the reload signal actually firing, on the reload completing without dropping connections, on the new config being valid. Any of those can quietly fail. The cert file on disk is new. The cert the load balancer is actually serving is old.
The legacy server didn't get the update. One of your 200 hosts is the one nobody touched during the migration to centralized cert management. It's still running its 2022 setup with a manually-installed cert. It renewed (or didn't) on a different schedule that's not in your central tracking.
The third-party endpoint wasn't updated. Your CDN serves the new cert. Your origin still serves the old cert. Some validation paths hit one, some hit the other.
The dependent service has the cert pinned. A client app pins the cert (or its key) for security reasons. The cert renewed; the pin didn't update. The app stops trusting the connection. This one isn't your fault, but you find out when your enterprise customer files a P1 ticket.
Why renewal automation hides deployment failures
Most cert automation reports success when the cert is issued, not when it's serving traffic. ACME clients log "renewed successfully" the moment the new cert is written to disk. The dashboard turns green. The metric is "renewal completed." The actual question - "is this cert what a customer's browser is currently receiving?" - is not what the automation answers.
Internal state checks compound this. A monitoring script that reads the cert file from disk on the same host that the renewal automation wrote it to will always say everything's fine. The check and the action use the same source of truth, which means the check can't catch deployment failures.
What "verified deployed" means
External probing. A request to the public hostname, performing a full TLS handshake, reading the certificate the server actually presented, comparing it to what was supposed to be deployed.
This is the only check that catches all of the failure modes above. It's also the check that requires running probes from outside your infrastructure - if the probe is inside your network, it might hit the same internal load balancer that has the new cert while customers are routing through an external CDN that has the old one.
The probe should run at multiple points in the deployment window: immediately after the renewal automation reports success (to catch deployment lag), again a few hours later (to catch propagation issues), and continuously through the cert's life (to catch reverts, drift, and unrelated deployments that overwrite the cert).
The shifting validity baseline makes this worse
At 398-day validity, you had a year for a deployment failure to surface and get fixed. At 200-day validity, you have six months. At 47-day validity, you have six weeks. The deployment-verification window has to compress to match.
At minimum, you need external verification within the same week as renewal. Otherwise the next renewal cycle starts before the previous one is confirmed to have actually deployed.
Verify that renewal actually deployed
TLS Radar runs external TLS probes against every certificate in your inventory, continuously. Catches the deployment failures that internal state checks miss: stale CDN copies, kubernetes secrets that didn't sync, load balancers that didn't reload, hosts that got skipped. Built to scale from a handful of sites to enterprise portfolios with API integration, SAML/SSO, and pricing that fits your certificate volume.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.