Automatic SSL and Let's Encrypt: A Certificate Renewal Guide

What is automatic SSL?

Automatic SSL is the issuance and renewal of a domain's TLS certificate without a human in the loop. Software proves to a certificate authority (CA) that it controls the domain, receives the certificate, installs it, and repeats the process before expiry. The standard that makes this possible is ACME (RFC 8555).

The name "SSL" stuck, but the protocol in use today is TLS. A certificate tells the browser two things: the server answering for this domain is the right one, and the connection is encrypted. When the certificate expires, browsers show a full-page warning and most visitors leave.

ACME, step by step

An ACME client first creates an account key with the CA. It then names the domains it wants and the CA issues a challenge. The client solves it (by publishing a file or writing a TXT record), the CA verifies, and the client sends a certificate signing request (CSR). The CA returns the signed certificate.

This only proves control of the domain (a DV certificate). It does not prove who your company is. The padlock in the browser therefore does not say "this site is trustworthy"; it says "the connection is encrypted and the domain is correct".

Why are certificates so short-lived?

Let's Encrypt certificates are valid for 90 days today. The project explains its reasoning in a published note: a leaked or mis-issued certificate stays dangerous for less time, and automation is encouraged. More detail sits in the FAQ.

The practical consequence: you cannot renew once a year from a calendar reminder. Renewal has to become a job that runs without anyone remembering it. The more certificates you hold, the more manual handling invites mistakes.

Monitoring is part of automation. Renewal can fail silently, so an alert that checks certificate expiry 20 to 30 days out catches the problem before a weekend outage. If you run many subdomains, remember that each may have its own certificate or its own renewal job.

HTTP-01 vs DNS-01

Before issuing, the CA asks for a challenge. Two methods are common.

A wildcard such as *.example.com can only be issued with DNS-01. DNS-01 does not require your server to be reachable, but it means a DNS API key lives in your automation. If that key leaks, an attacker can obtain certificates too. That is the trade-off between the two.

What breaks renewals?

Issuance often works the first time and breaks three months later. The usual causes:

• DNS no longer points here. The domain moved to another provider or a record changed. HTTP-01 expects the CA to resolve your domain to your server.
• Port 80 is closed. A firewall rule blocks the HTTP-01 request. "Only HTTPS should be open" quietly kills renewals.
• A CAA record. If your domain has CAA records that do not list Let's Encrypt, the CA refuses to issue (RFC 8659).
• A redirect loop. A rule that bounces HTTP to HTTPS and back to HTTP never reaches the token file.
• Rate limits. Many failed attempts for the same domain trigger throttling. The limits are listed on the official page; retrying in a loop while debugging makes things worse.

CAA record example

CAA states which CAs may issue for your domain. A record that allows only Let's Encrypt looks like this:

example.com.  IN  CAA  0 issue "letsencrypt.org"

With no CAA record, any CA may issue. With one, remember to include the CA you actually use.

HSTS and the origin certificate

HSTS (RFC 6797) uses the Strict-Transport-Security header to tell the browser to connect to this domain only over HTTPS for a given time. The security gain is real, but it is hard to undo: if your certificate breaks, the browser will not even let users click past the warning. Start with a short max-age and raise it once you have seen renewals work.

Behind a reverse proxy there are two separate connections: visitor to proxy, and proxy to origin. Using a valid certificate on the second one, and having the proxy verify it (some providers call this "full strict"), stops a man in the middle from slipping in. An origin with a self-signed certificate and verification turned off gives you an encrypted but unauthenticated line. For closing the origin itself, see origin IP hiding and origin lock. The architecture is explained in what is a reverse proxy.

DNS changes and certificate surprises

Plan the order when you move a domain to another provider. First make sure a certificate can be obtained at the new provider, then switch the DNS record and wait until the old record's TTL has passed. If you shut down the old system before switching, visitors have no valid certificate for a while. Write down the old record value so you can roll back.

Checklist

1. Does the domain's DNS resolve to the Nexren Shield address? Check with dig +short example.com.
2. If you have CAA records, is Let's Encrypt allowed?
3. Do redirect rules on the origin leave the HTTP-01 path alone?
4. Did you start HSTS with a short max-age?
5. Does the origin hold a valid certificate that the proxy verifies?

Sources

• RFC 8555: ACME
• RFC 8659: DNS CAA
• RFC 6797: HSTS
• Let's Encrypt FAQ
• Why 90-day lifetimes
• Let's Encrypt rate limits

Related product pages:Help center