How to renew an SSL certificate, and make sure the renewal worked

A certificate cannot be extended. "Renewal" is the issue of a new certificate, with new validity dates and a new serial number, for the same hostnames. The CA checks again that you control each domain, and you then install the new certificate in place of the old one.

Public certificates issued since March 15, 2026 last at most 200 days, falling to 100 days in 2027 and 47 days in 2029. Renewal is no longer a yearly task; plan for it to be automatic.

1. Generate a new private key and CSR on the server or in your hosting panel. Reusing the old key works, but a new key limits the damage if the old one ever leaked.
2. Submit the CSR to your CA and complete domain validation by DNS record, HTTP file or email, as the CA asks.
3. Download the certificate with its chain. Use the full-chain bundle, not only the leaf certificate, or some clients will reject it.
4. Install it everywhere the hostname is served: each web server, load balancer, CDN, mail server and any appliance with its own copy.
5. Reload or restart the service so it picks up the new files.
6. Check from outside that the new certificate is the one served (see below).

ACME is the protocol Let's Encrypt created and most CAs now support. A client on your server, or your hosting platform, requests and validates certificates on a schedule without anyone involved. Let's Encrypt certificates last 90 days, and clients usually renew them with about 30 days left.

With certbot, test that renewal will work without waiting for it:

sudo certbot renew --dry-run

systemctl list-timers | grep certbot

• Validation breaks. An HTTP-01 challenge is blocked by a redirect, firewall or CDN rule; a DNS-01 challenge uses an API token that expired or was rotated.
• The schedule is gone. The server was rebuilt or migrated and the cron job or timer did not come with it.
• The new certificate is never deployed. The client renewed the files, but the web server was not reloaded, or a load balancer still holds its own copy of the old certificate.
• A CAA record blocks the CA. After a change of CA, the domain's CAA record still allows only the old one. Check it with the CAA checker.
• Nobody reads the warning emails. They go to a former employee's address, and Let's Encrypt stopped sending expiry emails in 2025.

In every case the old certificate keeps working until its last day, so nothing looks wrong. A fixed "30 days before expiry" reminder does not help either: on short-lived certificates it fires on every cycle, so people stop reading it.

Check the certificate the server actually presents, not the file on disk. Enter the hostname in the SSL checker and confirm the expiry date and serial number changed, or use the bulk SSL expiry checker for up to 20 hosts. From a terminal:

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

Visitors see "Your connection is not private" with the code NET::ERR_CERT_DATE_INVALID, API clients fail, and sites using HSTS cannot be opened at all. Issue a new certificate straight away; with ACME this takes a minute once validation works. The guide to the "Your connection is not private" error covers the other causes of the same warning.