Let's Encrypt

Let's Encrypt is the default HTTPS certificate authority for a huge fraction of the public web. This 2026 review is for US and UK site owners, freelancers, and SMB IT folks asking a blunt question: should you keep using free DV certificates, or pay Sectigo/DigiCert/Entrust for organization validation and a support desk?

Let's Encrypt should be the default HTTPS path for most sites. Pay for OV/EV only when procurement, compliance theater, or brand validation truly requires it.

Quick verdict

Let's Encrypt earns about 4.7 / 5 as the automatic choice for blogs, marketing sites, SaaS staging, side projects, and most production apps that only need Domain Validation. It is “free” in money and expensive in ops discipline: short-lived certificates demand working ACME renewals and monitoring. If your host already issues and renews Let's Encrypt for you, you are already winning.

STA angle: unmatched value for DV HTTPS; clarity depends on your hosting panel; “support” is community and docs, not a CA hotline.

What Let's Encrypt is (and is not)

Let's Encrypt is a free, automated certificate authority operated as a public benefit / nonprofit mission (ISRG). It issues Domain Validated (DV) certificates through the ACME protocol. Clients like Certbot, Caddy’s automatic HTTPS, Traefik, cert-manager on Kubernetes, and countless hosting panels speak ACME so certificates can be issued and renewed without buying SKUs from a reseller.

What it is optimized for:

• Encrypting traffic so browsers show HTTPS without purchase orders
• Automating issuance at internet scale
• Removing “SSL is hard/expensive” as an excuse for plaintext sites
• Working everywhere ACME HTTP-01 / DNS-01 challenges can be completed

What it is not:

• Organization Validation (OV) or Extended Validation (EV) identity proof
• A commercial support contract with 15-minute SLAs
• A CDN, WAF, or “secure hosting” product
• A cure for insecure application code, weak cookies, or missing security headers

DV certificates prove control of a domain name at issuance time. They do not prove your company is the legal entity a procurement officer imagines when they say “we need SSL.”

Core features that matter in 2026

1. ACME automation is the product

The certificate itself is commodity DV. The product is the ecosystem: Certbot on classic VMs, Caddy with automatic HTTPS, panel one-clicks on shared hosting, and cert-manager in clusters. If automation is healthy, Let's Encrypt is nearly invisible—which is the goal. If automation is broken, you get 3 a.m. expiry outages that feel like the CA “failed” when your cron did.

2. Short lifetimes force good hygiene

Certificate lifetimes are intentionally short relative to the multi-year paper certs of the 2000s. That design reduces the damage window of key compromise and encourages automation. It also punishes “issue once and forget” admins. In 2026, treat expiry monitoring as mandatory: uptime checks that alert on certificate days-remaining, not only HTTP 200.

3. Challenge types: HTTP-01 vs DNS-01

HTTP-01 is simple when your web server can serve a well-known path on port 80. DNS-01 is required for wildcards and for many locked-down networks. Wildcard certificates are powerful and easy to mismanage—document which hosts they cover and where the private key lives. Prefer narrower names when operationally feasible.

4. Rate limits and staging

Let's Encrypt rate limits exist to protect the ecosystem. Use the staging environment while debugging clients so you do not burn production limits. When a migration goes sideways, staging discipline separates pros from “why is issuance broken on launch day” panic.

5. Transparency and mission fit

As a mission-driven CA, Let's Encrypt publishes extensive documentation and participates in Certificate Transparency. That openness is part of why the industry trusts DV-at-scale. It does not mean zero incidents forever—operate like any dependency: monitor, subscribe to status notices, and have a fallback CA plan for emergencies.

Pricing renewal notes (free money, paid attention)

Street price is Free. There is no renewal invoice from Let's Encrypt for the certificate itself. The 2026 “renewal” risks are operational and adjacent-commercial:

1. ACME renewal failure after a host move, firewall change, or DNS provider API token expiry.
2. Panel upsells where a host charges for “premium SSL” that is still DV under the hood—sometimes fine for support bundling, sometimes pure margin.
3. Wildcard DNS API tokens stored insecurely become a security problem bigger than the cert cost you saved.
4. Multi-year prepaid OV/EV from commercial CAs can still make sense for procurement—do not “save money” by forcing Let's Encrypt into a contract that explicitly requires OV.

Calendar habits that matter even though the cert is free:

• Alert when any public cert has fewer than 14 days remaining.
• After every DNS host or reverse-proxy change, force a renewal rehearsal in staging or renew early once.
• Document who owns ACME for each property—freelancers leave, certs remain.

US/UK note: “free SSL” offers from hosts are often Let's Encrypt wrappers. That is good. Just confirm auto-renew is on and that email alerts go to a monitored inbox, not a former employee.

Setup checklist (sites and apps)

1. Decide challenge type: HTTP-01 for simple single hosts; DNS-01 for wildcards or blocked port 80.
2. Prefer a maintained client: hosting panel toggle, Caddy, Traefik, Certbot, or cert-manager—not a random GitHub script last touched in 2019.
3. Issue on staging first if you are wiring a new client.
4. Confirm the full chain serves correctly (intermediate included) and that HTTP redirects to HTTPS without loops.
5. Turn on renewal automation; run dry-run or equivalent where available.
6. Add external monitoring for certificate expiry and TLS errors.
7. Store private keys with least privilege; restrict who can download panel certs.
8. Load HSTS only after you are sure HTTPS is stable for all hostnames users might hit.
9. Record a fallback: how you would temporarily use another CA if ACME were unavailable during an incident.

If your site is on Netlify, Cloudflare, Vercel, or similar, follow that platform’s certificate docs—fighting them with manual Certbot is usually waste.

Who should use it — and who should skip

Use Let's Encrypt if you:

• Need HTTPS for content sites, APIs, staging, and most startups
• Can keep ACME renewals healthy (or your host does it)
• Do not need OV/EV identity validation in browser UI or contracts
• Want to stop paying annual DV invoices for no procurement reason

Skip (or supplement) Let's Encrypt if you:

• Your customer contract or PCI questionnaire explicitly demands OV/EV from a commercial CA
• You need a vendor support desk to walk a non-technical staffer through CSR installation on legacy Windows Server IIS without ACME
• You cannot automate renewals and refuse to monitor expiry
• You need specialized private PKI / internal enterprise CA features (different product category entirely)
• A compliance checklist writer will reject “free CA” regardless of cryptography—pick battles

Alternatives with real nuance

Alternative	Choose it when…	Trade-off vs Let's Encrypt
Sectigo SSL	You need paid DV/OV/EV via familiar SMB resellers	Cost + reseller quality variance
Entrust	Enterprise buying motion and managed PKI conversations	Overkill for a blog
DigiCert / other flagship CAs	Brand preference and enterprise support matter	Higher prices for similar DV crypto
Cloudflare / host-managed TLS	You want certificates invisible behind a proxy	Understand termination points and origin certs
Self-signed	Lab only	Browsers will rightly scare users

Nuance: paid DV from a commercial CA is rarely “more secure” cryptographically than Let's Encrypt DV. You are buying validation process differences (for OV/EV), warranty marketing, support, and procurement familiarity.

Security notes certificate buyers mix up

• HTTPS encrypts the pipe; it does not authenticate your WordPress plugins as safe.
• Mixed content can still break padlock UX—fix HTTP assets after enabling TLS.
• Wildcard keys are crown jewels—protect them like production database credentials.
• Certificate Transparency logs mean issuance is observable; that is generally a feature.
• Expired certs destroy trust faster than most downtime: users learn to click through warnings—do not train them.

Ops stories worth avoiding

The classic outage: developer changes nginx config, drops the ACME location block, renewals fail silently for 60 days, site dies on a Monday. The fix is monitoring plus a documented owner. Second classic: DNS-01 token with zone-wide write access committed to a public repo. Scope tokens tightly and rotate on staff changes.

For multi-domain agencies: standardize on one ACME approach per hosting class (panel vs Kubernetes vs Caddy). Snowflakes create expiry roulette.

Final score: 4.7 / 5

Let's Encrypt remains Editor’s Choice for default public-web HTTPS in 2026. The certificate is free; reliability is earned through automation and alerts. Pay commercial CAs for identity validation and support when those are real requirements—not because a reseller upsell said “business SSL.”

FAQ

Is Let's Encrypt safe to use?
Yes for DV HTTPS on the public web. Use official clients and keep renewals automated. Safety of your site still depends on app security.

Does Let's Encrypt replace good security habits?
No. Patch CMSs, use strong admin passwords/passkeys, and enable backups. TLS is necessary, not sufficient.

Is there a free version?
The certificates are free. Hosting, DNS, and your time are not.

Will it slow my PC or Mac?
Let's Encrypt is not desktop security software. It affects servers and browsers via normal TLS—which modern hardware handles fine.

Can I share one “license” across sites?
There is no seat license. Rate limits and operational ownership still apply per account/client setup.

What is the biggest mistake operators make?
Assuming panel auto-renew is healthy forever without expiry monitoring—especially after domain DNS migrates.

Do I need EV certificates in 2026?
Almost never for UX reasons (browser EV presentation changed years ago). Buy EV only if a contract or policy demands it.

Are wildcards a good default?
Convenient, riskier key management. Use when the operational model justifies them; otherwise prefer exact hostnames.