Automating SSL renewal with Let's Encrypt

A 90-day certificate sounds like more work than a one-year one, until you realise nobody is supposed to touch it. Short lifetimes exist precisely because the renewal is meant to be handled by software running on your server every few weeks. Getting automatic SSL renewal working properly, and then proving it actually runs, is a one-off task that removes an entire category of outage from your website. This article explains the mechanism, the choice between the two validation methods, and the reasons renewals fail in practice.

How the ACME process works

Let's Encrypt issues certificates through a protocol called ACME. Instead of a person emailing documents to a certificate authority, a client program on your server does the whole exchange.

1. The client asks Let's Encrypt for a certificate covering your hostnames.
2. Let's Encrypt replies with a challenge: prove you control these names.
3. The client satisfies the challenge, either by publishing a file on your web server or by creating a DNS record.
4. Let's Encrypt checks from the outside, from several network locations.
5. If the check passes, the certificate is issued and saved on your server.
6. The client reloads the web server so the new certificate is served.

Common clients include Certbot and acme.sh, while control panels such as cPanel and Plesk have their own built-in implementations. Most install a timer or cron entry that attempts renewal twice a day, doing nothing unless the certificate is within about 30 days of expiry. That window is deliberate: it gives you roughly a month of failed attempts before anything visible breaks.

HTTP challenge or DNS challenge?

The HTTP challenge

The client writes a token file under a well-known path on your site and Let's Encrypt fetches it over port 80. It is the simplest option and needs no credentials beyond access to the web root.

Use it when your site is publicly reachable on a normal server. Be aware that port 80 must stay open and reachable, that your redirect rules must not block the well-known path while forcing HTTPS, and that it cannot issue wildcard certificates.

The DNS challenge

The client creates a TXT record under _acme-challenge at your domain, which means it needs API access to your DNS provider. It is the only way to obtain a wildcard certificate covering all subdomains, and it works for servers that are not publicly reachable, such as internal or staging systems.

The trade-off is credentials: an API token for your DNS provider sits on the server, so scope it as narrowly as the provider allows. Some providers are slow to publish records, so the client may need to wait before validation succeeds.

For most small business sites on ordinary hosting, the HTTP challenge is the right default. Choose DNS when you need a wildcard or the server cannot be reached from the internet.

Why renewals fail

• Port 80 was closed after someone decided the site is HTTPS-only. The challenge cannot complete, though nothing appears wrong for weeks.
• A redirect rule catches the challenge path. A blanket redirect to the homepage means Let's Encrypt fetches a page instead of the token.
• The site moved to a new document root, so the client writes the token where nothing serves it.
• A hostname was removed from DNS but is still on the certificate. Validation fails for that name and the whole renewal fails with it.
• The renewal timer is not running. After a migration or a server rebuild, the cron entry or systemd timer often does not come across.
• The reload step is missing. The certificate renews on disk, but the web server keeps serving the old one until it is reloaded, so the site expires anyway.
• A CAA record was added that does not list Let's Encrypt, which blocks issuance entirely.
• Rate limits were hit after repeated failed attempts or repeated test runs against the live service.
• Behind a proxy or CDN, validation traffic may never reach the origin server, so the challenge times out.

Notice the pattern: nearly all of these are caused by a change made elsewhere, weeks earlier, for an unrelated reason.

Verifying that renewal really works

Do not wait for the expiry date to find out. Three checks cover almost everything.

1. Run a dry run. Most clients support a test renewal that performs the full exchange against a staging endpoint without issuing a real certificate or consuming rate limits. If the dry run succeeds, the mechanism is sound.
2. Confirm the timer exists. List the systemd timers or the crontab and check the renewal entry is present and enabled. After any server change, check again.
3. Read the live certificate. Connect to the site from outside and look at the validity dates, rather than trusting files on disk. The date a browser sees is the only one that matters.

Add a log line or heartbeat ping after each renewal attempt so a silent failure raises an alarm rather than accumulating for a month. Since the client only acts within the last 30 days of validity, alerting at 14 days still leaves time to intervene.

Practical points for Indian hosting setups

If your site sits behind a CDN with its own edge certificate, you still need a valid certificate on the origin server, and it renews separately. Check both.

On shared hosting, the panel usually manages everything and the correct action is to confirm the AutoSSL feature is enabled for every domain and subdomain, including addon domains added later. On a VPS you own the client, the timer and the reload hook, so these belong in your server documentation alongside the renewal command.

Also remember that mail servers and any API subdomain need certificates too, and their reload commands differ from the web server's.

Make renewal boring

Spend an hour doing three things: run a dry run, confirm the timer is enabled, and set an external expiry alert for every hostname. After that, certificates stop being something anyone thinks about. If you would rather not maintain the client and its hooks yourself, our team sets this up as standard on servers we manage, and you can see what is included on our VPS hosting plans.

Frequently asked questions

How often does a Let's Encrypt certificate renew?

Certificates are valid for 90 days and clients typically attempt renewal twice daily, acting only when about 30 days of validity remain. That leaves a generous window to fix failures.

Do I need a wildcard certificate?

Only if you have many subdomains or create them dynamically. A standard certificate can list several specific hostnames, which is simpler and avoids needing DNS API credentials on the server.

What happens if a renewal attempt fails once?

Nothing immediately, because the client retries. The danger is repeated failure going unnoticed, which is why the renewal attempt should write a log entry or send a notification either way.

Can I use Let's Encrypt on shared hosting?

Usually yes. Most Indian shared hosting panels include free certificates with automatic renewal; you just need to enable it for each domain and confirm afterwards that the live site presents the new certificate.