Renew TLS Certificates Before They Expire

Inventory every TLS endpoint, renew through ACME or your certificate authority, deploy the full chain, and verify dates and trust from outside before expiry.

intermediate~45 minsecuritytlsoperations

Objective

Renew and deploy TLS certificates for every public endpoint before expiry, with monitoring that catches a missed renewal weeks in advance.

Environment

A certificate inventory covering load balancers, CDN edges, API gateways and internal service meshes
Ownership of the ACME account or corporate certificate authority account for each domain
DNS or HTTP challenge access for every domain being renewed
A secret store for private keys and the previous certificate version
External monitoring that checks certificate expiry and chain validity

Steps

1. Inventory endpoints and certificates

Connect to every public hostname and record the subject, issuer, not-after date and chain, then match each certificate to an owner and renewal method.

Expected state: Every endpoint has a certificate record, an owner and a renewal method, with no unowned certificates.

2. Test the renewal path

Run the ACME client in dry-run or staging mode and confirm the DNS or HTTP challenge succeeds for every domain and wildcard in scope.

Expected state: The dry run completes without challenge failures and the new certificate chains to a trusted root.

3. Renew and stage the certificate

Request the new certificate, validate the full chain and key match, and upload it to the secret store alongside the current version.

Expected state: The staged certificate has the expected names, a validity period of at least sixty days and a matching private key.

4. Deploy and reload

Deploy the new certificate to every endpoint, reload the load balancer or proxy gracefully, and confirm no listener is serving the old certificate.

Expected state: All endpoints present the new serial number and existing connections drain without errors.

5. Verify from outside

Check the served chain, expiry date and hostname coverage from at least two external networks, and confirm OCSP or CRL checks succeed.

Expected state: External clients see a valid chain with the new expiry date and no certificate warnings.

6. Set expiry alerting

Configure alerts at thirty, fourteen and seven days before expiry and add the renewal task to the on-call calendar for the owning team.

Expected state: A synthetic check would page the owner before the certificate reaches the seven-day threshold.

Decision points

Should certificates come from ACME or a commercial authority?

ACME with automated renewal
Commercial CA with a longer validity and support contract

Use ACME for public web endpoints unless a contract, extended validation or an internal policy requires a commercial CA.

How should wildcard certificates be renewed?

DNS-01 challenge with an API credential
Per-host HTTP-01 challenges

Use DNS-01 for wildcards and for hosts behind a CDN; scope the API credential to the specific zone and rotate it with the certificate.

Expected outcome

Every endpoint serves a renewed, trusted certificate with a full chain, and expiry alerts give the owning team at least a week of warning.

Verification

Use openssl s_client against each hostname to confirm the subject, issuer, not-after date and chain, and compare the serial number with the certificate stored in the secret manager.

Cleanup

Keep the previous certificate and key for thirty days, revoke the superseded certificate only after the rollback window, and update the certificate inventory.

Inventory first, renew second

Certificate outages are almost always caused by an endpoint nobody remembered, not by a failed renewal. Enumerate hostnames from DNS zones, load balancer listeners, CDN custom domains and API gateway certificates, then connect to each one and record what it actually serves. A wildcard certificate on the load balancer does not cover a hostname that terminates TLS at a third-party service.

echo | openssl s_client -servername api.example.com \
  -connect api.example.com:443 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -serial

certbot renew --dry-run --cert-name api.example.com

Safety checks

Test the challenge path before the production request. DNS-01 credentials should be scoped to the zone and stored in the secret manager, never in a cron script. Validate that the new certificate includes every name the old one covered, that the private key matches, and that the intermediate chain is complete; a missing intermediate works in browsers that cache it and fails for API clients. Keep the previous certificate version for thirty days so a deploy can be reversed quickly.

Deploy and verify

Reload rather than restart where the load balancer supports a graceful reload, and watch for handshake errors during the change. Verify from outside your network, because internal checks may trust an internal CA or skip hostname validation. Compare the serial number served on port 443 with the serial number stored in the secret manager.

Rollback

Re-deploy the previous certificate and key from the secret store; this is fast and fully reversible while the old certificate is still valid. Revocation is the irreversible action: once revoked, the old certificate cannot be restored, so revoke only after the new certificate has served production for the full rollback window, and only immediately when the private key is compromised.