Test SSL Auto-Renewal Before 100-Day Certificates Arrive

If your SSL certificate renews itself, test that renewal now, while you still have time to fix it calmly. Start by finding which tool renews your certificate, run a safe test renewal, check that your web server picks up the new certificate, and add a small alert that warns you before anything expires.

Here is why this matters right now. Certificate lifetimes are shrinking on a published schedule. At the time of writing (31 October 2026), the CA/Browser Forum Baseline Requirements, the rulebook that public certificate authorities follow, set the maximum lifetime of a public TLS certificate at 200 days for certificates issued from 15 March 2026. From 15 March 2027 that drops to 100 days, and from 15 March 2029 it drops to 47 days. Before this schedule started, the maximum was 398 days.

Shorter certificates mean more renewals, and less time between a silent failure and an expired site.

By the end of this guide you will know who renews your certificate, you will have tested that renewal works, and you will have a local expiry warning. Email delivery is only confirmed after you test the server’s mail path.

What SSL auto-renewal actually is

An SSL certificate (more correctly a TLS certificate) is a small file that proves your site is really example.com and lets browsers encrypt the connection. Every certificate has an expiry date. After that date, browsers show a full-page warning.

Auto-renewal is a scheduled job on your server that asks the certificate authority for a fresh certificate before the old one expires, then installs it. On cPanel hosting this job is usually AutoSSL. On a VPS (a virtual private server you manage yourself) it is often Certbot, a free tool from the EFF that talks to Let's Encrypt.

Think of it like a standing order at the pharmacy. The refill is supposed to happen on its own, but if the pharmacy changed its phone number or your address changed, nobody tells you until the day you open an empty bottle. Testing renewal is calling the pharmacy before you run out.

Why this matters: the job must run, the certificate authority must reach your server to check you own the domain, and your web server must reload to use the new file. Any of these can fail silently.

Before you start

• Access: SSH access with sudo for a VPS running Certbot, or a cPanel login for shared hosting.
• Tools: a terminal with openssl installed (it is on almost every Linux server and on macOS), and a normal web browser.
• Your domain list: every domain and subdomain that should have a valid certificate, including www.
• Backup: if you plan to add a hook script, back up /etc/letsencrypt first (step below shows how).
• Maintenance window: allow enough time to read any renewal error, test the hook and undo the change if the web server check fails.
• Risk: the dry run does not replace your live certificate, but hooks can reload services and a bad command can interrupt traffic. Work in a maintenance window and keep a second admin session open.

Step-by-step: test your renewal from start to finish

Step 1: Find out who issues and renews your certificate

This command connects to your site on port 443, asks for the certificate for example.com, and prints who issued it and when it expires:

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

You should see three lines: issuer= followed by the certificate authority name, then notBefore= and notAfter=. The notAfter line is the expiry date.

Per the OpenSSL manual, -servername sets SNI (Server Name Indication, the field that tells a shared server which site you want). The echo | sends empty input, so s_client reaches end of file, closes the connection and the command finishes.

In a browser, open the certificate details from the icon left of the address bar to see the same facts.

Now match what you see to your setup:

• If you use cPanel hosting, your certificate is most likely managed by AutoSSL. Go to Step 2A.
• If you run your own server and installed Certbot, go to Step 2B.
• If the issuer is your CDN or proxy provider, the certificate visitors see is managed there. Check that provider's dashboard, and also check the certificate on your origin server, which is a separate certificate.

Quick tip: if you sit behind Cloudflare, the certificate on your origin server still matters when you use Full (strict) mode. Our guide on Cloudflare SSL mode Full (strict) without redirect loops explains how the two certificates fit together.

Step 2A: Check AutoSSL in cPanel

1. Log in to cPanel.
2. Go to cPanel > Home > Security > SSL/TLS Status. On some versions this appears as a tab inside SSL/TLS Certificates.
3. Look at the Certificate Status column for each domain.

What you should see: each domain listed with its certificate state. According to the cPanel documentation, this column also shows the last time the system ran AutoSSL for that domain, and any AutoSSL error for the domain that exists in /var/cpanel/logs/autossl/.

Use the filters to find problems fast. The SSL status filter has Active, Expired, Expiring Soon, Unsecured and Has AutoSSL Problems. The AutoSSL status filter has All, Included and Excluded.

Check two things in particular:

• Select Has AutoSSL Problems. Any domain that shows up here will not renew until you fix the error shown next to it.
• Select Excluded. These are domains AutoSSL skips when it runs, so they will never renew on their own.

Heads up: on shared hosting the AutoSSL log folder sits on the server, outside your account. If an error makes no sense, send the full text to your host.

Step 2B: List the certificates Certbot manages

On a Certbot server, start with the version, because renewal timing changed in Certbot 4.0.0.

This command prints the installed Certbot version:

certbot --version

You should see the word certbot followed by a version number. Keep that number; it matters in the troubleshooting section.

Next, ask Certbot which certificates it knows about. This command lists each certificate's name, domains, expiry date and file paths:

sudo certbot certificates

You should see one block per certificate, with its name, the domains it covers, its expiry date and the paths to its files. Compare the domain list with the list you prepared. A domain that is live but missing here is not covered by any Certbot renewal.

Why the version matters: the Certbot documentation says that from version 4.0.0, a certificate is due for renewal when less than one third of its lifetime remains. Before 4.0.0 the threshold was a fixed 30 days. With a 100-day certificate, one third is about 33 days of warning time before expiry. With a 47-day certificate it is about 16 days.

Step 3: Run a safe test renewal

This is the core of the guide. A dry run goes through renewal against the Let's Encrypt staging server (a test system) without saving any new certificate. Your real certificate stays as it is.

This command tests renewal for every certificate Certbot manages:

sudo certbot renew --dry-run

You should see each certificate being tested, followed by a short summary of which simulated renewals succeeded and which failed. If anything fails, copy the full error text before you do anything else.

Two details from the Certbot documentation are worth knowing:

• The dry run may reload your web server, because it can temporarily change and then roll back configuration files.
• Pre hooks and post hooks run during a dry run, but deploy hooks do not, unless you add --run-deploy-hooks.

If you want to test only one certificate, add --cert-name with the name you saw in certbot certificates:

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

Made-up example: Priya runs a small shop on a VPS. Months ago a freelancer added a firewall rule that blocks port 80, and the site looked fine. Her dry run fails with a connection error. She opens port 80, runs it again, and it passes. Without the test, customers would have told her on expiry day.

Step 4: Confirm the renewal timer or cron job exists

A passing dry run proves renewal can work, not that anything will run it.

On Linux, the Certbot documentation says to look for certbot renew either in a systemd timer or in your system crontab. This command lists systemd timers whose name contains "certbot":

systemctl list-timers '*certbot*'

You should see a Certbot timer with the time of its next run. If no Certbot timer is listed, check cron instead.

This command searches the system crontab and the cron folders for a Certbot entry:

grep -r certbot /etc/crontab /etc/cron.*/ 2>/dev/null

You should see at least one line that runs certbot renew. If both checks come back empty, those locations did not reveal a renewal job. Check how Certbot was installed before adding another schedule, because a package or container may manage renewal elsewhere.

If you need to add a schedule, the Certbot documentation suggests a twice-daily cron entry with a random delay. This command adds that line to /etc/crontab:

SLEEPTIME=$(awk 'BEGIN{srand(); print int(rand()*(3600+1))}'); echo "0 0,12 * * * root sleep $SLEEPTIME && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

After running it, check the last line of the file with tail -n 1 /etc/crontab. You should see the new entry with a number in place of the sleep time.

Heads up: only add this if both checks above came back empty.

Step 5: Add a deploy hook so the web server reloads

This fixes the most confusing failure: renewal succeeds, but visitors still get the old certificate because the web server never reloaded.

A deploy hook is a command that, per the Certbot documentation, runs "once for each successfully issued certificate, including on subsequent renewals". Certbot runs any executable file in /etc/letsencrypt/renewal-hooks/deploy/ as a deploy hook, in alphabetical order.

First, take a backup of your Certbot folder. This creates a dated archive inside a root-only directory. The archive can contain certificate private keys, so keep it out of the web root and restrict it to root:

sudo install -d -m 700 /root/letsencrypt-backups
sudo tar -czf /root/letsencrypt-backups/letsencrypt-backup-$(date +%F).tar.gz /etc/letsencrypt
sudo chmod 600 /root/letsencrypt-backups/letsencrypt-backup-$(date +%F).tar.gz

Verify it with sudo ls -l /root/letsencrypt-backups/; the archive should show mode -rw-------.

Next, this command creates the hook script. It tests the Nginx configuration first and reloads only if that check passes. If you use Apache, use its own configuration test and service name instead:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-webserver.sh > /dev/null <<'EOF'
#!/bin/sh
nginx -t && systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-webserver.sh

Now test the hook along with renewal. This command runs a dry run and, only if the dry run succeeds, also runs your deploy hooks against your current real certificate:

sudo certbot renew --dry-run --run-deploy-hooks

You should see the dry run succeed with no hook errors. If the hook fails, Certbot prints the error and carries on, so read the output carefully.

Quick tip: you can also set --deploy-hook through certbot reconfigure --cert-name example.com; the documentation recommends adding --run-deploy-hooks when you do.

Step 6: Set up a simple expiry alert

You want a safety net that does not depend on the renewal tool. Once a day, read the live certificate on port 443 and use OpenSSL's -checkend option, which takes a number of seconds and exits non-zero if the certificate expires within that time.

Pick the window carefully: the alert must fire later than your normal renewal point, or you get an email every cycle. Certbot 4.0.0 and later renews with one third of the lifetime left. Let's Encrypt's own timeline says its default classic profile moves to 64-day certificates on 10 February 2027 and 45-day certificates on 16 February 2028. One third of 45 days is 15 days, so an alert at 10 days stays quiet when things work and still leaves you over a week to fix things.

This command creates the check script. Change DOMAIN to your own domain:

sudo tee /usr/local/bin/check-cert-expiry.sh > /dev/null <<'EOF'
#!/bin/sh
DOMAIN="example.com"
DAYS=10
LIMIT=$((DAYS * 86400))
if ! echo | openssl s_client -connect "$DOMAIN:443" -servername "$DOMAIN" 2>/dev/null | openssl x509 -noout -checkend "$LIMIT" > /dev/null 2>&1; then
  echo "Warning: the certificate for $DOMAIN expires within $DAYS days, or could not be read."
  echo | openssl s_client -connect "$DOMAIN:443" -servername "$DOMAIN" 2>/dev/null | openssl x509 -noout -enddate
fi
EOF
sudo chmod +x /usr/local/bin/check-cert-expiry.sh

The script prints nothing when the certificate has more than 10 days left. It prints a warning and the expiry date when it does not, or when the site cannot be reached at all.

You can test the warning branch by temporarily setting DAYS=400 in the script and running it. You should see the warning and a notAfter= line. Set it back to 10 afterwards.

Now schedule it. Cron mails any output a job produces to the owner of the crontab, or to the address in MAILTO if you set one. Because the script is silent when everything is fine, you only get an email when there is a problem.

This crontab block sends the output to your address and runs the check every day at 07:15. Add it with crontab -e:

MAILTO="you@example.com"
15 7 * * * /usr/local/bin/check-cert-expiry.sh

Heads up: cron can only email you if the server can send mail. On a fresh VPS that is often not set up, so test it once with DAYS=400 and confirm the email actually arrives.

On cPanel, open cPanel > Advanced > Cron Jobs, enter your address in the Email box of the Cron Email section and click Update Email. Then add a daily job that runs the same openssl commands. The cPanel documentation says this address gets notifications when your cron jobs run.

How to check it worked

• Run sudo certbot renew --dry-run again. Expected: every certificate reports a successful simulated renewal.
• Run systemctl list-timers '*certbot*' or check cron. Expected: a Certbot timer with a next run time, or a cron line that runs certbot renew.
• Run the openssl s_client command from Step 1. Expected: the notAfter= date matches the expiry date shown by sudo certbot certificates. If they differ, your web server is still serving an older certificate.
• In cPanel, filter SSL/TLS Status by Expiring Soon and Has AutoSSL Problems. Expected: no domains you care about appear in either list.
• Run /usr/local/bin/check-cert-expiry.sh by hand. Expected: no output at all, which means more than 10 days remain.
• Open your site in a private browser window and view the certificate details. Expected: no warning and a valid until date in the future.

Also make sure plain HTTP still reaches your site and then forwards to HTTPS. If you redirect with Apache, our guide on how to redirect HTTP to HTTPS using .htaccess shows a redirect that keeps working through renewals.

Troubleshooting

Dry run fails with a connection refused or timeout error

Symptom: certbot renew --dry-run fails for one or more domains, and the error mentions a connection problem or a timeout while contacting your domain.

Likely cause: the HTTP-01 check cannot reach your server on port 80. Let's Encrypt's documentation says the HTTP-01 challenge can only be done on port 80. A firewall rule, a security group at your cloud provider, or a changed DNS record pointing to the wrong server will break it. Redirects are followed, but only to port 80 or 443.

Fix: make sure ports 80 and 443 are open to the internet and that your domain's A and AAAA records point to the server running Certbot. If you use UFW, our guide on setting up a UFW firewall on an Ubuntu VPS without locking yourself out shows how to allow both ports safely. Then run the dry run again.

Renewal succeeded but the browser still shows the old certificate

Symptom: sudo certbot certificates shows a new expiry date, but the openssl s_client check and the browser still show the old notAfter date.

Likely cause: the web server was never reloaded, so it is still holding the old certificate in memory.

Fix: reload the web server now (for example sudo systemctl reload nginx), then add the deploy hook from Step 5 so it happens automatically next time. Check again with the Step 1 command.

A cPanel domain is excluded from AutoSSL

Symptom: in SSL/TLS Status, the domain appears when you filter by Excluded, and its certificate is moving towards Expiring Soon or already Expired.

Likely cause: someone excluded the domain, and AutoSSL skips excluded domains when it runs.

Fix: include the domain in AutoSSL again from the same screen if your cPanel offers that option, or ask your host to do it. Then watch the Certificate Status column for the next AutoSSL run time.

cPanel shows "Has AutoSSL Problems" for a domain

Symptom: the domain appears under the Has AutoSSL Problems filter, with an error in the Certificate Status column.

Likely cause: AutoSSL could not validate or issue a certificate for that domain. One common reason is that the domain's DNS no longer points to this hosting account. The error text tells you the specific cause.

Fix: read the error next to the domain. If the domain moved elsewhere, remove it from the account or point DNS back. If the message is unclear, send the full text to your host, since the details are logged in /var/cpanel/logs/autossl/ on the server.

Certbot is older than 4.0.0

Symptom: certbot --version shows a 3.x or 2.x release.

Likely cause: an old package from your Linux distribution, or a Certbot install that was never updated.

Fix: older versions renew at a fixed 30 days before expiry instead of one third of the lifetime. That still works, but the timing will not adapt as lifetimes change. Update Certbot using the same method you used to install it, then repeat Steps 2B and 3.

Pro tips and when to ask for help

• Put the expiry check on a different machine from the web server if you can. If the server is down, a check on the same server cannot email you.
• Let's Encrypt recommends ARI (ACME Renewal Information, a way for the certificate authority to tell your client when to renew). Check your client's documentation to see whether it supports it.
• Ask your host if you are on shared hosting and a domain keeps failing AutoSSL. Ask a developer if your site sits behind a load balancer or several servers share one certificate, because the reload step needs to reach every server.

The one message worth forwarding

Copy this to whoever looks after your server:

"Hi, certificate lifetimes are getting shorter: at the time of writing (31 October 2026) the maximum drops to 100 days from 15 March 2027 and to 47 days from 15 March 2029. Could you please run sudo certbot renew --dry-run --run-deploy-hooks (or check SSL/TLS Status in cPanel for AutoSSL problems and excluded domains), confirm a renewal timer or cron job exists, and set up a daily expiry check that emails us if any certificate has fewer than 10 days left? Thanks."

A renewal you have tested once and monitor daily is a renewal you can stop worrying about.