Let's Encrypt

What Let's Encrypt actually is

Let's Encrypt is a free, automated, open certificate authority, and it is the single most successful piece of security infrastructure of the last decade. It is a project of the Internet Security Research Group (ISRG), a US 501(c)(3) nonprofit, and it issues domain-validated TLS certificates at no cost to anyone who can prove control of a domain. The headline number on the homepage today is more than 700 million websites served — up from the 300 million figure our database still carried — and the issuance statistics are public, updated continuously, and independently checkable.

There is also a second-order effect worth naming: Let's Encrypt's existence reset the economics of the entire certificate market. Before 2015, basic TLS certificates were a paid product with per-year pricing and manual validation; today every major hosting panel issues certificates automatically, browsers mark plain HTTP as insecure, and commercial CAs compete on validation level and support rather than on encryption itself. When we evaluate certificate options on ServerSpotter, that is the backdrop: the free baseline is so good that paid certificates have to justify themselves on validation, warranty, and process — not on the padlock.

The operating model is the interesting part. There is no freemium ladder, no paid tier, and no enterprise sales motion: 100% of funding comes from sponsors and community contributions, with Google Chrome, AWS, Microsoft, and the Open Technology Fund at the diamond level and Mozilla, the EFF, OVH, and Meta among the platinum sponsors. The organization is small — public accounts put ISRG staff in the high twenties — and it runs one of the busiest pieces of internet trust infrastructure in the world on that budget. That is worth stating plainly, because it explains both the strengths and the limits of what you are adopting.

The history is a timeline of hitting milestones early. ISRG was incorporated in May 2013, the project was announced in November 2014, the first certificate issued on 14 September 2015, public trust from the major root programs followed within weeks, and general availability came on 3 December 2015. A million certificates by March 2016, 100 million by mid-2017, and the billionth certificate in February 2020. Along the way the ACME protocol — the machine-to-machine certificate issuance and renewal protocol Let's Encrypt invented — became an IETF standard in March 2019, which is why every hosting panel, ingress controller, and reverse proxy now speaks it.

Pricing: what you really pay

The price is zero, and it is zero for everyone: one certificate costs the same as a million, and there is no per-domain fee, no wildcard surcharge, and no support upsell attached. In the strict sense there is nothing to compare in our ssl-certificates category — commercial CAs sell organization-validated and extended-validation certificates with warranty sums and support contracts, and Let's Encrypt sells none of that.

The real costs are operational, and they are worth pricing honestly. Certificates are valid for 90 days as of October 2026, which means automation is not optional: you need an ACME client (Certbot, acme.sh, Caddy, Traefik, or the client built into your control panel) running renewal on schedule. Get that wrong and a free certificate becomes an outage. The shortening trend continues — Let's Encrypt has announced that from February 2027 the default profile will issue 64-day certificates with a 10-day authorization reuse period, and a 45-day profile is already available for early adopters. Short-lived certificates are better security (stolen keys are useful for less time) and worse convenience, and Let's Encrypt has chosen security on that trade every time.

Support is the other line item. There is a community forum where ISRG staff and volunteers answer questions, excellent documentation, and public issue trackers on GitHub. What there is not: a support desk, a response-time commitment, or anyone contractually obliged to answer you. For a personal blog that is fine. For the certificate layer of a payment platform, plan to be your own expert or keep a commercial CA relationship as well.

Performance & infrastructure

Certificate issuance is fast and scriptable: prove domain control via HTTP-01, DNS-01, or TLS-ALPN-01 challenge, and a certificate comes back in seconds. Wildcard certificates are supported via DNS-01, and as of January 2026 short-lived 6-day certificates and IP address certificates reached general availability — options that matter for infrastructure automation and ephemeral workloads where a 90-day lease is absurdly long.

The trust story is complete: Let's Encrypt's ISRG Root X1 is in the major root stores, an ECDSA root (ISRG Root X2) has been in service since 2020, and cross-signing arrangements kept old devices trusting the chain during the transition. Certificates are issued from intermediates so the root keys can stay offline, and revocation relies on CRLs rather than OCSP responders — a deliberate design choice paired with short validity periods.

Reliability at this scale is a serious engineering fact. The service issues on the order of millions of certificates a day and underpins HTTPS for a large fraction of the web, and its published statistics page (certificates issued per day, percentage of Firefox page loads over HTTPS) is the kind of transparency we rarely see from commercial CAs. It has not been incident-free — no CA has — but incident communication is public, and the organization's small size means failures get explained rather than absorbed into a status page widget.

The practical deployment recipe we recommend is short: run an ACME client as a service, renew on a schedule well inside the validity window (weekly is common), alert on failure, and test renewal before it matters. Wildcard users need DNS-01 automation with API credentials for their DNS provider, which is the one place where setup genuinely gets fiddly. Get those four pieces right and the certificate layer stops being something anyone thinks about — which is the point.

For operators, the ecosystem is the killer feature. ACME clients exist for every stack, hosting providers bake issuance into their panels, Kubernetes ingress controllers automate it natively, and the protocol being an IETF standard means you are not locked to Let's Encrypt — the same automation works with other ACME CAs. That portability is exactly what we want from infrastructure at this layer.

Where it falls short

Domain validation only. Let's Encrypt does not issue organization-validated (OV) or extended-validation (EV) certificates, does not sell multi-year terms, and offers no warranty sum — the things that procurement checklists at banks and large enterprises still ask for. If your compliance regime demands OV/EV or a named account manager for the trust layer, this is not your CA, and pretending otherwise helps nobody.

The 90-day lifetime, shrinking to 64 days in 2027, is the operational tax. Manual renewal is effectively unsupported by design, and a meaningful share of the web's certificate outages each year come from people who automated issuance but not renewal. We consider this an acceptable trade for the security properties, but teams must budget for it: renewal monitoring, wildcard DNS automation where needed, and alerts when a certificate is inside its expiry window.

Support is community-based. There is no SLA, no guaranteed issuance uptime, and no contractual recourse if issuance is slow or a validation check fails. The organization is transparent and responsive by reputation, but "by reputation" is not a contract.

Finally, rate limits exist — measured per registered domain and per account — to keep abuse down, and they can bite legitimate large-scale users (think wildcard-heavy multi-tenant platforms). Higher limits are handled through an adjustment process rather than a purchase, which is fair but adds process.

Who should pick this

We would pick Let's Encrypt for essentially every website and API endpoint where domain validation is acceptable — which is the overwhelming majority of the web. Personal sites, SaaS front-ends, internal tools exposed over TLS, microservice ingress, staging environments, IoT fleets with DNS automation: the free-and-automated model wins outright, and our pick for the default TLS layer of any new project is this one, without hesitation.

We would not pick it where OV or EV validation is contractually required, where certificate operations cannot be automated at all, or where a business relationship with a CA (warranties, named support, liability framing) is itself a deliverable. In those cases budget for a commercial CA — but automate against ACME anyway where you can, so the operational model stays portable.

Key takeaways

• Free, automated, domain-validated TLS certificates from a nonprofit CA (ISRG); more than 700 million websites served
• 90-day certificate lifetimes as of October 2026, dropping to 64 days from February 2027 — automation is mandatory
• ACME is an IETF standard (2019), so issuance tooling is portable across CAs and built into every major platform
• Transparent operation: public issuance statistics, published timelines, open-source clients, sponsor-funded with no paid tier
• No OV/EV certificates, no warranties, no support SLA — community forum and docs instead
• Our default pick for TLS wherever domain validation suffices; keep a commercial CA only for compliance-mandated cases

Sources

• https://letsencrypt.org/
• https://letsencrypt.org/stats/
• https://letsencrypt.org/feed.xml
• https://en.wikipedia.org/wiki/Let%27s_Encrypt