SSL certificate renewal checklist

Symptoms

The certificate is about to expire (the padlock warns, sometimes forty-five days out with paid certificates, sooner with the 90-day Let's Encrypt cycle), or it already expired and visitors see NET::ERR_CERT_DATE_INVALID / "your connection is not private" and cannot reach the site. Renewal surprises almost always come from a manual process falling out of sync: a certificate purchased for 2 years, a server move that left the original certificates behind, or a client that broke.

The cause chain

The certificate carries an notBefore and notAfter date. The browser rejects a certificate after notAfter. Renewal means getting the CA to issue a new certificate with a future date, replacing the old one on every server and CDN that hosts it, and confirming the new one is trusted before the old one passes out. When the old certificate is short-lived and no automation, the site goes down on the expiry date itself.

The checklist

1. Know your expiry far in advance

• Find the expiry in the browser: click the padlock, then "Certificate" or Security. The field is notAfter.
• Or command line: openssl s_client -connect example.com:443 -servername example.com -nameopt RFC2253 and read the Verification line.
• Put the expiry in a calendar 30 to 60 days before the date. For paid CA certificates this is when you can begin the renewal.

2. Confirm the full hostname list

• List exactly which hostnames the certificate must cover: apex, www, mail, subdomains. Every one must appear in the subject alternative names.
• Renew for the exact names you sell or serve. Adding a name without adding the SAN makes that host error.

3. Issue the renewal

• If Let's Encrypt with certbot: sudo certbot renew or the renewal timer you set. A valid config renews nothing because that's not due; run --force-renewal only when you really mean it.
• If the hosting panel: use the panel's own "renew certificate" field, because the panel re-issues and reboots the web server for you.
• If purchasing new, the CA reseller uploads the new certificate in the panel or email. Test that the certificate belongs to the same key pair: in Apache, openssl x509 -text -in new-cert.pem prints the public key and you can compare it against openssl rsa -in key.pem -pubout.

4. Replace on every shared surface

• If a CDN proxies the domain, upload the new certificate to the CDN zone, because the proxy terminates TLS and can hold the expired one.
• If the certificate protects only the site root, the same private key files sit on the web server, the mail server and any staging that needs it; upload each one.

5. Test before and after

• Before the switch-over: curl -vkI https://example.com in a maintenance window, then again after you replace the certificate.
• After: view in a clean or incognito browser each hostname you listed.
• Check the chain: openssl s_client -showcerts -connect example.com:443 prints a report of root, intermediate and leaf; if the intermediate is missing the browser rejects, even though the leaf is new.

6. Automate so it cannot recur

• Turn on the timer/cron and verify with a dry run.
• Add a monitor that tests the certificate date on a schedule and alerts your inbox, so a missed renewal cannot take the whole site down silently.

When to involve a professional

If renewal is manual and a month is already crossed, if the server, the proxy and the CDN all hold separate copies, or if a payment certificate came with a complicated private key exchange, a professional can renew it and fix the automation so this does not recur. This is one renewal task with several failure points; if you are unsure about any step, do not let the certificate run out.

The certificate types article explains the DV/OV/EV differences, and the free certificate article covers building the automation.