How to Renew an SSL Certificate and Automate It for Good

Renewing a certificate by hand once a year worked when that was the rule. It is a liability now, because validity periods are getting shorter and a forgotten renewal takes your site down. This guide shows you how to set up renewal that runs unattended, how to prove it works before it matters, and how to get alerted if it ever stops.

The certificate lifecycle in plain terms

A certificate goes through the same stages regardless of who issues it:

1. Key generation. A private key is created on your server. It never leaves it.
2. Request. You send a certificate signing request (CSR), containing the public key and the names you want covered.
3. Validation. The CA verifies that you control the domain: by serving a file over HTTP (HTTP-01), by publishing a DNS record (DNS-01), or in other ways depending on the CA and certificate type.
4. Issuance. The CA signs and returns the certificate and intermediates.
5. Installation. You place the full chain and key where the web server can read them, then reload it.
6. Renewal. Before expiry, steps 2 to 5 repeat. Many tools reuse or rotate the key on renewal; rotating is the better default.

Automation covers steps 2 to 5. The part people forget is step 5's last half: the reload. A renewed file that the running process never reloads is still an expired certificate to your visitors.

Public certificate lifetimes have been trending shorter across the industry, driven by browser and CA policy. Free ACME-based CAs such as Let's Encrypt already issue 90-day certificates, and the direction for all publicly trusted certificates is further shortening. The practical consequence is simple: any process that depends on a person remembering a date will eventually fail, so treat automation as a requirement, not an optimization.

Option 1: certbot with Let's Encrypt

Certbot is the reference ACME client from the EFF. On Debian and Ubuntu, the maintainers recommend the snap package; distribution packages also exist but can be older.

Webroot or plugin issuance

If you want certbot to edit your nginx or Apache configuration for you:

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot --apache -d example.com -d www.example.com

If you prefer to manage the web server configuration yourself, use the webroot method. It requires that /.well-known/acme-challenge/ is reachable over port 80 for each name:

sudo certbot certonly --webroot -w /var/www/example -d example.com -d www.example.com

Certbot stores material under /etc/letsencrypt/live/example.com/. Point your server at fullchain.pem and privkey.pem there. Never copy files out of live/; they are symlinks into archive/ that certbot updates on renewal.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

How renewal is scheduled

Packaged certbot installs a systemd timer (or a cron entry on older systems) that runs twice daily. Each run only acts on certificates within roughly 30 days of expiry, so frequent runs are normal and harmless. Verify that a timer exists:

systemctl list-timers | grep -i certbot

Reload hooks

Certbot renews files, but your server must pick them up. Use a deploy hook, which runs only after a certificate was actually renewed:

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

A more durable approach is to drop a script into the hooks directory so it applies to every certificate:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh >/dev/null <<'EOF'
#!/bin/sh
systemctl reload nginx
# systemctl reload apache2   # use this line instead on Apache
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh

Prefer reload over restart: it applies new certificates without dropping connections. Run nginx -t or apachectl configtest in the script if you want to guard against reloading a broken configuration.

Test before you trust it

sudo certbot renew --dry-run

This performs the full renewal flow against Let's Encrypt's staging environment without replacing your real certificates. Run it right after setup, and again after any change to your firewall, web server, DNS or proxy. If the dry run fails, the real renewal will fail too, usually when it is least convenient.

Common dry-run failures:

• Port 80 blocked, or an HTTP-to-HTTPS redirect that breaks the challenge path (a plain 301 to HTTPS is normally fine for HTTP-01; redirects to another host or an authentication wall are not).
• A CDN or WAF intercepting /.well-known/acme-challenge/.
• DNS for one of the listed names no longer pointing at this server.
• Rate limits when you test repeatedly against production; use --dry-run or --staging to avoid them.

Option 2: Caddy, where renewal is built in

Caddy obtains and renews certificates automatically for any site you define with a real hostname, with no extra configuration. A minimal Caddyfile:

example.com, www.example.com {
    root * /var/www/example
    file_server
}

Caddy needs ports 80 and 443 reachable, a persistent data directory so it keeps its account and certificates between restarts, and DNS already pointing at the server. It renews well before expiry and applies the new certificate in memory, so no reload hook is needed. For many teams this removes the entire class of problem, at the cost of switching web servers.

Option 3: acme.sh for lightweight or unusual setups

acme.sh is a shell-script ACME client that has no dependencies beyond standard tools and supports a wide range of DNS providers. Issue and install:

acme.sh --issue -d example.com -d www.example.com -w /var/www/example

acme.sh --install-cert -d example.com \
  --key-file       /etc/ssl/example/privkey.pem \
  --fullchain-file /etc/ssl/example/fullchain.pem \
  --reloadcmd      "systemctl reload nginx"

The --install-cert step is important: it records where to copy files and which command to run after every renewal, and acme.sh installs its own cron job to renew. Check the default CA configured in your version, since acme.sh has changed its default over time; pass --server letsencrypt if you want to be explicit.

Wildcards and DNS-01

A wildcard such as *.example.com can only be issued with DNS-01 validation, because you must prove control of the zone by publishing a TXT record at _acme-challenge.example.com. To automate it, your DNS provider needs an API your client can call. With certbot and Cloudflare, for example:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

# /root/.secrets/cloudflare.ini  (chmod 600)
dns_cloudflare_api_token = REPLACE_WITH_SCOPED_TOKEN

Notes that save pain:

• The wildcard does not cover the bare domain, which is why both names are listed.
• Create an API token limited to editing DNS for that one zone, not a global key, and keep the file at mode 600.
• DNS-01 does not require inbound ports, so it also suits servers behind firewalls and internal hosts with public names.
• If your DNS host has no API, you can delegate the _acme-challenge name through a CNAME to a zone that does.

Shared hosting, cPanel and AutoSSL

On cPanel, AutoSSL issues and renews certificates for domains on the account without any command line work. It runs on a schedule, and it only succeeds for domains that actually resolve to that server. Common causes of AutoSSL failures are DNS pointing elsewhere (for example, to a CDN proxy), a .htaccess rule that blocks the challenge path, or an account hitting the provider's issuance limits. Check the AutoSSL log in WHM or ask your host if the certificate in cPanel and the certificate served on the web disagree.

Commercial CA certificates

Extended validation, organization-validated or specific-vendor certificates are still bought from commercial CAs, usually because of compliance needs, warranties, or because a particular device requires a particular issuer. Many commercial CAs now support ACME, which lets you automate them with the same tools above. If yours does not, build the process around a calendar and a monitor:

1. Start renewal at least 30 days before expiry; domain or organization validation can take days.
2. Generate a new key and CSR each time: openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr -subj "/CN=example.com" (add SANs through a config file or the CA's form).
3. Install the leaf plus the CA's current intermediates as a single chain file.
4. Reload, then verify with an external check.

Verification and monitoring

Automation fails silently if nobody looks. Layer these checks:

• Immediately after every change: run curl -vI https://example.com or use the SSL Checker to confirm the new expiry date and a complete chain. The SSL Chain Debugger is useful when the leaf is right but intermediates are wrong.
• Continuously: external expiry monitoring with alerts at several thresholds. An uptime monitor that checks certificate dates catches the case where renewal ran but the server never reloaded, which an internal file check cannot see.
• At scale: use the Bulk SSL Checker to list every domain and its days remaining, then work from the soonest.
• The domain itself: a lapsed domain registration makes certificate renewal impossible, so pair certificate watching with domain expiry watch.

A simple local sanity check you can put in a scheduled job:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -checkend $((21*24*3600)) \
  || echo "Certificate expires within 21 days"

-checkend exits non-zero if the certificate will expire within the given number of seconds. Run it from a different network than the server.

Troubleshooting a failed renewal

Start with the logs: /var/log/letsencrypt/letsencrypt.log for certbot, and journalctl -u certbot if it runs under systemd. Then look at the cause category:

• Challenge failed: the validation request could not reach your server. Check DNS, firewall, and redirects.
• Authorization expired or rate limited: wait, then retry; avoid retry loops.
• Hook failed: your reload command errored. Run it by hand.
• Plugin missing after an upgrade: reinstall the DNS plugin matching your certbot version.
• Certificate renewed but old one served: the process was not reloaded, or another layer holds a copy. See SSL/TLS certificate errors explained.

अगले कदम

• Check your current certificate with the SSL Checker
• Inspect the chain with the SSL Chain Debugger
• Track many domains in the Bulk SSL Checker
• Get alerts through the अपटाइम मॉनिटर
• Watch registration dates with डोमेन एक्सपायरी वॉच
• Read HTTP security headers to harden HTTPS after renewal is reliable

सामान्य प्रश्न

How often does certbot renew certificates?

The scheduled job runs twice a day but only renews certificates that are within about 30 days of expiry. For a 90-day Let's Encrypt certificate this means renewal around day 60, leaving a comfortable window to fix problems before it expires.

Do I need to restart the web server after renewal?

You need the server to load the new files, which usually means a reload rather than a restart. Add a deploy hook so it happens automatically. Caddy does this internally, so no hook is needed there.

Can I get a wildcard certificate from Let's Encrypt?

Yes, using DNS-01 validation. Your DNS provider needs an API that your ACME client can use to create the TXT record, or you can delegate the challenge name to a zone that has one.

Why did renewal work for months and then stop?

Typically something around the server changed: a firewall rule, a new redirect, a DNS move to a CDN, a certbot upgrade that dropped a plugin, or a changed API token. Running certbot renew --dry-run after infrastructure changes catches these early.

What happens if I let a certificate expire?

Browsers show a full-page warning and many visitors will leave; API clients and webhooks fail outright. Renewal then fixes it, but only after you notice. That delay is why external expiry monitoring matters.

Is a shorter certificate lifetime worse for me?

Not if renewal is automated; it limits the damage window of a leaked key and is the direction the ecosystem is moving. It only hurts when renewal depends on manual steps, which is a reason to automate now.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.