TLS Certificate Renewal: Endpoint and Expiry Checks

Inventory where certificates are actually served

Record each hostname and port, certificate issuer, subject alternative names, expiry, key location, termination component and responsible owner. A public website, API gateway, callback endpoint and internal service may use different certificates. A load balancer can terminate TLS while a separate certificate protects the connection behind it.

Include replicas and alternate routes. A successful browser check against one address may miss an old certificate served by another node. OWASP discusses correct domain names, trusted certificate authorities and private-key protection. Use those controls to review the real endpoint inventory; a padlock on a landing page does not describe every service connection.

Test renewal and alert delivery

Identify the renewal mechanism and its dependencies: domain or challenge access, DNS permissions, certificate-authority reachability, secret storage and deployment permissions. Test the supported renewal procedure safely before expiry. Record how a newly issued certificate reaches the process that serves traffic and whether a reload or restart is needed.

Monitor the certificate presented over the network, not just the expiry of a file in storage. Route alerts to an owned queue and test that someone receives them. Let's Encrypt states that its expiration email service has ended, so users of that issuer should not rely on the historical email reminder as their operational control.

Validate deployment and the recovery option

After renewal, check hostname coverage, validity dates, certificate chain and representative client trust. For mutual TLS, separately check server and client-certificate requirements. Keep private keys out of tickets and screenshots. A failed connection can result from an incomplete chain or trust-store mismatch even when the new certificate has a later expiry.

Record the previous working configuration and a permitted recovery path. Restoring an expired or revoked certificate is not a valid recovery plan. If a key may be compromised, treat revocation and replacement as a security process rather than routine renewal. Close the change only when all intended endpoints and relevant client types have been checked.

Example: issuance succeeds while one node remains stale

A fictional API has two TLS termination nodes. The renewal job issues certificate B, but the deployment hook reloads only node 1. A local file check passes; direct endpoint checks reveal that node 2 still presents certificate A. The team fixes the deployment step, checks both routes and adds served-certificate verification to future runs. This example makes no claim about a particular supplier's infrastructure.