The Let's Encrypt revolution: how free certificates rewired the web's trust layer

In 2015, somewhere between 55 and 70 percent of browser page loads still happened over plaintext HTTP. The average price for a one-year, single-domain certificate from the five largest certificate authorities was about $178. To get one, a server operator had to recognize they needed a cert, pick a vendor out of a confusing marketplace, generate a key, build a CSR, complete a payment transaction, wait for issuance, install the chain by hand, and then repeat the whole ritual a year later before the thing expired and threw browser warnings at every visitor. Each step was a place to give up. Most people gave up.

Ten years later more than 80 percent of page loads are encrypted, a domain-validated certificate costs nothing, and the operator never touches it because a daemon renews it on a schedule. One organization is responsible for most of that swing, and it did it by attacking the part everyone else treated as immovable: not the price of a certificate, but the human labor of getting one. This post traces how that happened.

We start with the world before 2015 and why HTTPS adoption had stalled. Then the 2013 founding of the Internet Security Research Group, the design of the ACME protocol and the Boulder CA behind it, the 2015-2016 launch, and the climb to becoming the largest CA on the planet. The last third covers what changed once “encrypt everything” was basically won: the 2024 decision to kill OCSP, the 2025 arrival of six-day certificates, and the slow march of every cert toward a 45-day lifetime. The through-line is automation, and what automation does to a trust layer once it stops being optional.

Before 2015: why HTTPS stalled

The technical pieces of HTTPS were in place for two decades before it became the default. Netscape shipped SSL in 1994. The performance overhead of TLS on modern hardware is negligible. So the question was never “can we encrypt.” It was “why didn’t we,” and the answer was friction plus money, in roughly that order.

Certificates cost real money, and the market was deliberately confusing. The CCS 2019 paper that the Let’s Encrypt team wrote about their own system put 2015 prices in a table: GoDaddy charged $69 for a single-domain cert and $332 for a wildcard, Comodo $76 and $404, GeoTrust $149 and $499, DigiCert $195 and $595, and Symantec $399 and $1999. Because browsers treat every domain-validated certificate identically, the CAs segmented the market with add-ons. “Vulnerability assessment scans,” warranty programs that nominally covered relying parties if a cert was mis-issued, higher prices for elliptic-curve keys than RSA keys. Symantec charged $597 more per year to issue against an EC key. None of that changed what the browser padlock meant. It changed what the invoice said.

Cheaper paths existed but came with traps. StartCom’s StartSSL offered free certificates for non-commercial use starting in 2011, which was genuinely ahead of its time, but it charged for revocation. After Heartbleed forced a wave of mass revocation in April 2014, that pricing model became a liability for the people relying on it. You could get the cert for nothing and then get billed to invalidate it during the exact emergency revocation exists for.

How the CA marketplace got this way, and the breaches that reformed it, is its own story in the history of certificate authorities.

Money was only half the problem. The other half was that even a free certificate took work. An operator had to generate a private key, build a certificate signing request, prove control of the domain through whatever manual hoop the CA used, wait, then configure the server with the cert and the right intermediate chain. Usability studies cited in the same paper found that installing a cert took administrators about an hour even when the CA issued it instantly, and the whole thing had to be redone before expiry. A 2013 study found that only about 45 percent of certificates on HTTPS servers were correctly configured, and around 13 percent were misconfigured badly enough to be inaccessible to some clients. Renewal lapses hit roughly 20 percent of certificates. The manual process did not just deter adoption. It produced broken deployments at scale.

Two events around 2013 and 2014 turned background concern into urgency. The Snowden disclosures made it concrete that intelligence agencies were harvesting plaintext traffic in bulk, including at points inside company networks where HTTPS protection was simply absent. Heartbleed, the OpenSSL bug disclosed in April 2014, exposed private keys on a huge fraction of TLS servers and forced an industry-wide key rotation that the manual issuance process was spectacularly unsuited to handle. The lesson both events taught was the same. Encryption that depends on humans doing tedious work correctly, on a schedule, under pressure, will not be there when you need it.

2013: the Internet Security Research Group

Let’s Encrypt came out of two efforts that found each other. At the University of Michigan, J. Alex Halderman and the EFF’s Peter Eckersley were building a protocol to automatically issue and renew certificates. At Mozilla, a team led by Josh Aas and Eric Rescorla was working on a free, automated CA. The two groups learned of each other in 2012, realized they were building two halves of the same thing, and joined forces.

In May 2013 they incorporated the Internet Security Research Group as the legal entity that would operate the CA. The choice of a nonprofit was deliberate and structural. Running a CA that the whole web depends on requires high transparency, a public-service mission, and the kind of governance that does not bend to a quarterly revenue target. A nonprofit with no profit motive and no owners was the form that let the organization stay a trusted issuer over the long term. Josh Aas has been ISRG’s executive director since the founding.

*The arc from incorporation to short-lived certificates. The orange tick is where the project stopped chasing adoption and started reshaping the cert lifecycle itself.*

The initial backers were the organizations with the most to gain from a more encrypted web: the EFF, Mozilla, Cisco, Akamai, the University of Michigan, and IdenTrust, the established CA whose root would cross-sign Let’s Encrypt’s intermediate so that browsers trusted it on day one. That cross-signing detail matters more than it sounds. A brand-new root takes years to propagate into every browser and operating system trust store. By chaining to IdenTrust’s already-trusted root, Let’s Encrypt could issue certificates that worked in the field immediately, while its own ISRG Root X1 slowly earned its place in the web PKI trust store over the following years.

The project was announced publicly on November 18, 2014. For the first year and a half it had almost no full-time staff. The software was built by engineers from EFF and Mozilla with help from Cisco and IdenTrust, plus the Michigan researchers building what would become the client. ISRG hired its first full-time employee in April 2015. By May 2019, the entire organization running what was by then the world’s largest CA had 13 full-time staff: six site-reliability engineers, three software developers, and four administrative people. The ratio is the whole point. The work that used to need a human per certificate now needed almost no humans at all, because it had been moved into a protocol.

The ACME protocol and Boulder

The thing that made all of this work is ACME, the Automatic Certificate Management Environment. It is the protocol a server speaks to a CA to request a certificate, prove it controls the domain, and pick up the issued cert, with no human in the loop on either side. ACME is JSON over HTTPS. It was designed by ISRG for Let’s Encrypt, ran in production as the proprietary “ACMEv1” from the December 2015 launch, and was eventually standardized by the IETF as RFC 8555 in March 2019, authored by Richard Barnes of Cisco, Jacob Hoffman-Andrews of the EFF, Daniel McCarney of Let’s Encrypt, and James Kasten of the University of Michigan.

The heart of ACME is domain validation, the challenge that proves the requester actually controls the name they are asking to certify. Three challenge types are in use today, and the difference between them is which part of the infrastructure you have to demonstrate control over.

*The ACME exchange. Steps 1, 2, and 4 are bookkeeping. Step 3, proving you control the name, is the only part where a human used to be required, and it is the part ACME automates away.*

HTTP-01 is the common one. The CA hands the client a token, the client writes a file containing that token and a thumbprint of the account key to a fixed path under /.well-known/acme-challenge/ on the web server, and the CA fetches it over port 80. If the file is there with the right contents, you have demonstrated control of the host. DNS-01 instead asks you to publish a TXT record at _acme-challenge.<domain>, which the CA looks up. DNS-01 is the only way to get a wildcard certificate, because controlling the zone proves authority over every name under it, and it works for hosts that are not reachable from the public internet. TLS-ALPN-01 performs the validation entirely inside a TLS handshake on port 443 using a dedicated ALPN protocol, which suits TLS-terminating reverse proxies and big hosting platforms that already own the 443 listener. An older challenge, TLS-SNI-01, was removed in March 2019 after researchers showed it could be abused on shared hosting infrastructure where one tenant could answer for another.

On the CA side, the software that runs all of this is Boulder, ISRG’s certificate authority implementation written in Go and open-sourced. The reference client most people met first is Certbot, the Python tool maintained by the EFF, which obtains a cert and can configure popular web servers to use it. The pairing matters historically because it set a template. ACME is an open protocol with multiple independent implementations, so the ecosystem that grew around Let’s Encrypt was never locked to one client. Today acme.sh, lego, win-acme, Caddy’s built-in ACME support, and dozens of others all speak the same protocol, and several other CAs have since stood up their own ACME endpoints. The automation Let’s Encrypt needed became an industry interface.

There is a security argument hiding in the automation, and it is the inverse of what people first assumed. Historically the most frequent cause of CA mis-issuance was human error somewhere in the manual validation pipeline. By making issuance fully robotic with no manual override, ACME removed a large class of those mistakes. The machine does the same check every time. It does not get socially engineered, it does not skip a step on a Friday, and it does not approve a request because the customer is important.

2015-2016: launch and the climb

Let’s Encrypt issued its first browser-trusted certificate on September 14, 2015, for the domain helloworld.letsencrypt.org. IdenTrust cross-signed the intermediate on October 19, which is what made certificates trusted in shipping browsers rather than just cryptographically valid. The public beta opened on December 3, 2015, and general availability followed on April 12, 2016. From that point the curve is almost vertical.

By January 2019, a little over three years in, Let’s Encrypt had issued more than 538 million certificates covering 223 million domain names, and there were already more currently-valid browser-trusted certificates issued by Let’s Encrypt than by every other CA combined. The one-billionth certificate was issued on February 27, 2020. As of 2025 the CA serves more than 700 million websites and is comfortably the largest certificate authority in the world.

*Encrypted page loads roughly tripled over the decade. Let's Encrypt did not do all of this alone, but the timing of its launch lines up with the steepest part of the climb.*

Attributing the whole HTTPS swing to one CA would be too neat. Google’s ranking and UI changes pushed in the same direction. Chrome and Firefox both started marking plain HTTP pages as “Not Secure,” which turned the absence of encryption into a visible defect rather than a neutral default. CDNs began offering one-click HTTPS. But the measurements line up with the launch. Over the roughly four years after Let’s Encrypt went live, the fraction of browser page loads over HTTPS approximately doubled, from the 30s into the 70s, and by the end of 2024 it was past 80 percent. The team’s own paper noted that more than a third of the Alexa top million used Let’s Encrypt and that it was the fourth most common CA in Firefox beta handshakes, while issuing more certs than anyone, which is the signature of a CA serving an enormous tail of smaller sites that previously had no certificate at all.

That tail is the real story. The big commercial sites were going to encrypt eventually because they could afford to. The blogs, the hobby projects, the small-business sites, the millions of low-traffic domains that would never have justified a $178 annual line item and an hour of sysadmin time, those are the ones that flipped because the cost in money and effort hit zero at the same moment. If you are interested in how detection systems read the resulting traffic, the TLS fingerprinting story picks up where universal encryption leaves off, since once everything is encrypted the handshake itself becomes the thing worth fingerprinting.

The 90-day default and why it was deliberate

Let’s Encrypt certificates were valid for 90 days from the start, when commercial CAs were happily selling one, two, and three-year certs. This was not a limitation. It was a design decision with two motives stated plainly in the project’s own writing.

The first motive is that a short lifetime strongly encourages automation. A 90-day cert is short enough that nobody wants to renew it by hand four times a year, which nudges every operator toward an ACME client that does it for them, which is exactly the behavior that makes the whole system reliable. The renewal that used to be a calendar reminder becomes a cron job. The second motive is that short lifetimes lessen the damage from key compromise and reduce dependence on revocation. If a private key leaks, the window during which a mis-issued or stolen certificate is dangerous is bounded by how soon it expires anyway. Revocation, as the next section explains, has never worked well. A certificate that expires on its own in weeks is a certificate that does not need revocation to be made safe.

That second motive is the thread that the entire post is pulling. Once you accept that revocation is unreliable and that expiry is the dependable mechanism, the logical move is to keep shortening the lifetime until expiry is fast enough to replace revocation entirely. Everything Let’s Encrypt has done since 2024 is that logic playing out.

2024-2025: killing OCSP

To understand the OCSP decision you have to understand the problem revocation was trying to solve and why the existing tools were bad at it. When a certificate’s private key is compromised, you want a way to tell the world to stop trusting that certificate before it naturally expires. The two mechanisms are Certificate Revocation Lists, which are signed lists of revoked serial numbers a client downloads, and the Online Certificate Status Protocol, where a client asks the CA in real time whether a specific certificate is still good. The mechanics of both are covered in more depth in the post on OCSP, stapling, and the revocation-check fingerprint.

OCSP had a privacy problem baked into its design. When a browser checks a certificate’s status by querying the CA’s OCSP responder, the CA learns which site that visitor’s IP address is connecting to, in real time, every time. The certificate authority becomes a witness to a chunk of everyone’s browsing history. A CA that does not want to keep those logs can still be compelled to start keeping them, which is precisely the kind of centralized surveillance chokepoint the whole post-Snowden push toward encryption was supposed to remove. Stapling, where the server fetches its own OCSP response and serves it inside the handshake, was designed to fix the privacy leak, but adoption was patchy and the must-staple variant that would have made it enforceable never became universal.

In July 2024, Let’s Encrypt announced its intent to stop providing revocation information via OCSP and serve it exclusively through CRLs. The detailed timeline came in December 2024. OCSP Must-Staple requests from new accounts began failing on January 30, 2025. On May 7, 2025, CRL URLs were added to certificates and OCSP URLs were removed, and all Must-Staple requests started failing. The OCSP responders were shut down for good on August 6, 2025.

*The privacy difference. An OCSP query names the exact site at the moment of the visit. A CRL is a bulk download that reveals nothing about which certificate the client actually cared about.*

The scale of what got switched off is worth sitting with. At peak earlier in 2025, Let’s Encrypt’s OCSP service handled roughly 340 billion requests per month, which worked out to more than 140,000 requests per second at the CDN edge and about 15,000 per second hitting the origin. That entire real-time query firehose, every one of those queries a small disclosure of someone’s browsing, is gone. Operating it had also consumed real engineering resources for the project’s entire existence, so removing it freed staff in an organization that runs the world’s largest CA with a couple dozen people.

The catch with CRLs has always been size. A full list of every revoked serial across hundreds of millions of certificates is large, which is why CRLs fell out of favor in browsers years ago. The modern answer is on the browser side. Chrome’s CRLSets and Mozilla’s CRLite compress aggregated revocation data into a compact form that ships to the browser out of band, so the client checks revocation against a local structure instead of phoning home. The CA publishes CRLs, an intermediary compresses and distributes them, and the privacy-leaking real-time query disappears from the path. Revocation moved from a per-visit network call to a periodically-updated local lookup.

2025-2026: short-lived certificates and the road to 45 days

If expiry is the reliable safety mechanism and revocation is the unreliable one, the cleanest design is to make certificates expire so fast that revocation becomes almost irrelevant. That is the short-lived certificate, and Let’s Encrypt began rolling it out in 2025.

The announcement came in January 2025: an option for certificates with six-day lifetimes, plus the ability to put IP addresses in the subject alternative name field. The first six-day certificate was issued to Let’s Encrypt itself on February 20, 2025. A small set of early adopters got access around April, and the option reached general availability by the start of 2026. The exact validity is 160 hours, just over six days, and Let’s Encrypt recommends renewing every three days so a hiccup in one renewal cycle has slack before the cert expires. You select it through a certificate profile in your ACME client. None of this is usable without automation, which is the entire intent. A six-day certificate that you renew by hand is a part-time job. A six-day certificate that a daemon renews twice a cycle is invisible.

IP-address certificates are the other half of the January 2025 announcement, and they fill a real gap. You can now get a publicly-trusted certificate for an IP address as a subject alternative name, which previously was rare and expensive. The DNS-01 challenge is not available for IP validation for obvious reasons, since there is no zone to publish a TXT record in, so IP certs are validated through the HTTP and TLS-ALPN challenges.

The six-day cert is the aggressive opt-in edge. The broader, slower shift affects every certificate whether the operator opts in or not, and it comes from the CA/Browser Forum rather than from Let’s Encrypt alone. The Baseline Requirements that every publicly-trusted CA must follow are ratcheting maximum certificate lifetimes down on a published schedule. Let’s Encrypt’s own plan, posted in December 2025, walks the default certificate from 90 days toward 45. The tlsserver profile switches to 45-day certificates as an opt-in on May 13, 2026. The default classic profile drops to 64-day certificates on February 10, 2027, and then to 45-day certificates on February 16, 2028.

*Validity has fallen by more than two orders of magnitude in a decade. Each drop only became thinkable because the previous one had already forced automation to be the norm.*

There is a quieter number in the December 2025 plan that constrains tooling more than the headline lifetime does. The authorization reuse period, the window during which a successful domain validation can be reused for a new certificate without re-running the challenge, is being cut hard. It sits at 30 days today and is scheduled to drop to seven hours by 2028. That means a client cannot validate once and coast for a month. It has to be prepared to revalidate domain control almost every time it renews. For anyone operating fleets of certificates, the practical effect is that domain validation stops being an occasional event and becomes a near-continuous background process.

What the automation actually changed

The clean way to summarize Let’s Encrypt is that it made certificates free, and that is true, but the price was never the deepest part of the story. StartCom had free certificates in 2011 and it changed almost nothing, because a free certificate that still takes an hour to install and has to be redone by hand every year is not actually free. The cost that mattered was human attention, and ACME is the thing that drove that cost to zero. Free was necessary. Automated was the lever.

Once attention cost nothing, the rest followed by its own logic. A trust layer that renews itself can afford short lifetimes, because nobody has to do the renewing. Short lifetimes make revocation almost unnecessary, because a compromised certificate expires before the damage compounds. Almost-unnecessary revocation means the privacy-leaking OCSP responder can be switched off, taking 340 billion monthly disclosures of people’s browsing with it. And once the lifetime is short enough, the CA can keep ratcheting it down, six days, then push the whole ecosystem to 45, because the only thing standing in the way of a shorter cert was ever the human who had to renew it, and that human has been automated out of the loop.

The web that resulted is one where encryption is the default and the certificate is infrastructure nobody thinks about, which is exactly what infrastructure is supposed to be. The interesting consequence for anyone who watches traffic is that the padlock stopped meaning anything about the site behind it years ago. When every site, including every phishing page and every piece of malware command-and-control, can get a valid certificate in seconds for free, the certificate certifies control of a name and nothing more. That was always all it certified. Let’s Encrypt just made the fact impossible to ignore by handing the same automation to everyone at once.

Sources & further reading

Aas, Barnes, Case, Durumeric, Eckersley, Flores-López, Halderman, Hoffman-Andrews, Kasten, Rescorla, Schoen, Warren (2019), Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web — the team’s own ACM CCS paper, with the 2015 price table, the 538-million-cert figure, and the design rationale.
Barnes, Hoffman-Andrews, McCarney, Kasten (2019), RFC 8555: Automatic Certificate Management Environment (ACME) — the IETF standard that defines the protocol behind every ACME client and CA.
Let’s Encrypt (2024), Intent to End OCSP Service — the July 2024 announcement of the move from OCSP to CRLs and the privacy argument for it.
Let’s Encrypt (2024), Ending OCSP Support in 2025 — the detailed phase-out timeline with the January, May, and August 2025 milestones.
Let’s Encrypt (2025), OCSP Service Has Reached End of Life — the shutdown post, including the 340-billion-requests-per-month peak figure.
Let’s Encrypt (2025), Announcing Six Day and IP Address Certificate Options in 2025 — introduces short-lived certs and IP-address SANs.
Let’s Encrypt (2025), We Issued Our First Six Day Cert — the February 2025 milestone, with the 160-hour validity detail.
Let’s Encrypt (2025), Decreasing Certificate Lifetimes to 45 Days — the schedule walking the default cert from 90 to 64 to 45 days through 2028.
Let’s Encrypt (2025), Challenge Types — the canonical description of HTTP-01, DNS-01, and TLS-ALPN-01.
Wikipedia contributors (2026), Let’s Encrypt — consolidated timeline of founding dates, milestones, and scale figures with primary-source citations.
EFF (2023), Celebrating Ten Years of Encrypting the Web with Let’s Encrypt — retrospective from one of the founding organizations on the ten-year arc.
Mozilla Research (2025), The State of HTTPS Adoption on the Web — telemetry-based measurement of the climb past 80 percent of page loads.