How Let's Encrypt Revolutionized Web Encryption

The web before free certificates

For most of the web’s history, HTTPS was something large companies and online shops used and everyone else skipped. Getting a certificate meant choosing a vendor, paying an annual fee, generating a certificate signing request by hand, waiting for validation emails, then installing files and remembering to repeat the process a year later. Each step was a reason to leave a site on plain HTTP.

Let’s Encrypt changed that. It is a certificate authority operated by the Internet Security Research Group (ISRG), a nonprofit, and began issuing publicly trusted certificates in 2015, leaving beta in 2016. Its model was simple: certificates are free, issuance is automated, and the whole process is built on an open protocol anyone can implement. Combined with browsers increasingly marking HTTP pages as “Not secure”, this helped make HTTPS the normal state of the web rather than the exception.

This guide explains how Let’s Encrypt works under the hood, how it differs from traditional certificate authorities, how automatic renewal is designed, and why shorter certificate lifetimes across the industry make that design more important.

What Let’s Encrypt does differently

Technically, a Let’s Encrypt certificate is a normal X.509 certificate trusted by mainstream browsers and operating systems. The encryption it enables is the same as with a paid certificate. The differences are in what it issues and how.

For most websites, a DV certificate is all that is needed: it proves the server is authorized for the domain and encrypts traffic. Organization and Extended Validation certificates add identity checks, but browsers no longer display them prominently. Our article on SSL trust levels covers those differences.

ACME: the protocol behind the automation

The core innovation is ACME, the Automatic Certificate Management Environment, standardized by the IETF as RFC 8555 in 2019. ACME defines how a client software on your server talks to a certificate authority to create an account, request a certificate, prove control of the domain and download the result, all without a human in the loop.

A simplified issuance flow looks like this:

1. The client creates an account with the CA, identified by an account key pair.
2. It submits an order listing the domain names it wants on the certificate.
3. The CA returns an authorization for each name, with one or more challenges the client can complete to prove control.
4. The client completes a challenge and tells the CA it is ready; the CA checks it from its own validation servers.
5. Once all names are validated, the client sends a certificate signing request and downloads the signed certificate.

Because ACME is an open standard, it is not limited to Let’s Encrypt. Other certificate authorities support it too, and there are clients for virtually every platform, from certbot and acme.sh to built-in support in web servers like Caddy and in hosting panels such as cPanel’s AutoSSL integrations.

Challenge types: HTTP-01, DNS-01 and TLS-ALPN-01

A challenge is how you prove you control a domain. Choosing the right one depends on your setup.

HTTP-01

The client places a token file at a specific path on your web server, and Let’s Encrypt fetches it over plain HTTP on port 80:

http://example.com/.well-known/acme-challenge/<token>

This is the easiest method for a single server with a public website. It requires port 80 to be reachable from the internet and cannot issue wildcard certificates. If you have several servers behind a load balancer, the token must be served by whichever one answers.

DNS-01

The client creates a TXT record under _acme-challenge for the domain, and the CA looks it up:

_acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"

DNS-01 is the only method that supports wildcard certificates such as *.example.com, and it works for servers that are not publicly reachable. The trade-off is that automation needs API access to your DNS provider, and those API credentials are sensitive: anyone holding them can change your DNS. Use scoped credentials where your provider supports them. See our guide to wildcard certificates for more.

TLS-ALPN-01

Validation happens inside a TLS handshake on port 443 using a special protocol identifier. It is mainly useful for tools and proxies that terminate TLS themselves and cannot serve files on port 80. Most site owners will use HTTP-01 or DNS-01.

Certbot and renewal architecture

Certbot, maintained by the Electronic Frontier Foundation, is the best-known ACME client. A typical first issuance on a server running Nginx looks like this:

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

For a wildcard using DNS-01, you would typically use a DNS plugin for your provider instead of the web server plugin. After issuance, certbot stores the configuration for each certificate and installs a scheduled job, usually a systemd timer or a cron entry depending on how it was packaged, that runs certbot renew regularly. That command only renews certificates that are close to expiry, by default when fewer than about 30 days remain, giving several weeks of retries if something fails.

Test the whole renewal path without issuing a real certificate:

sudo certbot renew --dry-run
systemctl list-timers | grep certbot

A renewed certificate is useless if the web server keeps serving the old one. Certbot’s web server plugins reload the server automatically; with other setups, add a deploy hook:

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

Where renewals fail in practice

• Port 80 closed by a firewall change, breaking HTTP-01.
• A redirect or CDN rule that stops the challenge path from reaching the server.
• DNS moved to a new provider without updating the DNS-01 credentials.
• A CAA record that does not authorize Let’s Encrypt; see configuring CAA records.
• The scheduled job disabled after a server migration, or rate limits hit by repeated failed attempts during testing (use the staging environment for experiments).

Newer ACME clients can also use ACME Renewal Information (ARI), which lets the CA suggest a renewal window, for example to encourage early renewal if certificates must be replaced. Check whether your client supports it.

The 90-day lifetime and the move to shorter certificates

Let’s Encrypt chose 90-day certificates from the start, when one- to multi-year certificates were common. The reasoning was twofold: a shorter lifetime limits the damage if a private key is compromised or a certificate is issued wrongly, and it forces automation, because nobody wants to renew by hand every few months. Automation, in turn, makes renewal reliable.

The rest of the industry has moved in the same direction. The CA/Browser Forum, the body of certificate authorities and browser makers that sets baseline rules for publicly trusted certificates, approved a ballot in 2025 that phases down the maximum lifetime of TLS certificates in steps, starting in 2026 and reaching 47 days by 2029, with domain validation reuse periods shrinking as well. Let’s Encrypt has also announced plans to shorten its own default lifetime over the coming years and offers optional very short-lived certificates. Exact dates and options can change, so follow the CA/Browser Forum and Let’s Encrypt announcements rather than relying on any single summary.

The practical lesson is the same whichever CA you use: manual certificate renewal is becoming unworkable. Every certificate should be renewed by software, and that software should be monitored.

Monitoring: trust automation, but verify

Automation fails silently more often than it fails loudly. Let’s Encrypt ended its expiration reminder emails in 2025, so you should not rely on the CA to warn you. Build your own safety net:

• Check the expiry date your server actually serves, not just what the client reports:

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

• Alert if any certificate has fewer days left than your renewal window should allow; with 90-day certificates renewed at 30 days, a certificate below about 20 days usually means renewal is broken.
• Monitor every hostname, including mail servers, APIs and subdomains that are easy to forget.
• Remember that the domain itself must stay registered: a valid certificate on an expired domain helps nobody.

TLDix can track both sides of that picture, sending alerts before SSL certificates and domain registrations expire from your domain panel. Once HTTPS is in place, consider adding HTTP Strict Transport Security so browsers always connect securely.

Why it counts as a revolution

Let’s Encrypt did not invent new cryptography. Its impact came from removing friction: no cost, no paperwork, and an open protocol that let hosting providers, panels and web servers make HTTPS automatic. That shifted the default for millions of sites and pushed the whole industry toward automated, short-lived certificates. For site owners, the job now is not buying certificates but keeping automation healthy and watching it closely.