Let's Encrypt vs Paid SSL — Which Should You Choose?

What Let's Encrypt Is

Let's Encrypt is a non-profit certificate authority that has been issuing free TLS certificates since 2016. It is operated by the Internet Security Research Group (ISRG), which is funded by EFF, Mozilla, Cisco, Akamai, and dozens of other internet infrastructure organizations. As of 2026 it issues more than four million certificates per day and secures roughly 60% of the public web.

Two innovations made it possible. The first was ACME (Automatic Certificate Management Environment), a protocol that lets a server prove control of a domain and receive a certificate without human intervention. The second was funding the entire CA from foundation grants and corporate sponsorships rather than per-certificate fees. Together these collapsed the cost of HTTPS from $50-150 per domain per year to zero.

Crypto-wise, a Let's Encrypt certificate is signed with the same algorithms and the same root trust as any commercial CA. RSA-2048 or ECDSA P-256, SHA-256 signatures, cross-signed by IdenTrust DST Root CA X3 historically and by ISRG Root X1 directly today. A browser cannot tell the difference and neither can openssl s_client.

Cost — The Honest Comparison

The list-price comparison is brutal. For every common certificate type, Let's Encrypt is free and paid issuers charge real money:

At the company level the difference is less dramatic than the row-by-row look suggests. A small startup with a single wildcard might save $100/year. A multi-brand enterprise with sixty product domains might save $20,000/year — real money, but rounding error against a developer headcount budget.

DV vs OV vs EV

The validation level is the actual product difference, not the encryption. All three give you the same TLS — the difference is what the CA verified before signing:

Let's Encrypt only issues DV certificates. If your compliance team requires an OV certificate listing your legal entity name, you must pay. For everyone else, the practical answer is: the encryption is identical, the user-visible UX is identical, and the security model is identical. EV in particular has been quietly dying since Chrome and Firefox removed the green address bar in 2019 — the visual signal that justified the price tag is gone.

Wildcards and Multi-Domain (SAN)

The two cases where many teams historically reached for paid certificates were wildcards (*.example.com) and multi-domain Subject Alternative Name (SAN) certs covering several brand names. Let's Encrypt closed both gaps in 2018.

Wildcards are issued via the DNS-01 challenge — you prove control of the domain by placing a TXT record at _acme-challenge.example.com. Most ACME clients automate this with DNS provider plugins (certbot supports Cloudflare, Route 53, DigitalOcean, Gandi, and 30+ others out of the box). The wildcard limitation: it only covers one level of subdomain. *.example.com matches api.example.com but not v2.api.example.com.

SAN certificates can list up to 100 names per cert from Let's Encrypt — more than nearly any organization needs. Add or remove a domain by re-running certbot; the new cert replaces the old one cleanly.

90-Day Lifetime vs 1-Year

Let's Encrypt certificates are valid for 90 days. Paid certificates were historically issued for 1 to 2 years, though the CA/Browser Forum reduced the maximum to 398 days in 2020 and is on track to reduce it further to 90 days for everyone by 2027 — at which point the lifetime advantage disappears entirely.

The 90-day cycle is intentional. Short lifetimes force automation: nobody wants to manually rotate a cert every three months. Automation eliminates the single most common TLS outage, which is "our wildcard expired Friday at 5pm and nobody noticed". Once the renewal cron is running, you forget the cert exists.

For paid 398-day certs the rotation is slower but the same automation pattern applies. Use ACME with a paid CA that supports it (Sectigo, ZeroSSL, BuyPass, Google Trust Services all do) or accept the manual rotation pain.

Browser Trust

Both Let's Encrypt's ISRG Root X1 and every paid CA root are in the Apple, Microsoft, Mozilla, and Google trust stores. The only meaningful gap is for very old client devices — pre-2016 Android, Windows XP, Java 7, or embedded TLS clients with stale trust stores. These typically cannot validate Let's Encrypt certificates because the ISRG Root X1 was added to most stores after 2016.

If your audience includes 0.1% of users on truly ancient hardware (industrial IoT, certain medical devices, legacy retail point-of-sale), a cross-signed cert from a longer-established CA like DigiCert or Sectigo will reach them. Let's Encrypt itself maintained a cross-sign from IdenTrust until 2024 to mitigate exactly this — that cross-sign has now expired.

When to Pay Anyway

Five concrete cases where a paid certificate still makes sense in 2026:

• arrow_rightCompliance requires OV/EV. PCI-DSS does not require it but some banking partners contractually do. The cert itself is the artifact your auditor wants to see.
• arrow_rightWarranty matters. Paid CAs ship a per-incident warranty (typically $100K to $1.75M) covering relying parties if the CA mis-issues. Useful for high-value B2B contracts.
• arrow_rightCode signing or document signing. Different cert type, different ecosystem — Let's Encrypt does not issue these at all.
• arrow_rightInternal CA needs. For a private PKI inside your company you want a paid CA that issues sub-CA certificates from a trusted root. Let's Encrypt only signs end-entity certs for public domains.
• arrow_rightPhone support. When a renewal fails at midnight before a launch, having a vendor with a SLA-backed phone line is worth real money to some teams.

Getting Started with Certbot

For a typical Linux server, certbot is the easiest path to a Let's Encrypt certificate. The HTTP-01 challenge auto-renews via systemd timer; the DNS-01 challenge for wildcards needs API credentials for your DNS provider:

# Install certbot (Debian/Ubuntu)
sudo apt install certbot python3-certbot-nginx

# Get a cert with the nginx plugin (auto-edits config)
sudo certbot --nginx -d example.com -d www.example.com

# Or, get a cert standalone (you handle the web server config)
sudo certbot certonly --standalone -d example.com

# Wildcard cert (requires DNS-01 challenge)
sudo certbot certonly --manual --preferred-challenges dns \
  -d '*.example.com' -d example.com

# Auto-renewal (already installed as a systemd timer or cron job)
sudo systemctl status certbot.timer
# Test renewal without actually renewing
sudo certbot renew --dry-run

The whole flow takes about three minutes the first time and zero minutes thereafter. Renewal is a no-op until 30 days before expiry, at which point certbot quietly refreshes the cert and reloads the web server. The single most common failure mode is a stale firewall rule blocking inbound port 80 (needed for HTTP-01); switch to DNS-01 and the dependency disappears.

Default recommendation: use Let's Encrypt unless you have a specific reason from the "when to pay" list. The encryption is identical, the user UX is identical, and your future self will thank you for never having to manually renew a certificate again.