SSL/TLS Certificate Renewal Checklist Template

Phase 1: Inventory, Ownership & CAA

The renewal method chosen on the first task decides whether the automated phase or the two manual phases appear.

• Open the record and choose the renewal method — Automated (ACME) or Manual, with the certificate owner and change approver picked from your members
• Search Certificate Transparency logs for every public certificate on your domains — crt.sh with %.example.com lists certificates for every subdomain, including ones nobody remembers ordering
• Scan your own address ranges for TLS services — port 443 and the rest: SMTP with STARTTLS, LDAPS on 636, VPN gateways and admin interfaces
• Add the places scans and CT logs miss — load balancers, CDNs, appliances, Java keystores, and internal CA certificates, which are never publicly logged
• Record each certificate in the certificate table — CN and SANs, where it is installed, expiry date, owner and renewal method
• Check CAA records allow the CA you renew with — public CAs have had to check CAA before issuing since September 2017, and a missing entry blocks issuance
• Flag certificates used for client authentication — new public TLS certificates no longer carry the clientAuth EKU, so mutual TLS needs a private CA or a dedicated client certificate

Phase 2: Automated Renewal (ACME)

Tasks appear only when the renewal method is Automated (ACME).

• Confirm the ACME client and version on each host — and that it supports ACME Renewal Information (RFC 9773), so the CA can tell it when to renew
• Renew on a fraction of the lifetime, not a fixed day count — Let’s Encrypt advises renewing with a third left; a hard-coded 30 days renews far too often on 45-day certificates
• Choose the challenge type for each name — HTTP-01 needs port 80 reachable, wildcards need DNS-01, and TLS-ALPN-01 works on port 443
• Limit what the DNS-01 credentials can change — a token scoped to one zone, or a CNAME that delegates _acme-challenge to a validation-only zone
• Make the deploy hook reload every service using the certificate — a renewed file on disk does nothing until the web server, proxy or mail server reloads
• Run a test renewal against the CA’s staging environment — certbot renew --dry-run or your client’s equivalent
• Alert on renewal failures, not just on expiry — Let’s Encrypt stopped sending expiry emails on 4 June 2025, so your own monitoring is the only warning

Phase 3: New Key, CSR & Validation

Tasks appear only when the renewal method is Manual.

• Generate a new private key for each renewal — RSA 2048-bit is the minimum public CAs accept; ECDSA P-256 is smaller and faster
• Build the CSR with every name in the SAN list — browsers ignore the Common Name, so a name missing from the SANs fails even if it is the CN
• Place the renewal order with the CA — and check the validity you will receive; since 15 March 2026 the maximum is 200 days
• Complete domain control validation — DNS TXT, HTTP file or email; earlier validation can be reused for 200 days now, 100 from March 2027 and 10 from March 2029
• Answer the CA’s organisation checks for OV and EV certificates — and allow for their lead time in the plan
• Download the certificate with its intermediate chain — in the format each platform needs, such as PEM or PFX
• Store the private key in your secrets vault — never in email, tickets or chat; record its location in the table

Phase 4: Approval & Install

Tasks appear only for manual renewals. The approval on the second task halts the checklist until the approver decides.

• Raise the change for the install window — listing every endpoint in the certificate table that carries this certificate
• Approve the install — the named approver records approved or not approved, with the reason
• Install on every endpoint in the table — servers, load balancers, CDN and appliances; a wildcard often lives in more places than expected
• Install the intermediate chain with the leaf certificate — browsers can work around a missing intermediate; API clients, mobile apps and older devices often cannot
• Convert formats where a platform needs it — PFX for Windows and IIS, PEM for most Linux services, a keystore for Java
• Reload each service and keep the old files until verification passes — they are your rollback

Phase 5: Verify Every Endpoint

If the verification result is recorded as Fail, the fix task appears and the run cannot close until it is done.

• Check each endpoint serves the new certificate and its chain — openssl s_client -connect host:443 -servername host -showcerts
• Confirm the new expiry date and the names covered — pipe the output into openssl x509 -noout -enddate and check every SAN
• Test from outside and inside the network — a load balancer and the server behind it can present different certificates
• Test the clients that matter, not only a browser — API partners, mobile apps, mail servers and anything that pins a certificate
• Record the verification result — pass, or fail with the endpoints still serving the old certificate or a broken chain
• Fix the failed endpoints and verify them again — until every row in the table shows the new expiry

Phase 6: Retire, Record & Next Review

• Remove the old certificate from every binding and keystore — an expired certificate left in place causes confusing failures later
• Revoke the old certificate only if its key was exposed — or the system using it is gone; a routine renewal does not need revocation
• Update expiry monitoring for each endpoint — alert while a third of the lifetime remains, so a failed renewal leaves time to act
• Update the certificate table — new expiry, location, owner and renewal method for every row
• List the certificates due in the next 60 days — the starting point for next month’s recurring expiry review
• Sign off and close — the owner confirms every endpoint passed, with the verification output attached