Free Certificates with Let's Encrypt

Before Let’s Encrypt, putting HTTPS (the secure, encrypted version of HTTP) on a website meant paying a company anywhere from $50 to several hundred dollars a year for a TLS certificate, then going through a slow, manual purchase process. Let’s Encrypt changed all of that. It is a free, automated certificate authority (a CA — an organization trusted by web browsers to confirm that a website really owns its domain). This page explains what Let’s Encrypt is, how it proves you own your domain, and the rules you need to know before you start issuing real certificates.

What is Let’s Encrypt?

Let’s Encrypt is a non-profit certificate authority run by the Internet Security Research Group (ISRG). It launched publicly in 2016 and has since issued billions of certificates. Its goal is simple: make encrypted HTTPS the default for the entire web by making certificates free, automatic, and open.

A TLS certificate (sometimes still called an “SSL certificate” out of habit) is a small file that proves your domain’s identity and lets browsers set up an encrypted connection. Every browser ships with a list of CAs it trusts, and Let’s Encrypt is on that list. That is what makes the green padlock appear without scary warnings.

Let’s Encrypt only issues Domain Validated (DV) certificates — it confirms you control a domain, nothing more. It does not offer Organization Validated (OV) or Extended Validation (EV) certificates that vouch for a legal company name. For 99% of websites, DV is exactly what you want.

The ACME protocol

The reason Let’s Encrypt can be fully automatic is a standard called ACME (Automatic Certificate Management Environment). ACME is a defined set of messages your server and the CA exchange over the internet to request, validate, and install a certificate — with no human clicking buttons.

You almost never speak ACME by hand. Instead you run an ACME client — a program that does the talking for you. The most popular client is Certbot, maintained by the Electronic Frontier Foundation (EFF), which we cover in detail in the Certbot pages. Other clients include acme.sh, Caddy (which has ACME built in), and the Nginx-native njs module.

How domain validation works

Before issuing a certificate, Let’s Encrypt must verify you actually control the domain. It does this with a challenge — it asks your server to prove ownership in one of two common ways:

Challenge type	How it proves ownership	When to use it
HTTP-01	The CA tells your client to place a specific file at `http://your-domain/.well-known/acme-challenge/<token>`. It then fetches that URL over port 80.	The default. Works for any single domain pointed at a public server. Cannot issue wildcard certs.
DNS-01	The CA gives you a value to add as a TXT DNS record (a text entry in your domain’s DNS) at `_acme-challenge.your-domain`. It checks DNS for that value.	Required for wildcard certificates (`*.example.com`) and when port 80 is closed or the server is private.

HTTP-01 needs port 80 open and your domain already pointing at the server. DNS-01 needs access to your DNS provider (ideally via an API so it can be automated).

The 90-day certificate lifetime

A Let’s Encrypt certificate is valid for only 90 days, far shorter than the 1-3 years traditional CAs once offered. This is deliberate and a good thing:

Short lifetimes limit damage. If a private key is stolen, the window an attacker can abuse it is small.
It forces automation. Because renewing by hand every 90 days would be miserable, everyone automates renewal — and automation is more reliable than a human remembering.

The standard advice is to renew when a certificate has 30 days left (at the 60-day mark). Certbot does this for you automatically via a systemd timer, which we cover on the auto-renew page. The wider industry is even moving toward 47-day certificates by 2029, so building automation now is the right habit.

Rate limits

Let’s Encrypt is free, so to keep it stable and prevent abuse it enforces rate limits. The main ones to know in 2026:

Limit	Value	Notes
Certificates per registered domain	50 per week	Counts the whole domain, e.g. all of `example.com`.
Duplicate certificate (same exact set of names)	5 per week	The one most beginners hit while testing.
Failed validations	5 failures per hostname per hour	Stops you from hammering the service while debugging.
Names per certificate	100	Subject Alternative Names in a single cert.

The duplicate-certificate limit is the trap: if you repeatedly issue a cert for the same domain while learning, you can lock yourself out for a week.

Use the staging environment to test

This is the single most important tip on this page. Let’s Encrypt runs a separate staging environment that behaves exactly like production but issues fake (untrusted) certificates and has much higher rate limits. Always test your setup against staging first, then switch to production once it works.

With Certbot you add the --staging flag:

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

Output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for example.com and www.example.com
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate is NOT TRUSTED by browsers. It was issued using the staging environment for testing.

A staging certificate will show a browser warning — that is expected. Once everything works, delete the staging cert and re-run the same command without --staging to get a real, trusted certificate:

sudo certbot delete --cert-name example.com
sudo certbot certonly --nginx -d example.com -d www.example.com

Never deploy a staging certificate to real users — browsers will reject it. Staging is for confirming your DNS, ports, and config are correct, nothing more.

Why it democratized HTTPS

Before 2016, most small sites ran plain HTTP because certificates cost money and took effort. Let’s Encrypt removed both barriers at once. The result: HTTPS adoption jumped from roughly 40% of page loads to well over 90% today. Search engines reward HTTPS, browsers now mark plain HTTP pages as “Not Secure,” and encryption protects your users on shared Wi-Fi. Free, automatic certificates are the reason the secure web became the default web.

Best Practices

Always run a test issuance against the --staging environment before requesting a real certificate.
Let an ACME client like Certbot handle renewal automatically; never plan to renew the 90-day certs by hand.
Use HTTP-01 validation for normal single-host certs, and DNS-01 only when you need wildcards or have port 80 closed.
Watch the duplicate-certificate rate limit (5/week) while learning — reuse one cert instead of re-issuing repeatedly.
Keep your /etc/letsencrypt directory backed up; it holds your private keys and account data.
Subscribe to the expiry-notification emails Let’s Encrypt sends as a safety net in case automated renewal silently fails.