Not long ago, putting a website on HTTPS meant buying a certificate, generating a signing request by hand, and remembering to renew every year. Let's Encrypt changed that. It is a free, automated certificate authority run by the nonprofit Internet Security Research Group (ISRG), and its certificates are trusted by all major browsers and operating systems. For most websites, it is now the default choice.
What Let's Encrypt gives you (and what it does not)
Let's Encrypt issues Domain Validated (DV) certificates. They prove that you control a domain and enable exactly the same TLS encryption as a paid certificate. You can get:
- Single-name and multi-name certificates (one certificate covering several hostnames).
- Wildcard certificates such as
*.example.com, if you can prove control through DNS.
What it does not offer:
- Organization Validated (OV) or Extended Validation (EV) certificates, which include your company's verified legal name.
- Long lifetimes. Certificates are valid for 90 days, and Let's Encrypt has announced plans to shorten that further. This is intentional: short lifetimes limit damage from a compromised key and push everyone towards automation.
- A warranty or phone support. Help comes from documentation and a community forum.
How it works: the ACME protocol
Let's Encrypt is built around ACME (Automatic Certificate Management Environment), an open protocol published as RFC 8555. Software on your server, called an ACME client, talks to Let's Encrypt and handles everything: creating a key, proving domain control, downloading the certificate, and renewing it later.
Domain control is proven through a challenge. The three main types are:
| Challenge | How you prove control | Best for |
|---|---|---|
| HTTP-01 | Serve a token file at http://yourdomain/.well-known/acme-challenge/ on port 80 | Ordinary web servers reachable from the internet |
| DNS-01 | Create a TXT record at _acme-challenge.yourdomain | Wildcards, internal servers, servers without port 80 open |
| TLS-ALPN-01 | Answer a special TLS handshake on port 443 | Specialized setups and some reverse proxies |
Wildcard certificates can only be issued with DNS-01. If you automate DNS-01, your ACME client needs API access to your DNS provider, so store those credentials carefully.
Getting a certificate with Certbot
Certbot, maintained by the Electronic Frontier Foundation, is the most widely documented ACME client. On a typical Ubuntu server running Nginx, the process looks like this (installation methods vary by distribution; the Certbot website gives exact instructions for yours):
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.comCertbot proves control with HTTP-01, obtains the certificate, edits your Nginx configuration to use it, and can add an HTTP-to-HTTPS redirect. Files are stored under /etc/letsencrypt/live/example.com/; your server should use fullchain.pem and privkey.pem.
Before you run it, make sure the domain's A (and AAAA, if any) records point to this server. A quick DNS lookup saves a failed validation.
Other popular clients include acme.sh (a lightweight shell script), win-acme for Windows and IIS, and the automatic HTTPS built into web servers such as Caddy. Many hosting control panels also integrate Let's Encrypt with a single checkbox.
Renewal: the part that matters most
A 90-day certificate is only convenient if renewal is automatic. Certbot installs a systemd timer or cron job that runs twice a day and renews any certificate within 30 days of expiry. You can confirm it works without actually renewing:
sudo certbot renew --dry-runRenewal tends to break for predictable reasons:
- A firewall rule or security group change blocked inbound port 80, so HTTP-01 fails.
- The domain's DNS was moved to a different provider, breaking DNS-01 API credentials.
- A new redirect or CDN rule intercepts
/.well-known/acme-challenge/. - The web server was not reloaded after renewal, so it keeps serving the old certificate. Certbot's
--deploy-hookoption can reload it automatically.
Let's Encrypt no longer sends expiry reminder emails, so do not rely on your inbox. Monitor expiry independently, either with your existing monitoring system or by checking periodically with an SSL checker.
Rate limits
To protect the service, Let's Encrypt applies rate limits, such as caps on how many certificates can be issued for the same registered domain within a week and on repeated failed validations. Normal use never comes close. You are most likely to hit them while testing a broken setup repeatedly. Use the staging environment (certbot --staging or --dry-run) while experimenting; it has much higher limits and issues untrusted test certificates.
Behind a CDN or load balancer
If your site sits behind a CDN or cloud load balancer, visitors see the certificate held there, not the one on your server. Many such services issue and renew certificates for you automatically, often from Let's Encrypt or a similar ACME-based CA. In that case you may still want a certificate on the origin server so the connection between the CDN and your server is encrypted too. Make sure HTTP-01 challenge requests can pass through to whichever system is requesting the certificate, or use DNS-01 to avoid the question entirely.
When a paid certificate still makes sense
- A contract, tender or regulator requires OV or EV validation.
- You run systems that cannot be automated, such as some legacy appliances, where a longer-lived certificate from a commercial CA is easier to manage. Bear in mind that maximum lifetimes for all public certificates are also shrinking.
- You want vendor support, a warranty, or certificate management tooling bundled with the purchase.
Key takeaways
- Let's Encrypt provides free, browser-trusted DV certificates, including wildcards via DNS-01.
- Everything runs over the ACME protocol, so issuance and renewal can be fully automated.
- Use
fullchain.pem, test withcertbot renew --dry-run, and reload the web server after renewal. - Monitor expiry yourself; automation fails quietly when firewalls or DNS change.