Automate SSL Certificate Renewal: Certbot, acme.sh and AutoSSL

To automate SSL certificate renewal, use an ACME client (Certbot or acme.sh on a server you control, or AutoSSL on cPanel hosting) that renews on a schedule, answers the domain validation challenge by itself and reloads your web server afterwards. Then add an independent expiry check from outside, because renewals can fail silently.

Before you start, run your domain through our free SSL checker to see the certificate you are serving today, who issued it and when it expires. That tells you which section below applies to you.

Why renewal has to be automatic now

The CA/Browser Forum's Ballot SC-081v3 cut the maximum lifetime of publicly trusted TLS certificates in stages:

From 2029, domain validation can only be reused for 10 days, so the certificate authority (CA) will re-check domain control nearly every time it issues. Let's Encrypt is going further on its own timetable, moving to 45-day certificates by 2028. We cover the dates and reasons in detail in TLS certificate lifetimes are shrinking to 47 days, and what the first 200-day renewals look like in 200-day TLS certificates: first renewals. This post is about the plumbing.

How ACME renewal works

ACME (Automatic Certificate Management Environment, RFC 8555) is the protocol behind Let's Encrypt, ZeroSSL and a growing number of commercial CAs. A renewal has four steps:

1. Your client asks the CA for a certificate for one or more names.
2. The CA sets a challenge to prove you control each name.
3. Your client completes it, either by serving a file at http://example.com/.well-known/acme-challenge/ (HTTP-01) or by publishing a TXT record at _acme-challenge.example.com (DNS-01).
4. The CA issues the certificate, your client installs it, and your web server reloads.

Most silent failures happen at step 3 or step 4. Keep that in mind when you test.

Option 1: Certbot on your own server

Certbot is the EFF's ACME client and the most common choice on Ubuntu and Debian servers running Nginx or Apache.

Issue with the web server plugin

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

The --nginx (or --apache) plugin edits your server config, answers HTTP-01 and reloads the server for you on every renewal.

Confirm the schedule exists

Package installs add a systemd timer or a cron entry that runs certbot renew twice a day. It only renews certificates that are due, so running often is harmless.

systemctl list-timers | grep -i certbot
# or, on cron-based systems
grep -r certbot /etc/cron.d/ /etc/crontab

If nothing comes back, add a timer or cron job yourself. A server rebuilt from a backup or migrated by hand is the classic place where this gets lost.

Test the whole cycle

sudo certbot renew --dry-run

A dry run talks to the Let's Encrypt staging environment and exercises the challenge without touching your live certificate. Run it after any change to firewalls, redirects, CDN rules or DNS.

Make sure the server reloads

If you issued with --webroot or --standalone, Certbot doesn't know how to reload your server. Add a deploy hook, which runs only after a successful renewal:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Or drop an executable script into /etc/letsencrypt/renewal-hooks/deploy/ so it applies to every certificate.

Let the CA decide when to renew

Certbot 4.1 added support for ACME Renewal Information (ARI), standardised as RFC 9773. With ARI, certbot renew asks the CA when it should renew and may renew earlier than its own default. That matters as lifetimes shrink and if a CA ever needs to revoke and replace certificates in bulk. Check your version with certbot --version and upgrade if you're on an older distribution package; the snap package tracks current releases.

Option 2: acme.sh

acme.sh is a single shell script with no Python dependency. It's popular on minimal servers, routers and shared hosting with SSH access, and it supports DNS-01 with well over a hundred DNS provider APIs.

curl https://get.acme.sh | sh -s email=you@example.com

The installer adds a daily cron job. Two things catch people out:

The default CA is ZeroSSL, not Let's Encrypt. Since acme.sh v3.0, ZeroSSL is the default. Both are free. If you want Let's Encrypt, set it explicitly, and remember to allow whichever CA you use in your CAA record:

acme.sh --set-default-ca --server letsencrypt

Issuing is not installing. acme.sh keeps certificates in its own directory. Use --install-cert so renewals copy the files into place and reload your server:

export CF_Token="your-cloudflare-api-token"
acme.sh --issue --dns dns_cf -d example.com -d '*.example.com'
acme.sh --install-cert -d example.com \
  --key-file       /etc/nginx/ssl/example.key \
  --fullchain-file /etc/nginx/ssl/example.pem \
  --reloadcmd      "systemctl reload nginx"

acme.sh remembers the reload command and DNS credentials, so later renewals run unattended. If the DNS API token expires or is revoked, renewals start failing, which is a good reason to give it a long lifetime with minimal permissions (edit DNS on one zone only) and monitor expiry independently.

Option 3: cPanel AutoSSL

On most shared hosting with cPanel, you don't run an ACME client yourself. AutoSSL does it. According to cPanel's documentation, Let's Encrypt is the default provider, AutoSSL runs nightly as part of the system update script, and it can also be triggered on demand.

In cPanel, open SSL/TLS Status to see which domains are covered and click Run AutoSSL to force a check. AutoSSL validates over HTTP (or DNS if your nameservers are on the same server), so it most often fails because:

• The domain doesn't point to this server. A domain or subdomain whose A record points to Cloudflare's proxy, a CDN or an old host may fail HTTP validation, depending on how the proxy handles the challenge path.
• A redirect or security rule blocks the challenge. An .htaccess rule that redirects everything, or a security plugin that blocks unknown paths, can break /.well-known/. Exclude that path from the rule.
• A CAA record doesn't authorise the provider.
• Unused subdomains such as cpcontact. or webdisk. that don't resolve create warnings. These are usually harmless but make the report noisy.

AutoSSL emails the account owner about failures and warnings by default, though your host may change that. Make sure the cPanel contact address goes to a mailbox someone reads.

Option 4: let the platform do it

If your site sits on Cloudflare (proxied), Shopify, Squarespace, Wix, Webflow, Netlify, Vercel or a managed WordPress host, the edge certificate is issued and renewed for you. Two caveats:

• With Cloudflare's proxy, there are two certificates: the edge certificate visitors see (automatic) and the origin certificate on your server. If you use Full (strict) mode, the origin certificate must stay valid too. A free Cloudflare Origin CA certificate can last up to 15 years, which avoids the problem for that hop.
• Anything not behind the platform still needs its own certificate: a mail server, an admin panel on a separate subdomain, a staging site.

For a comparison of the free options, see how to get a free SSL certificate.

Monitoring expiry: trust, but verify

Automation fails quietly. A firewall change blocks port 80, a DNS API token expires, a CDN rule redirects the challenge path, or a server is migrated without its cron jobs. And since 4 June 2025, Let's Encrypt has stopped sending expiry reminder emails, so nobody will warn you.

Check the certificate each hostname actually serves, from outside your network. A file on disk can be renewed while the web server still serves the old one because it never reloaded.

A free cron check

#!/bin/sh
# Warn when a served certificate has fewer than 21 days left
for host in example.com www.example.com shop.example.com; do
  end=$(echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
        | openssl x509 -noout -enddate | cut -d= -f2)
  days=$(( ( $(date -d "$end" +%s) - $(date +%s) ) / 86400 ))
  [ "$days" -lt 21 ] && echo "$host: certificate expires in $days days" \
    | mail -s "TLS expiry warning: $host" you@example.com
done

Run it daily from a machine that isn't the web server. Pair it with a heartbeat monitor so you also know if the check itself stops running; our free website monitoring automation guide shows how.

Free tools that watch expiry for you

• Uptime Kuma (self-hosted) sends certificate expiry notifications for HTTPS monitors, by default at 21, 14 and 7 days before expiry.
• Hosted uptime services often include certificate expiry checks, though some reserve them for paid plans. Check the current plan details.
• Certificate Transparency monitoring. Every public certificate is logged. Searching crt.sh for your domain shows every certificate issued, which is handy for spotting forgotten subdomains and certificates you didn't request.

When to alert

Alert when a certificate has less than about a third of its lifetime left. Your ACME client should have renewed by then, so an alert means something is broken while there's still time to fix it. For 90-day certificates that's around 30 days; for 45-day certificates, around 15. A fixed "30 days" threshold will fire constantly on short-lived certificates, so set it per certificate type.

Our free audits and Website Monitoring re-scans (Starter plan and above) show the certificate's issuer and expiry date in the security results, but they don't send dedicated expiry alerts, so keep one of the checks above in place.

Troubleshooting a failed renewal

When a renewal does fail and visitors see warnings, common SSL certificate errors explains what each browser message means. After fixing it, re-run the SSL checker to confirm the new expiry date and full chain are being served on every hostname.

FAQ

Does Certbot renew certificates automatically?

Yes, if it was installed from a package or snap that set up its systemd timer or cron job. The job runs certbot renew twice daily and renews only certificates that are due. Confirm the timer exists and run certbot renew --dry-run to prove the whole process works.

How do I know if my certificate renewed?

Check the certificate your site serves, not the file on disk. Use an SSL checker or openssl s_client to read the expiry date from the live site, and decode the new certificate file with an SSL certificate decoder if you want to confirm what was issued. If the date hasn't moved after a renewal, your web server probably wasn't reloaded.

Why did AutoSSL not renew my certificate?

The most common reasons are a domain that points to a different server or proxy, a redirect or security rule blocking the validation path, or a CAA record that doesn't authorise the provider. Open SSL/TLS Status in cPanel to see the exact error for each domain, fix it, then click Run AutoSSL.

Should I use HTTP-01 or DNS-01 validation?

Use HTTP-01 for a simple single server with port 80 open, because it needs no DNS credentials. Use DNS-01 for wildcard certificates, servers that aren't reachable from the internet, or setups with several servers behind a load balancer. DNS-01 needs an API token, which should be scoped to the minimum permissions.

What happens if my certificate expires?

Browsers show a full-page warning and most visitors leave. If your site uses HSTS, visitors can't click past the warning at all. Search engine crawlers may also fail to fetch pages over HTTPS until the certificate is replaced.

Do shorter certificate lifetimes cost more?

Not if you use free ACME certificates from Let's Encrypt or ZeroSSL, or a platform that manages them. Paid certificates are sold as subscriptions, so you pay the same but reissue and reinstall more often. The real cost is the time spent on manual renewals, which is why automation matters.

Related reading

• Let's Encrypt 64-Day Certificates: Test Your Renewals Before February 2027: Let's Encrypt scheduled 64-day staging certificates from October 14, 2026, before they become the default on February 10, 2027. How to check your renewals.