On February 10, 2027, all Let’s Encrypt subscribers will move to certificates with 64 day lifetimes by default unless they select an even shorter lifetime (45 or 6 days, as previously announced). This means that any certificate we issue or renew on and after that date will have a 64 day validity period, and we expect the last 90-day certificate to expire on May 11, 2027. We will not revoke valid certificates as a part of this process.
We will switch to issuing 64 day certificates in our staging environment on October 14, 2026 to enable testing. We recommend testing in staging before the change takes effect in production.
If your renewals are automated and your client supports ACME Renewal Info (ARI), you should be all set since ARI allows Let’s Encrypt to tell your client when to renew (you can review your ACME client’s documentation to determine if ARI is implemented).
If your renewals are hard-coded to a date from expiration you should update them to renew at approximately ⅔ of the lifetime instead. Taking this step in preparation for 64 day lifetimes will lay the groundwork for default lifetimes of 45 days in 2028. Grep for common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks if you’re not sure.
We will also be reducing the authorization reuse period from 30 days to 10 days. In 2028, the reuse period will shrink to seven hours. We are making this change to comply with a 2029 reduction in maximum validation reuse periods, and to remove the need for “CAA rechecking”, where we have to repeat part of the validation process if the validation data is more than 7 hours old. Unless you have specifically designed your ACME client to rely on validation reuse, you will not need to make any changes.
This is also an opportunity to automate certificate management processes like reload and deployment and to add alerting for renewal failures.
Rate limits will not be impacted by this change; you can learn more in our previous blog post.
This change will not affect ACME endpoints or our issuance chains.
We are moving to shorter certificate lifetimes because this reduces the risk of key compromise and mis-issuance. As a nonprofit we see it as part of our mission to make this change to advance security for everyone using the Web globally. We anticipate a smooth transition, but if you experience issues, our community forum and documentation are good resources.
When the scripts that generate the data for letsencrypt.org/stats broke yet again, we decided to retire it rather than repair it. Let’s Encrypt issues six to ten million certificates each day, producing a large volume of logs that keeps growing. It became increasingly time-consuming and difficult to answer questions about our own issuance like “how many certificates use the ‘shortlived’ profile.” Using raw logs, this requires finding, parsing and extracting relevant portions of loglines. Querying the database behind our issuance API is not a practical option, as it’s built for transactions rather than analysis. We’d also used a log search SaaS product, but our bills were growing much faster than we’d like, and while it was fine for searching, it wasn’t able to do the analytic workloads we needed. We knew we could dream bigger and better.
Daily issuance of Let’s Encrypt certificates over the last 180 days
This led us to seek a self-hosted solution with efficient storage for structured data in addition to logs. We chose ClickHouse because of its potential as a data warehouse; the combination of cost-efficient storage and fast aggregation over large datasets appealed to us. A bonus of ClickHouse is that it is open source, a key principle valued by Let’s Encrypt.
The first step in building our new infrastructure was to purchase new hardware. To back our ClickHouse warehouse, we bought three PowerEdge R7715 servers. Each is equipped with a 32-core AMD EPYC 9355P 3.55GHz processor, 384 GB of RAM and 32 × 3.2TB NVMe drives, working out to roughly 100TB raw storage. With structured data and 100 days’ worth of logs already in our database, we are only at ~14% of total capacity, leaving lots of room for future growth.
Logs are the bulk of our storage use and the foundation of our structured data, as every other table we build is derived from them. When it comes to log search, ClickHouse covers our basic needs with quick ingest and interactive SQL. However, there are query ergonomics that we want to improve, like using OpenTechnology’s tracing features and ClickHouse’s tokenization settings.
Our primary target for structured data are our issuance records. A materialized view extracts those records from logs into their own table, and further views pre-aggregate from there. One such view counts issuance by day per profile. Now, questions like “what is our issuance by profile over the last 180 days” can be answered within milliseconds.
Daily issuance count of certificates by profile, excluding “classic”, over the last 180 days
We used this approach to completely rebuild the pipeline for our public stats page. The scripts we abandoned used to take hours each day to read and process dozens of compressed data files. The Rube-Goldberg-Machine-like collection of steps failed several times a year, requiring us to intervene and fix it. ClickHouse now computes those same stats in less than 10 seconds. Aside from pre-aggregated issuance tables, we can accomplish this because ClickHouse’s native functions are capable of quick and complex aggregations. Below is a simplified snippet of our materialized view for daily stats, counting the unique set of active domains over months across millions of rows. Two things to point out about this query: array handling means we can query nested fields without reshaping the underlying data, and uniq uses approximations to stay fast at scale.
Our ClickHouse issuance data also addresses the previous headache of identifying affected certificates during incidents. It used to take hours of engineer time to correctly scan and parse logs to find the affected set of serials or hours of computing time to return results from database queries, competing with production transactional load. Now, however, there is no log wrestling required, and because queries return quickly, we can iterate toward the right one in minutes rather than hours.
Not everything we needed came with ClickHouse. For scheduled reports, we built our own custom tool that queries ClickHouse and exports formatted results. It cost additional engineering time to design it to fit our needs, but we’ve seen payoffs already. Old reports were clunky to read and required chasing down context by hand. New reports, on the other hand, streamline security reviews via neat formatting and linking directly to relevant pages. The same reporting tool was repurposed for our revitalized stats pipeline as well.
The biggest challenge was backfilling data. While OTel collector handles live log ingestion well for us, it didn’t suit the task of backfilling historical logs. We couldn’t find throttling settings that handled the bulk import reliably – a large portion of files were silently dropped – and the alternative meant breaking up the import by hand. We instead switched to ClickHouse’s native S3 import method, standing up an S3-compatible gateway in front of our old logs to do so. While this avoided the earlier obstacles, this process required trial and error to match ingestion rules to OTel collector’s parsing to ensure the ingested logs matched regardless of whether they were backfilled or streamed in. Two lessons: don’t run bulk historical imports through a streaming collector, and match parsing rules across paths before you start.
One schema decision made these iterations cheap. For tables we anticipated requiring backfilling or recalculation, we deliberately chose the ReplacingMergeTree engine, so re-ingesting corrected rows simply replaced the old ones. This also came in handy for a materialized view computing aggregations across other rows. We got the calculations wrong more than once, and each time all we had to do was re-run the query rather than surgically remove bad rows. For tables without the engine, we did OPTIMIZE TABLE ... DEDUPLICATE BY, which was expensive, but only needed to be run once.
We hope that this is just the start, especially with our shorter certificate lifetimes and post-quantum certificates on the horizon. We plan to take full advantage of our new warehouse, extracting and pre-aggregating data that answers questions other teams care about, the way we did for issuance. Better analysis improves our operations and makes transparency cheaper, as our rebuilt stats page shows.
Daily certificate issuance stats since 2016
With powerful analytics in hand and only ~14% of our storage in use, we have room to store and analyze more than ever before.
Ten years ago, we printed one of the nerdiest t-shirts we’ve ever made. On the front was the entire PEM encoding of ISRG Root X1 in base64. Back then, it represented a future we were working toward. Today, that same design tells the story of just how far Let’s Encrypt has come.
Let’s Encrypt was already issuing publicly trusted certificates in 2016, but ISRG Root X1 itself was still slowly and quietly making its way into browsers and operating systems around the world. For many years, our certificates were trusted through a cross-sign from IdenTrust. ISRG Root X1 itself was added to the major trust stores fairly early on; the slow part was waiting for that update to reach the browsers and devices already out in the world, since many of them only get new trust stores when they’re updated. That took years.
I remember the day we generated Root X1 and the planning and careful execution involved. We all breathed a sigh of relief when it was done but knew that we were really just crossing the starting line since our goal was, and continues to be, to get the Web to 100% encryption.
— Josh Aas, Co-Founder and Executive Director, ISRG
The Internet’s Quiet Infrastructure
When you visit a website over HTTPS, your browser follows a chain of trust that ultimately leads back to a trusted root certificate, like Root X1. If everything is working correctly, the entire process is invisible. You see a secure connection and the cryptography quietly does its job.
When we started, 39% of page loads were encrypted. Today, in much of the world, it’s over 80%. Hundreds of millions of websites rely on Let’s Encrypt certificates every day. Most of the people using those websites will never know the name “ISRG Root X1,” and that’s exactly the point. What once required optimism and patience has become something billions of people depend on without even knowing it’s there.
The Same Design, A Different Meaning
That’s what made us want to bring it back. In 2016, it represented a goal. Looking back ten years later, we realized the same design had come to represent something entirely different.
Today, it represents a decade of work and support by engineers, contributors, sponsors, donors, and advocates who believed that secure communication on the web should be free, automated, and available to everyone. Their support helped make HTTPS the default, not a privilege.
If you have one of the few original shirts, let us know how it’s treating you by dropping a line to [email protected].
A Story Worth Wearing
Let’s Encrypt is run by Internet Security Research Group (ISRG), a nonprofit funded by the generosity of our community. Every certificate we issue and every new challenge we take on is made possible by people who believe the Internet should be more secure and privacy-respecting for everyone.
If you donate $75 or more this summer we’ll send you a limited-edition ISRG Root X1 t-shirt and you can help share our story.
Then you’ll have the chance to tell the story of how you support one small piece of Internet infrastructure that went from an ambitious idea to something a large part of the web quietly depends on every day.
Let’s Encrypt is committed to a post-quantum-safe Web PKI. The path we’re planning to take is Merkle Tree Certificates (“MTCs”), a new approach that adds post-quantum authentication to the web without sacrificing the speed and reliability that have made TLS universal.
This post is about these plans and why we believe MTCs are worth pursuing as a key to a post-quantum future.
An increasingly urgent problem
For much of the last several years, the conversation about post-quantum cryptography has been a conversation about encryption. The reasoning was straightforward: an attacker who records encrypted traffic today might be able to decrypt it years from now once quantum computers can break the underlying math. Authentication, the part of TLS that indicates a server is who it says it is, has been a less urgent problem. A quantum computer needs to forge a signature in real time, not retroactively, so threats to authentication hinge on the existence of a cryptographically relevant quantum computer (CRQC).
That comfort has been eroding for a while. In the United States, the NSA’s CNSA 2.0 suite has directed national security systems toward post-quantum algorithms on a 2030-to-2035 schedule since 2022, and NIST’s draft transition guidance would deprecate RSA-2048 and P-256 after 2030 and disallow them after 2035. The European Union’s roadmap targets high-risk systems by the end of 2030 and broad migration by 2035. These mandates don’t bind the public Web PKI directly, but they set the end-of-decade timeline that the vendors, libraries, and standards bodies it relies on are already working toward.
This year, the timeline shortened further. Google announced that it would migrate its services by 2029, citing tightening estimates for the potential arrival of a CRQC. Cloudflare followed with a parallel commitment. In addition, Go 1.27 adds ML-DSA, a NIST-standardized post-quantum signature scheme, to the standard library, a sign that post-quantum signatures are becoming practical infrastructure.
Post-quantum authentication is no longer a problem the Web PKI ecosystem should defer. Long-lived keys (root certificate authorities, code-signing keys, identity systems) are particularly valuable targets, and new technology takes years to gain broad adoption, so the work has to start early.
The Web PKI’s unique circumstances
The Web PKI is one of the trickiest places to deploy post-quantum signatures. The reason is size.
ML-DSA-44, one of the smaller NIST standardized post-quantum signature schemes, has a signature roughly 2,420 bytes long. The algorithms used in the Web PKI today are much smaller. RSA-2048 signatures are 256 bytes and ECDSA-P256 signatures are 64 bytes. Public keys are bigger as well: 1,312 bytes for ML-DSA-44, 256 bytes for RSA-2048, and 64 bytes for ECDSA-P256. A typical Web PKI handshake today carries five signatures and two public keys. Replacing those with ML-DSA equivalents would push a single TLS handshake well past 10 kilobytes. Cloudflare’s research has shown that, at that scale, a meaningful share of TLS connections fail on real-world networks, and the rest get slower.
Larger handshakes would affect every TLS connection, not just those that would fail. They would mean constrained bandwidth, slower connections, and a worse experience for users, all in exchange for security against a threat that hasn’t materialized yet. That’s a steep cost to enable by default, and defaults are what actually move security at web scale.
Merkle Tree Certificates
A different design called Merkle Tree Certificates (“MTCs”) has been emerging over the past year, and we believe it is a strong path forward for the post-quantum Web PKI.
Instead of issuing certificates one at a time and signing each one individually, an MTC certificate authority issues certificates in batches, with a single signature covering the entire batch. Browsers stay up to date on those batch signatures (called “landmarks”) separately from the TLS handshake.
In the common case, the entire authentication path in an MTC handshake is one signature, one public key, and one inclusion proof. That’s smaller than today’s Web PKI handshake, even though MTCs use post-quantum algorithms. The other case is the “standalone” form. It uses slightly larger handshakes as a fallback when a client’s landmark is out of date.
There is more to MTCs than size optimization. Because every certificate is part of a published Merkle tree, transparency becomes a property of issuance itself. Today’s Certificate Transparency ecosystem is bolted on after the fact: certificates are issued by CAs, then logged separately, with extra signatures riding along in the TLS handshake to attest to that logging. With MTCs, a certificate cannot exist outside the Merkle tree. Certificate Transparency is built in.
This is not entirely new ground for us. Let’s Encrypt has operated Certificate Transparency logs since 2019. Those logs are append-only Merkle trees, the same core data structure MTCs are built on, and ones we have run in production, at scale, for years.
Cloudflare and Chrome are already running a feasibility experiment with MTCs against real internet traffic. The IETF’s PLANTS working group is working on standardizing the design. Chrome has announced that MTCs are its preferred path for adding post-quantum certificates to the public web.
Our plans
We are planning to support Merkle Tree Certificates as the path forward for the post-quantum Web PKI. We are targeting late 2026 for a staging environment that issues MTCs, and 2027 for a production-ready environment.
This is not a small endeavor. Issuing MTCs at the scale of Let’s Encrypt requires meaningful changes throughout our stack: in our issuance infrastructure, in the ACME protocol our subscribers use to obtain certificates, in revocation and operational tooling, and in the transparency-log infrastructure that MTCs subsume. We have been participating in the IETF PLANTS and ACME working groups as the standards take shape.
Alongside the MTC work, we are tracking the standards for ML-DSA signatures in X.509 (RFC 9881) and TLS (draft-ietf-tls-mldsa), and the ecosystem work this depends on, like the addition of ML-DSA to the Go standard library. The Web PKI’s transition to post-quantum security needs all of this to land in browsers, libraries, and ACME clients, whether the certificates ultimately delivered are MTCs or ML-DSA signed X.509.
What this means if you use Let’s Encrypt
Nothing changes today. Your current Let’s Encrypt certificates will continue to be issued and renewed exactly as they always have been. When post-quantum certificates become available from Let’s Encrypt, they will arrive the way our service always has: free, automated, and available to anyone with an ACME client.
The transition will take time. There are standards still being finalized, root programs still defining their requirements, and engineering work that has to land in the broader ecosystem (browsers, libraries, ACME clients) before any of this matters at scale. We will keep the community informed as the work progresses and as the timelines firm up.
If you maintain an ACME client or run an ACME-driven certificate pipeline, this is a good moment to start tracking the work in the PLANTS working group and the discussions on the [email protected] mailing list. Some of the changes coming will require client-side support, and the ecosystem will benefit from clients that are ready when the issuance side is.
A note on the wider post-quantum transition
For the broader internet community: post-quantum encryption is the more urgent problem, because any TLS connection without post-quantum key exchange is potentially harvestable for later decryption. If you operate servers, please ensure they support hybrid post-quantum key exchange (X25519MLKEM768). Major browsers and operating systems already do, and turning it on at the server is one of the highest-leverage things you can do this year.
In closing
We have been building infrastructure for the public web since 2013 on the principle that security should be available to everyone, automatically, at no cost. The quantum transition is a generational change in how that security works under the hood.
Have you ever needed to make sure your website has a broken certificate? While many tools exist to help run an HTTPS server with valid certificates, there aren’t tools to make sure your certificate is revoked or expired. This is not a problem most people have. Tools to help manage certificates are always focused on avoiding those problems, not creating them.
Let’s Encrypt is a Certificate Authority, and so we have unusual problems we need to solve.
One of the requirements for publicly trusted Certificate Authorities is to host websites with test certificates, some of which need to be revoked or expired. This getsmessedup more than you might expect, but it’s a bit tricky to get right. Test certificate sites exist to allow developers to test their clients, so it’s important that they’re done right.
We’d previously used certbot, nginx, and some shell scripts, but the shell scripts were getting a bit too complicated. So we wrote a Go program tailored to the specific needs of a CA’s test certs site.
The websites
We need to host three sites per root certificate:
A valid certificate, like any other website.
An expired certificate, past its expiry date.
A revoked certificate, but it can’t be expired.
Valid is easy enough; it’s the normal case of any other website. This is a solved problem.
Expired, too, is pretty easy. Issue one certificate, wait until it expires, and then you can use it forever. Not a normal feature, but so long as your webserver doesn’t get upset at it being expired, it’s easy to set up once and leave it.
Revoked, though, is where it’s easiest to slip up. You could fail to revoke a certificate and serve a perfectly valid one, or you could let your revoked certificate expire. Making sure your website is serving a non-expired but revoked certificate is not something any of the off-the-shelf tools support.
The ingredients to bake a cake
In order to implement our program, we need a few different ingredients to mix together.
First and foremost, we need to be able to get certificates. Because we’re writing this in Go, we’re using Lego as a library to request the certificates. Obtaining a certificate requires completing a domain validation challenge. We can hook Lego up to the Go webserver we’re using to complete TLS-ALPN-01 validation. We use that challenge type because it doesn’t require any more setup beyond exposing our webserver to the internet.
To get a revoked certificate, we request a certificate and then revoke it. That’s something we can do with Lego and ACME too: The account which issued a certificate can request it be revoked. We then need a way to check that the certificate is revoked. Certificates contain an HTTP URL pointing to the Certificate Revocation List (CRL) which we poll until our certificate’s serial number appears in it.
Let’s Encrypt implements the ACME standard, which defines how clients can get certificates. In general, we think ACME clients integrated into webservers are often the best way to get certificates for websites. They can automatically handle challenges, managing and reloading certificates, and overall minimizing the amount of work and reducing problems.
We also need a way to wait until a certificate is in the right state. The valid certificate is ready to use right away, but that’s not true for the revoked and expired certificates. The revoked certificate needs to wait at least until it appears in a CRL, which can be up to an hour. Expired certificates need to wait even longer: Even if we request the shortest-lived certificates we offer, that’s still six days. To handle this, our program stores a “next” certificate instead of immediately overwriting the current one. We wait at least 24 hours for the revoked certificate to make sure any CRL caches or push-based CRL infrastructure have time to process the revocation. The expired certificate has to wait until it passes its expiration date. After the program decides a certificate is ready, it replaces the current certificate and passes it off to the webserver. Normal ACME tools don’t support this because they can usually start using a certificate as soon as it’s obtained.
And finally, we need a webserver to host the certificates. We’re using Go, which has a great built-in TLS and HTTP serving stack we can use. The Go TLS server takes a GetCertificate callback function that decides what certificate to use for each new connection. We have all our certificates in-memory and select the right one to serve based on the request’s SNI. This function is also where we hook up Lego to serve the challenge certificates required for TLS-ALPN-01. Because we prioritize serving the correct certificate over uptime, we refuse to handle a connection if the corresponding certificate is expired (unless it should be expired!).
Visiting the sites
If you visit one of our revoked sites, you might not get an error message. Revocation checking in browsers varies pretty widely, and has historically not worked great. Today’s state-of-the-art is Firefox’s CRLite, which is efficient and reliable. Ubuntu is deploying the same technology in their upki project. We hope other browsers and operating systems follow suit. The upki project is a great example of a project making use of these revoked test certificates, too.
The actual content of the website isn’t terribly important: We just have a little HTML page explaining what the site is. But since this website is meant for testing clients, there’s more than just browsers connecting. In particular, it’s pretty routine that I try connecting with curl or some other terminal http client, and getting a bunch of HTML spewed to your terminal isn’t very nice.
As a small easter egg, we added a plain text version of the website with an ASCII art version of our logo that we serve if your HTTP client doesn’t include text/html in its Accept HTTP header. You can pass a ?txt or ?html URL parameter to specifically request one or the other version of the content, if you just want to see the ASCII art.
Let’s Encrypt has four root certificates right now. Each of them have test sites linked both here and from our documentation.
As with a lot of Let’s Encrypt, the code for this project is open-source. You can find it at https://github.com/letsencrypt/test-certs-site/. Other Certificate Authorities who need to run similar test certificate sites are welcome to use it. If you need any features that would make using our test certs site easier for your TLS/HTTPS client testing, please feel free to create an issue on that repository.
Nick Silverman is a Senior Infrastructure Engineer on the Edge Infrastructure team at Shopify, where he maintains the systems that provision, renew, and publish SSL certificates for millions of merchants’ custom domains. He is also a contributor to the Ruby acme-client gem.
The challenge
Shopify’s automated certificate management system relied on a static renewal threshold: 30 days before the end of the 90-day lifetime. To spread the load of provisioning and renewing certificates, we implemented a random 0–72 hour delay for each. While this helps evenly distribute certificate management over time, it did not take into account the Certificate Authority’s (CA) load. It was also incapable of reacting to a dynamic renewal window based on information provided by the CA.
However, this approach needed greater resilience to solve what is, in the end, a distributed coordination problem. The weaknesses are:
No rapid revocation response: The static logic is not aware of revocations at all.
Imperfect load distribution: Despite the random jitter, massive renewal bursts could still occur.
Shopify needed to develop a global coordination system to balance the load and handle regular and urgent renewals. Thankfully, Let’s Encrypt has led the charge on a solution for this and other very important aspects of the certificate lifecycle.
The journey
Let’s Encrypt and the Internet Engineering Task Force (IETF) published the ACME Renewal Information (ARI) standard which makes an endpoint available that provides a recommended window of time for the renewal to occur. The endpoint returns a payload that looks something like this:
GET /renewal-info/ACME_KEY_IDENTIFIER
{"suggestedWindow": {"start": "2026-02-03T04:00:00Z",
"end": "2026-02-04T04:00:00Z"}}
Shopify’s certificate management system uses the acme-client Ruby gem originally authored by another Shopify employee. A growing number of ACME clients, including certbot, have enabled support for ARI, but the Ruby gem did not yet support this feature. Rather than building a custom solution, we decided to enable support for the ARI extension directly in the client.
Let’s Encrypt’s guide to integrating ARI provided the necessary roadmap, and the implementation was completed with one PR. This contribution means that not only Shopify, but also the wider Ruby community, can benefit from the ARI extension.
Deployment and ARI at scale
Once we shipped the gem support, integrating ARI into our certificate management system was straightforward. Instead of checking a static 30-day threshold, we now query the ARI endpoint and use the suggested renewal window as the gate for initiating renewals. Those dates are stored alongside the certificate upon its initial provisioning.
The updated Ruby gem provides a method for fetching renewal information:
This method generates an ARI certificate identifier that can be used when making the API call. The client also includes a helper method, suggested_renewal_time, which chooses a random time between the returned start and end dates. The certificate identifier can be passed to the new_order method via the replaces key, which can grant a higher priority or bypass rate limits for renewals occurring during the window, depending on the CA’s policies.
Critically, Shopify also regularly polls the ARI endpoint for updated renewal timestamps. This allows our systems to rely on those timestamps as the primary renewal timing logic and removes the need for inflexible hard-coded expiry thresholds. This becomes the mechanism that LetsEncrypt uses to dynamically change the renewal time due to a revocation event.
Results and rewards
Since enabling the use of the ARI extension, our certificate management system has become significantly more robust. Shopify now delegates the responsibility of determining renewal timing to Let’s Encrypt. The ARI extension has proven to be an impactful infrastructure improvement and the benefits gained are immediate. These benefits, alongside fewer manual interventions, are the operational success story:
Future-proofing: We gained resilience against any future certificate lifetime changes and mass revocation events without needing code updates—ensuring our renewal logic is flexible.
Optimized load: We directly benefit from the CA’s coordinated load balancing provided by the suggested renewal window, eliminating local randomness issues and the need for complex global coordination.
Revocation readiness: ARI allows systems to quickly detect and respond to revocation events when an urgent renewal is necessary, well before certificates get close to their due dates.
Simple implementation: The extension is mature (RFC 9773) and the implementation is straightforward, providing simplified renewal logic and CA-optimized timing.
Good citizenship: Anyone using ARI helps the CA optimize its infrastructure, and contributes to better aggregate behavior across the entire ecosystem.
If you’re still relying on static renewal thresholds, give ARI a look—Shopify wholeheartedly encourages all ACME users and client developers to adopt the ARI extension.
As we announced earlier this year, Let’s Encrypt now issues IP address and six-day certificates to the general public. The Certbot team at the Electronic Frontier Foundation has been working on two improvements to support these features: the --preferred-profile flag released last year in Certbot 4.0, and the --ip-address flag, new in Certbot 5.3. With these improvements together, you can now use Certbot to get those IP address certificates!
If you want to try getting an IP address certificate using Certbot, install version 5.4 or higher (for webroot support with IP addresses), and run this command:
This will request a non-trusted certificate from the Let’s Encrypt staging server. Once you’ve got things working the way you want, run without the --staging flag to get a publicly trusted certificate.
This requests a certificate with Let’s Encrypt’s “shortlived” profile, which will be good for 6 days. This is a Let’s Encrypt requirement for IP address certificates.
As of right now, Certbot only supports getting IP address certificates, not yet installing them in your web server. There’s work to come on that front. In the meantime, edit your webserver configuration to load the newly issued certificate from /etc/letsencrypt/live/<ip address>/fullchain.pem and /etc/letsencrypt/live/<ip address>/privkey.pem.
The command line above uses Certbot’s “webroot” mode, which places a challenge response file in a location where your already-running webserver can serve it. This is nice since you don’t have to temporarily take down your server.
There are two other plugins that support IP address certificates today: --manual and --standalone. The manual plugin is like webroot, except Certbot pauses while you place the challenge response file manually (or runs a user-provided hook to place the file). The standalone plugin runs a simple web server that serves a challenge response. It has the advantage of being very easy to configure, but has the disadvantage that any running webserver on port 80 has to be temporarily taken down so Certbot can listen on that port. The nginx and apache plugins don’t yet support IP addresses.
You should also be sure that Certbot is set up for automatic renewal. Most installation methods for Certbot set up automatic renewal for you. However, since the webserver-specific installers don’t yet support IP address certificates, you’ll have to set a --deploy-hook that tells your webserver to load the most up-to-date certificates from disk. You can provide this --deploy-hook through the certbot reconfigure command using the rest of the flags above.
We hope you enjoy using IP address certificates with Let’s Encrypt and Certbot, and as always if you get stuck you can ask for help in our Community Forum.
As previously announced, over the next two years we will be switching the default certificate lifetime from 90 days to 64 days, and then 45 days. This will ultimately double the number of certificate renewal requests each day: today we expect renewal around day 60 (of a 90-day certificate), while in the future we expect renewal around day 30 (of a 45-day certificate). If you use an ACME client that supports ARI, this will happen automatically.
The good news for subscribers is that you don’t need any changes to your rate limits, whether you are using our default limits or have requested an override. Our rate limits affect issuance for new domain names (or groups of domain names), but renewals are exempt. So, for instance, if you are managing a set of 15,000 certificates that you continually renew, and create 250 new certificates (with new domain names) each day, you will be well within our limits both before and after the transition. The 250 new certificates daily will still be well under our New Orders per Account limit of 300 per day. And the 15,000 existing certificates will continue to be unaffected by rate limits, whether your ACME client is renewing them every sixty days or every thirty.
When you request a certificate from Let’s Encrypt, our servers validate that you control the hostnames in that certificate using ACME challenges. For subscribers who need wildcard certificates or who prefer not to expose infrastructure to the public Internet, the DNS-01 challenge type has long been the only choice. DNS-01 works well. It is widely supported and battle-tested, but it comes with operational costs: DNS propagation delays, recurring DNS updates at renewal time, and automation that often requires distributing DNS credentials throughout your infrastructure.
We are implementing support for a new ACME challenge type, DNS-PERSIST-01, based on a new IETF draft specification. As the name implies, it uses DNS as the validation mechanism, but replaces repeated demonstrations of control with a persistent authorization record bound to a specific ACME account and CA. The draft describes this method as being “particularly suited for environments where traditional challenge methods are impractical, such as IoT deployments, multi-tenant platforms, and scenarios requiring batch certificate operations”.
DNS-01 Proves Control Repeatedly
With DNS-01, validation relies on a one-time token generated by us. Your ACME client publishes a TXT record containing that token at _acme-challenge.<YOUR_DOMAIN>, and we query DNS to confirm that it matches the expected value. Because each authorization requires a new token, DNS updates become part of the issuance workflow. The benefit is that each successful validation provides fresh proof that you currently control DNS for the name being issued.
In practice, this often means DNS API credentials live somewhere in your issuance pipeline, validation attempts involve waiting for DNS propagation, and DNS changes happen frequently — sometimes many times per day in large deployments. Many subscribers accept these tradeoffs, but others would prefer to keep DNS updates and sensitive credentials out of their issuance path.
DNS-PERSIST-01 Authorizes Persistently
DNS-PERSIST-01 approaches validation differently. Instead of publishing a new challenge record for each issuance, you publish a standing authorization in the form of a TXT record that identifies both the CA and the specific ACME account you authorize to issue for this domain.
For the hostname example.com, the record would live at _validation-persist.example.com:
Once this record exists, it can be reused for new issuance and all subsequent renewals. Operationally, this removes DNS changes from the critical path.
Security and Operational Tradeoffs
With DNS-01, the sensitive asset is DNS write access. In many deployments, DNS API credentials are distributed throughout issuance and renewal pipelines, increasing the number of places an attacker might compromise them. DNS-PERSIST-01 instead binds authorization directly to an ACME account, allowing DNS write access to remain more tightly controlled after initial setup. The tradeoff is that, because the authorization record persists over time, protecting the ACME account key becomes the central concern.
Controlling Scope and Lifetime
DNS-PERSIST-01 also introduces explicit scope controls. Without additional parameters, authorization applies only to the validated Fully Qualified Domain Name (FQDN) and remains valid indefinitely.
Wildcard Certificates
Adding policy=wildcard broadens the authorization scope to include the validated FQDN, wildcard certificates such as *.example.com, and subdomains whose suffix matches the validated FQDN:
Subscribers who aren’t comfortable with authorization persisting indefinitely can include an optional persistUntil timestamp. This limits how long the record may be used for new validations, but also means it must be updated or replaced before it expires. Anyone using this feature should ensure they have adequate reminders or monitoring in place so that authorization does not expire unexpectedly. The timestamp is expressed as UTC seconds since 1970-01-01:
Multiple CAs can be simultaneously authorized by publishing multiple TXT records at _validation-persist.<YOUR_DOMAIN>, each containing the issuer-domain-name of the CA you intend to authorize. During validation, each CA queries the same DNS label and evaluates only the records that match its own issuer-domain-name.
Rollout Timeline
The CA/Browser Forum ballot SC-088v3, defining “3.2.2.4.22 DNS TXT Record with Persistent Value”, passed unanimously in October 2025, and the IETF ACME working group adopted the draft that same month. While the document remains an active IETF draft, the core mechanisms described here are not expected to change substantially.
Support for the draft specification is available now in Pebble, a miniature version of Boulder, our production CA software. Work is also in progress on a lego-cli client implementation to make it easier for subscribers to experiment with and adopt. Staging rollout is planned for late Q1 2026, with a production rollout targeted for some time in Q2 2026.
In a recent conversation with a Let’s Encrypt subscriber, we asked them to guess how many people work at ISRG, the nonprofit behind Let’s Encrypt (and Prossimo and Divvi Up). Their guess was about 100; they’d overestimated by 72.5 people. We’re a pretty small team, and we get a lot done, but most of that work is entirely remote, distributed, and automated.
That is a big part of what makes FOSDEM special. For the last few years, we’ve had a stand at this annual conference in Belgium, where a few folks from our team have the opportunity to speak directly with thousands of conference-goers. We continue to learn so much from these conversations!
That’s where the “Hello” part of this blog post comes in. At this year’s FOSDEM, we met so many Let’s Encrypt subscribers, and each of them has a unique relationship to Let’s Encrypt. We were pleasantly surprised by how many people told us they were using IP-address certificates, a new option we just made generally available in December. We had a lot of conversations about our plans to shorten certificate lifetimes. There were a few folks who asked about S/MIME (still no plans to do that). We invited people to continue to stay in touch by signing up for our newsletter.
The most meaningful part of FOSDEM is being able to say “thank you”. Our goal in starting Let’s Encrypt was to improve security and privacy for people using the internet, but that could not be achieved without the now millions of folks who decided to get a certificate. Our impact is predicated on this symbiotic exchange. While we were only able to directly express our gratitude to a few thousand people at FOSDEM, it was a reminder of how important the community is.
Short-lived and IP address certificates are now generally available from Let’s Encrypt. These certificates are valid for 160 hours, just over six days. In order to get a short-lived certificate subscribers simply need to select the ‘shortlived’ certificate profile in their ACME client.
Short-lived certificates improve security by requiring more frequent validation and reducing reliance on unreliable revocation mechanisms. If a certificate’s private key is exposed or compromised, revocation has historically been the way to mitigate damage prior to the certificate’s expiration. Unfortunately, revocation is an unreliable system so many relying parties continue to be vulnerable until the certificate expires, a period as long as 90 days. With short-lived certificates that vulnerability window is greatly reduced.
Short-lived certificates are opt-in and we have no plan to make them the default at this time. Subscribers that have fully automated their renewal process should be able to switch to short-lived certificates easily if they wish, but we understand that not everyone is in that position and generally comfortable with this significantly shorter lifetime. We hope that over time everyone moves to automated solutions and we can demonstrate that short-lived certificates work well.
Our default certificate lifetimes will be going from 90 days down to 45 days over the next few years, as previously announced.
IP address certificates allow server operators to authenticate TLS connections to IP addresses rather than domain names. Let’s Encrypt supports both IPv4 and IPv6. IP address certificates must be short-lived certificates, a decision we made because IP addresses are more transient than domain names, so validating more frequently is important. You can learn more about our IP address certificates and the use cases for them from our post announcing our first IP Certificate.
We’d like to thank the Open Technology Fund and Sovereign Tech Agency, along with our Sponsors and Donors, for supporting the development of this work.
This year was the 10th anniversary of Let’s Encrypt. We’ve come a long way! Today we’re serving more than 700 million websites, issuing ten million certificates on some days. Most importantly, when we started 39% of page loads on the Internet were encrypted. Today, in many parts of the world, over 95% of all page loads are encrypted. We can’t claim all the credit for that, but we’re proud of the leading role we played. Being able to help ISRG and Let’s Encrypt get to where we are today has been the opportunity of a lifetime for me.
There’s more I could talk about from the past ten years, but this 10th year was about as good as any before it so I want to focus on our most recent work. I’ll get the headline for 2025 out right away: over the past year we went from serving 492 million websites to 762 million. That’s a 50% increase in a single year, equivalent to the growth we saw over our first six years of existence combined. Our staff did an amazing job accommodating the additional traffic.
I’m also particularly proud of the things we did to improve privacy this year, across all of our projects.
At the start of 2025 we were serving over four billion Online Certificate Status Protocol (OCSP) requests per day. That’s 180 million per hour, or 50,000 per second. OCSP has been an important mechanism for providing certificate revocation information for a long time, but the way it works is bad for privacy. It requires browsers to check with certificate authorities for every website they visit, which is basically providing your browsing history to third parties. Let’s Encrypt never held onto that data; it got dropped immediately. However, there is no way to know if that was standard practice across the industry, and even well-intentioned CAs could make a mistake or be compelled to save that data. It was a system ripe for abuse, so we decided to become the first major CA to turn off our OCSP service. We couldn’t be sure what the full impact would be, but this was a way in which the Internet needed to get better. In August of 2025 we turned off our OCSP service. There was no major fallout and we haven’t looked back.
Another big privacy-focused change we made to Let’s Encrypt in 2025 was no longer storing subscriber email addresses in our CA database, associated with issuance data. In June of this year we stopped adding the optional email addresses that subscribers send to our database, and we deleted the millions of email addresses that had accumulated over the years. Making this change was not an easy thing to decide to do—it limits our ability to contact subscribers and we had to turn off our expiration reminder email service—but we feel the ecosystem has grown enough over the past ten years that the privacy implications of holding onto the email addresses outweighed the utility.
Privacy was at the forefront for the folks at ISRG researching human digital identity as well. They have been hard at work on an implementation of the Anonymous Credentials from ECDSA scheme, also known as Longfellow. This is a cryptographic library that can be used in digital identity management, including things like digital wallets, in order to improve privacy when sharing credentials. Digital identity systems should have strong privacy and compatibility requirements, but such requirements pose challenges that existing digital credential technologies are going to struggle to meet. New schemes such as Longfellow aim to address these challenges, bringing privacy improvements to systems that need to work with existing cryptographic hardware. This is exciting stuff, but not easy to build (so much math!)—watching our talented engineers make progress has been thrilling.
The last example of great privacy work I want to highlight from 2025 is our Prossimo project’s work towards encrypted recursive-to-authoritative DNS. Prossimo is focused on bringing memory safety to critical software infrastructure, but sometimes that dovetails nicely with other initiatives. DNS queries are fundamental to the operation of the Internet. Without getting into the details here too much, there are basically two types of DNS queries: stub-to-recursive and recursive-to-authoritative. A lot of work has gone into encrypting stub queries over the past decade, mostly through DNS over HTTPS (DoH) initiatives. Authoritative queries, however, remain almost entirely unencrypted. This is a particular problem for Certificate Authorities like Let’s Encrypt. During 2025, our Prossimo project started work on changing that, investing heavily in encrypted authoritative resolution by implementing RFC 9539 Unilateral Opportunistic Deployment of Encrypted Recursive‑to‑Authoritative DNS and other related improvements in Hickory DNS. Once this is ready, early in 2026, Hickory DNS will be a high performance and memory safe option that DNS operators can use to start making and receiving encrypted authoritative DNS queries. It can also be used for integration testing with other DNS implementations.
It’s wonderful, and a real responsibility, to be able to have this kind of positive impact on the lives of everyone using the Internet. Charitable contributions from people like you and organizations around the world make what we do possible. We are particularly grateful to Jeff Atwood, Betsy Burton, and Stina Ehrensvärd for their special gifts this year. Since 2015, tens of thousands of people have donated. They’ve made a case for corporate sponsorship, given through their DAFs, or set up recurring donations. If you’re one of those people, thank you. If you’re considering becoming a supporter, I hope this annual report will make the case that we’re making every dollar count.
Every year we aim to make the dollars entrusted to us go as far as possible, and next year will be no exception.
On September 14, 2015, our first publicly-trusted certificate went live. We were proud that we had issued a certificate that a significant majority of clients could accept, and had done it using automated software. Of course, in retrospect this was just the first of billions of certificates. Today, Let’s Encrypt is the largest certificate authority in the world in terms of certificates issued, the ACME protocol we helped create and standardize is integrated throughout the server ecosystem, and we’ve become a household name among system administrators. We’re closing in on protecting one billion web sites.
In 2023, we marked the tenth anniversary of the creation of our nonprofit, Internet Security Research Group, which continues to host Let’s Encrypt and other public benefit infrastructure projects. Now, in honor of the tenth anniversary of Let’s Encrypt’s public certificate issuance and the start of the general availability of our services, we’re looking back at a few milestones and factors that contributed to our success.
Growth
A conspicuous part of Let’s Encrypt’s history is how thoroughly our vision of scalability through automation has succeeded.
In March 2016, we issued our one millionth certificate. Just two years later, in September 2018, we were issuing a million certificates every day. In 2020 we reached a billion total certificates issued and as of late 2025 we’re frequently issuing ten million certificates per day. We’re now on track to reach a billion active sites, probably sometime in the coming year. (The “certificates issued” and “certificates active” metrics are quite different because our certificates regularly expire and get replaced.)
The steady growth of our issuance volume shows the strength of our architecture, the validity of our vision, and the great efforts of our engineering team to scale up our own infrastructure. It also reminds us of the confidence that the Internet community is placing in us, making the use of a Let’s Encrypt certificate a normal and, dare we say, boring choice. But I often point out that our ever-growing issuance volumes are only an indirect measure of value. What ultimately matters is improving the security of people’s use of the web, which, as far as Let’s Encrypt’s contribution goes, is not measured by issuance volumes so much as by the prevalence of HTTPS encryption. For that reason, we’ve always emphasized the graph of the percentage of encrypted connections that web users make (here represented by statistics from Firefox).
(These graphs are snapshots as of the date of this post; a dynamically updated version is found on our stats page.) Our biggest goal was to make a concrete, measurable security impact on the web by getting HTTPS connection prevalence to increase—and it’s worked. It took five years or so to get the global percentage from below 30% to around 80%, where it’s remained ever since. In the U.S. it has been close to 95% for a while now.
A good amount of the remaining unencrypted traffic probably comes from internal or private organizational sites (intranets), but other than that we don’t know much about it; this would be a great topic for Internet security researchers to look into.
We believe our present growth in certificate issuance volume is essentially coming from growth in the web as a whole. In other words, if we protect 20% more sites over some time period, it’s because the web itself grew by 20%.
Along the way, first issuing one million certificates in a single day (in September 2018), significantly contributed to by the SquareSpace and Shopify Let’s Encrypt integrations
Just at the end of September 2025, we issued more than ten million certificates in a day for the first time.
There are many technical milestones like our database server upgrades in 2021, where we found we needed a serious server infrastructure boost because of the tremendous volumes of data we were dealing with. Similarly, our original infrastructure was using Gigabit Ethernet internally, and, with the growth of our issuance volume and logging, we found that our Gigabit Ethernet network eventually became too slow to synchronize database instances! (Today we’re using 25-gig Ethernet.) More recently, we’ve experimented with architectural upgrades to our ever-growing Certificate Transparency logs, and decided to go ahead with deploying those upgrades—to help us not just keep up with, but get ahead of, our continuing growth.
These kinds of growing pains and successful responses to them are nice to remember because they point to the inexorable increase in demands on our infrastructure as we’ve become a more and more essential part of the Internet. I’m proud of our technical teams which have handled those increased demands capably and professionally.
I also recall the ongoing work involved in making sure our certificates would be as widely accepted as possible, which has meant managing the original cross-signature from IdenTrust, and subsequently creating and propagating our own root CA certificates. This process has required PKI engineering, key ceremonies, root program interactions, documentation, and community support associated with certificate migrations. Most users never have reason to look behind the scenes at our chains of trust, but our engineers update it as root and intermediate certificates have been replaced. We’ve engaged at the CA/B Forum, IETF, and in other venues with the browser root programs to help shape the web PKI as a technical leader.
As I wrote in 2020, our ideal of complete automation of the web PKI aims at a world where most site owners wouldn’t even need to think about certificates at all. We continue to get closer and closer to that world, which creates a risk that people will take us and our services for granted, as the details of certificate renewal occupy less of site operators’ mental energy. As I said at the time,
When your strategy as a nonprofit is to get out of the way, to offer services that people don’t need to think about, you’re running a real risk that you’ll eventually be taken for granted. There is a tension between wanting your work to be invisible and the need for recognition of its value. If people aren’t aware of how valuable our services are then we may not get the support we need to continue providing them.
I’m also grateful to our communications and fundraising staff who help make clear what we’re doing every day and how we’re making the Internet safer.
Recognition of Let’s Encrypt
Our community continually recognizes our work in tangible ways by using our certificates—now by the tens of millions per day—and by sponsoring us.
Ten years later, I’m still deeply grateful to the five initial sponsors that got Let’s Encrypt off the ground – Mozilla, EFF, Cisco, Akamai, and IdenTrust. When they committed significant resources to the project, it was just an ambitious idea. They saw the potential and believed in our team, and because of that we were able to build the service we operate today.
IdenTrust: A critical technical partner
I’d like to particularly recognize IdenTrust, a PKI company that worked as a partner from the outset and enabled us to issue publicly-trusted certificates via a cross-signature from one of their roots. We would simply not have been able to launch our publicly-trusted certificate service without them. Back when I first told them that we were starting a new nonprofit certificate authority that would give away millions of certificates for free, there wasn’t any precedent for this arrangement, and there wasn’t necessarily much reason for IdenTrust to pay attention to our proposal. But the company really understood what we were trying to do and was willing to engage from the beginning. Ultimately, IdenTrust’s support made our original issuance model a reality.
Conclusion
I’m proud of what we have achieved with our staff, partners, and donors over the past ten years. I hope to be even more proud of the next ten years, as we use our strong footing to continue to pursue our mission to protect Internet users by lowering monetary, technological, and informational barriers to a more secure and privacy-respecting Internet.
Let’s Encrypt is a project of the nonprofit Internet Security Research Group, a 501(c)(3) nonprofit. You can help us make the next ten years great as well by donating or becoming a sponsor.
Let’s Encrypt will be reducing the validity period of the certificates we issue. We currently issue certificates valid for 90 days, which will be cut in half to 45 days by 2028.
This change is being made along with the rest of the industry, as required by the CA/Browser Forum Baseline Requirements, which set the technical requirements that we must follow. All publicly-trusted Certificate Authorities like Let’s Encrypt will be making similar changes. Reducing how long certificates are valid for helps improve the security of the internet, by limiting the scope of compromise, and making certificate revocation technologies more efficient.
We are also reducing the authorization reuse period, which is the length of time after validating domain control that we allow certificates to be issued for that domain. It is currently 30 days, which will be reduced to 7 hours by 2028.
Timeline of Changes
To minimize disruption, Let’s Encrypt will roll this change out in multiple stages. We will use ACME Profiles to allow you control over when these changes take effect. They are configured in your ACME client. For more information, see our blog post announcing them.
Changes will be deployed to our staging environment approximately one month before the production dates below.
May 13, 2026: Let’s Encrypt will switch our tlsserver ACME profile to issue 45-day certificates. This profile is opt-in and can be used by early adopters and for testing.
February 10, 2027: Let’s Encrypt will switch our default classic ACME profile to issuing 64-day certificates with a 10-day authorization reuse period. This will affect all users who have not opted into the tlsserver or shortlived (6-day) profiles.
February 16, 2028: We will further update the classic profile to issue 45-day certificates with a 7 hour authorization reuse period.
These dates are when the change takes effect for new certificates, so Let’s Encrypt users will see the reduced certificate validity period at their next renewal after these dates.
Action Required
Most users of Let’s Encrypt who automatically issue certificates will not have to make any changes. However, you should verify that your automation is compatible with certificates that have shorter validity periods.
To ensure your ACME client renews on time, we recommend using ACME Renewal Information (ARI). ARI is a feature we’ve introduced to help clients know when they need to renew their certificates. Consult your ACME client’s documentation on how to enable ARI, as it differs from client to client. If you are a client developer, check out this integration guide.
If your client doesn’t support ARI yet, ensure it runs on a schedule that is compatible with 45-day certificates. For example, renewing at a hardcoded interval of 60 days will no longer be sufficient. Acceptable behavior includes renewing certificates at approximately two thirds of the way through the current certificate’s lifetime.
Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes.
We also recommend that you make sure your systems have sufficient monitoring in place to alert appropriately if certificates aren’t renewed when expected. There are many available options, some of which are documented on our Monitoring Service Options page.
Making Automation Easier with a new DNS Challenge Type
For many of our users, the hardest part of automatically issuing certificates is proving domain control. Reducing certificate lifetimes and the authorization reuse period will make users need to demonstrate control more often.
All validation methods today require that the ACME client have live access to your infrastructure, either to serve the correct HTTP-01 token, perform the right TLS-ALPN-01 handshake, or update the right DNS-01 TXT record. For a long time, people have wanted a way to run an ACME client without granting it access to these sensitive systems.
These challenges are why we are working with our partners at the CA/Browser Forum and IETF to standardize a new validation method called DNS-PERSIST-01. The key advantage of this new method is that the DNS TXT entry used to demonstrate control does not have to change every renewal.
This means you can set up the DNS entry once and begin automatically renewing certificates without needing a way to automatically update DNS. This should allow even more people to automate their certificate renewals. It will also reduce reliance on authorization reuse, since the DNS records can stay unchanged without any further ACME client involvement.
We expect DNS-PERSIST-01 to be available in 2026, and will have more to announce soon.
Keep Up to Date
Additional updates, reminders, and other changes will be shared on our technical updates mailing list. Subscribe to keep up-to-date with these and all other upcoming changes. If you have any questions, please ask on our community forum. If you want to read more about the work happening at Let’s Encrypt and our other projects, check out our Annual Report, which was published today.
In a ceremony held in September, Let’s Encrypt generated two new Root Certification Authorities (CAs) and six new Intermediate CAs, which we’re collectively calling the “Generation Y” hierarchy. Now we’re moving to begin issuing certificates from this new hierarchy, and to submit it to various root programs for inclusion in their trust stores.
The two new roots look very similar to our existing roots. The new ISRG Root YR has an RSA 4096 key and is valid for twenty years, just like ISRG Root X1. Similarly, the new ISRG Root YE has an ECDSA P-384 key, just like ISRG Root X2. We’ve made a few adjustments (for example, replacing “Internet Security Research Group” with “ISRG” to save a few bytes), but nothing major. Each of these new roots is intended to eventually replace its corresponding predecessor, and to that end we have cross-signed the new roots from the old ones.
The six new intermediates consist of three intermediates each issued from each of the two new roots. ISRG Root YE has issued the YE1, YE2, and YE3 intermediates, while ISRG Root YR has issued the YR1, YR2, and YR3 intermediates. These have two key differences from our current crop of issuing intermediates. First, their names: we’re now numbering intermediates under each root sequentially, rather than using the same numbering sequence across all intermediates. This makes it slightly easier to keep track of which intermediates are currently in use, and prepares for a possible post-quantum future where we have additional key types.
Second and more importantly: these intermediates do not contain the “TLS Web Client Authentication” Extended Key Usage. This means that these intermediates cannot issue end-entity certificates containing that EKU. As we’ve already announced, we will be phasing out issuance of tlsClientAuth certificates in 2026 due to a root program requirement. Until that time, we will only be using the new hierarchy to issue certificates under the “tlsserver” and “shortlived” profiles, which already omit that EKU. After the tlsClientAuth deprecation is complete, we will shift to using the new intermediates for all issuance.
If you’re requesting the tlsserver or shortlived profile, you can expect to see issuance from (the Staging equivalent of) the new hierarchy as of today. We expect to make the same change in our Production environment next month. As before, each issuance will choose which intermediate to use at random, to discourage intermediate key pinning.
We’ll be submitting the new roots for inclusion in the Apple, Chrome, Microsoft, Mozilla, and other root programs shortly thereafter. We look forward to updating you again when the new hierarchy is officially included in those trust stores!
Seth Schoen was an early contributor to Let’s Encrypt through his work at the Electronic Frontier Foundation. He’s also one of the longest standing participants in the Let’s Encrypt community support forum, so we asked him to offer his thoughts on the role and impact of the forum as a resource for our users. Thank you for your many years of expertise and participation, Seth!
Along with the tenth anniversary of Let’s Encrypt’s first certificate, we’re also celebrating ten years of the Let’s Encrypt Community Forum, which has played a vital role in the Let’s Encrypt community.
It’s happened in many different languages (including official French, Spanish, and Portuguese categories, use of numerous volunteers’ native languages, as well as many successful conversations via machine translation). For example, people have gotten help in Dutch, Russian, German, and Chinese.
Thousands of volunteers have provided help and successfully helped tens of thousands of users get their certificates. Occasionally, they’ve also reported bugs in client software, documentation, or even the Let’s Encrypt service itself. Many times a responsible developer was there to interact directly with the bug reporter.
Here are the monthly pageviews from the creation of the Community Forum until the present day:
Other reports from the forum software show that much of the most recent pageview growth is due to robots, probably from AI training. But that may ultimately be helpful to users too, as AI systems learn about Let’s Encrypt from the forum posts and become more able to answer users’ questions correctly.
Seeing the results of one’s efforts
The most common kind of interaction on the forum is one in which a Let’s Encrypt end user shows up with some kind of problem, usually an inability to get or renew a certificate. In most cases, if the user is willing to answer some questions, the community is ultimately able to resolve the problem.
I’ve often compared the satisfaction of helping users on the Let’s Encrypt forum to what I felt while installing bike lights at a local cycling organization’s bike light giveaway event. In both cases, one could engage for a few minutes with someone, maybe deal with some unanticipated oddities (extra-thick handlebars? an unusual seat post or cargo rack? a strange DNS setup? an unusual Apache configuration?). Usually, this would lead to a concrete practical improvement in safety afterward (the blinking red tail light freshly installed on someone’s bike, or the lovely https:// prefix or padlock icon newly visible in the browser bar when browsing to a visitor’s website). It’s common in the Internet security world not to be able to see or appreciate how what we do helps people, so “we just helped make connections to your specific web site more secure” is especially satisfying.
Tangible safety upgrades!
Photo by Richard Masoner / Cyclelicious, CC-BY-SA 2.0. Not a bike light I personally installed.
I think Wikimedia Foundation figured out their Let’s Encrypt certificates without support from the forum. But we’re there if they ever need us!
A channel between Let’s Encrypt staff and the community
Let’s Encrypt describes itself as “free, automated, and open”; part of that openness consists of its use of open standards (ACME) and open source CA software (Boulder). Part of it is also about how much of the CA’s thinking happens in public! One example (of dozens) is that the September 2025 Let’s Encrypt root ceremony was discussed ahead of time on the forum, starting back in July, with the plans and details all open for discussion and review. Let’s Encrypt staff have even asked the community for feedback on how production and testing certificates ought to be named!
The forum runs on Discourse, which has continued to be an effective choice of forum software for the community. Discourse has nice technical and user interface features, but it’s also pleasantly unobtrusive. The Discourse company has also generously been donating pro bono hosting for the forum for many years, and, of course, it uses a Let’s Encrypt certificate.
The volunteers on the Let’s Encrypt forum have made a huge contribution to Let’s Encrypt’s success. It’s easy to imagine that many users might have given up on Let’s Encrypt in frustration were it not for the efforts of dedicated volunteers to draw out the necessary details, notice the relevant issues, and patiently explain concepts that were confusing people. There are also volunteer moderators who’ve worked hard to keep the forum on track, stop spam, and defuse distracting conflicts. Thanks to all of you.
Several software projects have been informed by discussions and issues on the forum, as developers there found opportunities to help large numbers of users. I would particularly highlight Alex Zorin’s Let’s Debug and Jonathan Griffin’s CertSage as examples in this category. Let’s Debug runs a series of practical live tests on a specified site to help users figure out why certificate issuance is failing, giving useful explanations of many of the most common failure reasons. CertSage is a client meant for users who have hosting plans without native support for Let’s Encrypt, and without administrative access—but where they can run PHP scripts. These projects grew out of Alex’s and Jonathan’s experiences helping users on the forum and seeing the kinds of issues that came up repeatedly there. Joona Hoikkala’s helpful acme-dns, which helps subscribers complete the ACME DNS challenge with a dedicated service instead of using an existing DNS server, also helped respond to a common issue that brought many people to the forum.
I would also like to thank Jacob Hoffman-Andrews for his early efforts to set a positive and welcoming tone on the forum. Jacob and other forum administrators always reminded the community to be patient and welcoming to each visitor, emphasizing that the forum was many users’ first interaction with Let’s Encrypt, and that users ought to be welcomed regardless of their expertise or background (and regardless of whether their questions had been asked before by others).
Let’s Encrypt has been proud to work with the IETF to maintain ACME as an open standard since we first developed the technology a decade ago. We’re happy to announce that IETF has published our latest addition to the ACME protocol, ACME Renewal Information (ARI), as RFC 9773. ARI helps keep the renewal process reliable during unexpected events affecting certificate validity.
Since the ACME protocol was first published as RFC 8555, the IETF ACME working group has remained active, defining various extensions to the original ACME protocol, initiated either by Let’s Encrypt or by colleagues from other organizations. For example, ACME WG documents have specified how to validate kinds of identifiers other than domain names, making it possible to use ACME to issue certificates for IP addresses, or even in PKIs other than the web PKI.
The publication of RFC 9773 is the culmination of a process that began in September 2021 with the first ARI draft. Along the way, numerous colleagues from Let’s Encrypt and elsewhere (thanked individually at the end of this post) contributed to the ARI specification and helped improve it.
Why implement ARI?
This is a good opportunity to remind our community about ARI and how implementing it can help users. If you’re an ACME client user, you may want to check the documentation for your client to see if it has implemented ARI yet. New functionality like this is a great reason to make sure you’re using up-to-date ACME client software. If you’re a client developer, questions about ARI implementation are welcome in the Community Forum’s Client Dev category.
Sometimes certificate authorities, including Let’s Encrypt, may perform mass revocations of an entire group or category of certificates. This most often happens when someone discovers that a certificate authority has made a mistake in how it validates or issues certificates, or has made a misstatement in how it describes its policies and procedures. In this case, the CA is required to revoke the affected certificates. This may happen through absolutely no fault of the subscribers. For example, in January 2022, we had to revoke approximately two million certificates due to a technical error in our validation processes.
When we have to revoke certificates, we want to make sure that the websites using those certificates don’t experience issues. That means those websites need to re-request issuance and install new certificates. Since CAs are sometimes required to revoke certificates on a 24 hour timeline or a 5 day timeline (depending on the nature of the incident), a process that relies on manual intervention from system administrators won’t reach most websites in time.
ARI allows a certificate authority to advise a client to perform an early renewal of a certificate that the client would have anticipated did not need to be renewed yet, broadly because the CA knows that an early renewal is helpful, or necessary, in particular circumstances. In the mass revocation scenario, this allows ARI-aware clients to avoid outages due to certificate invalidity, because they can replace their certificates even before the revocation occurs.
Of course, we and other certificate authorities work diligently to prevent mass revocation events. We’re encouraging ARI implementation as a form of emergency preparedness that can significantly mitigate the impact of this kind of problem, if and when it happens.
ARI also provides features to reduce the impact of load spikes where too many clients request certificates in a short period of time. Let’s Encrypt doesn’t need to use ARI for this today, because other improvements in popular clients’ renewal practices have already sufficiently smoothed out our load spikes. Even so, this will be a valuable ability for all ACME CAs to have available in the long term to better manage emergencies and disruptions.
On the server side, we added support for the ARI draft specification to our Boulder CA software in late 2021, so the Let’s Encrypt CA has supported ARI for some time. If you are implementing ARI in your own client, the Pebble ACME test-bed also supports ARI so you can test against that implementation.
Thanks
Thanks to all of the people who contributed to this process at the ACME WG and elsewhere, including: Roland Shoemaker and Jacob Hoffman-Andrews for coming up with the initial idea of ARI and for helping me learn the IETF process; Samantha Frank, Matt Holt, Ilari Liusvaara, and Wouter Tinus for contributing client implementations; Freddy Zhang for contributing an independent server implementation; and Rob Stradling, Andrew Ayer, and J.C. Jones for providing meaningful feedback and suggestions that significantly improved this specification.
Finally, our congratulations also to Q Misell for the recent publication of RFC 9799, another ACME WG document that went through the standards process alongside ARI.
NGINX and Let’s Encrypt share a common vision of an open and secure web. Now, with built-in support for ACME, the world’s most popular web server, reverse proxy and ingress controller for Kubernetes can simplify certificate management for everyone. From the home lab to scaled-out, mission-critical enterprise deployments.
Our ideal has always been that server software could get and renew Let’s Encrypt certificates automatically, with minimal human intervention.
Over time, more and more web servers and hosting environments have become capable of that, often via native ACME and Let’s Encrypt integrations that allow users to manage certificates without third-party tools. On August 12, the popular open source web server NGINX announced support for ACME with their official ngx_http_acme module (implemented with memory safe Rust code!).
NGINX is one of the most widely used pieces of software for operating a web server or proxy. In directly supporting ACME, NGINX joins other web servers like Traefik, Caddy and Apache httpd that can directly take advantage of certificates from Let’s Encrypt and other ACME Certificate Authorities. NGINX’s new support for ACME, together with other servers, means a significant majority of sites can now have native ACME support. Many other software environments, hosting plans, and devices also offer built-in official support for ACME.
Users have a wide range of choices to achieve integrations for their particular hosting environments. Native support in web servers is an option alongside third-party clients that can integrate with many of those same web servers. Native support typically provides more seamless integration, and it’s less work for operators since they don’t have to manage a separate ACME client. Having more tools that take care of certificates automatically helps us achieve our goal of encrypting more and more of the web, while reducing the amount of time and energy site operators have to spend.
We’d like to thank NGINX and their parent company, F5, for their sponsorship of Let’s Encrypt. This financial support helps us provide a trusted and reliable service to nearly 700 million websites.
Let’s Encrypt operates two types of Certificate Transparency (“CT”) logs—some implement the original RFC 6962 API, and some that implement the newer Static CT API. Today we are announcing that on November 3, 2025, we will make our RFC 6962 logs read-only. Past that date, we will write only to our Static CT logs. On February 9, 2026, we will entirely shut down our RFC 6962 logs.
End users (consumers or relying parties) of Web PKI certificates do not need to take any action. The work that needs to be done to make this transition will be handled by Let’s Encrypt and the browsers.
RFC 6962 is from June of 2013 and describes the original version of CT. It was a revolutionary upgrade for transparency in the Web PKI, ultimately allowing anyone to monitor issuance from all certificate authorities. Over time, though, growth in certificate issuance volume has revealed that the original CT design doesn’t scale well enough. Let’s Encrypt currently issues more publicly trusted certificates in a single day than existed in total during 2013.
What are the issues with RFC 6962 logs?
Cost
The first issue with RFC 6962 logs is the high cost of running them, particularly at Web scale, which has significantly limited the number of entities willing to operate them. Annual cloud costs for our logs are approaching seven figures.
The biggest contributor to this is that the data is stored in a relational database. We’ve scaled that up by splitting each year’s worth of data into a “shard” with its own database, and then later shrinking the shards to cover six months instead of a full year.
The approach of splitting into more and more databases is not something we want to continue doing forever, as the operational burden and costs increase. The current storage size of a CT log shard is between 7 and 10 terabytes. That’s big enough to be concerning for a single database: we previously had a test log fail when we ran into a 16 TiB limit in MySQL.
Scaling read capacity up requires large database instances with fast disks and lots of RAM, which are not cheap. We’ve had numerous instances of CT logs becoming overloaded by clients attempting to read all the data in the log, overloading the database in the process. When rate limits are imposed to prevent overloading, clients are forced to slowly crawl the API, diminishing CT’s efficiency as a fast mechanism for detecting mis-issued certificates. Ideally, clients should be able to obtain copies of the whole log in a relatively short time, but the traditional API has made that impractical.
Availability
The second issue with RFC 6962 logs is the potential for problems and non-compliance when the period called a Maximum Merge Delay (“MMD”) is exceeded.
One of the goals of CT was to have limited latency for submission to the logs. The Merge Delay design feature was added to guarantee that property. When receiving a new certificate submission, a CT log can return a Signed Certificate Timestamp (SCT) immediately, with a promise to include it in the log within the log’s MMD, conventionally 24 hours. While this seems like a good tradeoff to avoid the alternative of slowing down certificate issuance, there have been multiple incidents in which important logs have exceeded their maximum merge delay, breaking that promise.
If the log does not integrate the certificate within the MMD window, the log is out of compliance and can be distrusted. If a log is distrusted, it’s disruptive for the operators and those who depend on it, and there are fewer logs for the ecosystem to rely on.
How does the new type of log resolve these issues?
In 2023 Filippo Valsorda suggested a new API for CT logs that avoids both of these issues—the Static CT API. The Static CT API for submitting certificates to logs is the same as RFC 6962, but the API for retrieving certificate information is quite different and the MMD is eliminated. The result is logs that are much more cost effective to operate and have better availability. We previously discussed our experiences testing out the new design in “Reflections on a Year of Sunlight.”
Serving Tiles
Certificate Transparency logs are a binary tree, with every node containing a hash of its two children. The “leaf” level contains the actual entries of the log: the certificates, appended to the right side of the tree. The top of the tree is digitally signed. This forms a cryptographically verifiable structure called a Merkle Tree, which can be used to check if a certificate is in the tree, and that the tree is append-only.
Unlike the dynamic endpoints in the RFC 6962 API, serving a tree as tiles doesn’t require any dynamic computation or request processing, so we can eliminate the need for API servers. Because the tiles are static, they’re efficiently cached, in contrast with CT APIs like get-proof-by-hash, which have a different response for every certificate, so there’s no shared cache. The leaf tiles can also be stored compressed, saving even more storage!
The idea of exposing the log as a series of static tiles is motivated by our desire to scale out the read path horizontally and relatively inexpensively. We can directly expose tiles in cloud object storage like S3, use a caching CDN, or use a webserver and a filesystem.
Object or file storage is readily available, can scale up easily, and costs significantly less than databases from cloud providers. It seemed like the obvious path forward. In fact, we already have an S3-backed cache in front of our existing CT logs, which means we are currently storing our data twice.
No More Merge Delay
Static CT takes a different approach to adding certificates to the log while maintaining the same external submission API as RFC 6962. Static CT logs hold submissions while it batches and integrates certificates in the log, eliminating the merge delay. While this leads to a small latency increase, we think it’s worthwhile to avoid one of the more common CT log failure cases.
It also lets us embed the final leaf index in an extension of our SCTs, bringing CT a step closer to direct client verification of Merkle tree proofs. The extension also makes it possible for clients to fetch the proof of log inclusion from the new static tile-based APIs, without requiring server-side lookup tables or databases.
Going Forward
Let’s Encrypt has submitted new Static CT API logs for inclusion in certificate transparency programs. We expect these logs to be included and trusted prior to the read-only date for our RFC 6962 logs, and we will begin submitting our certificates to them as soon as possible.
We may stop submitting our own certificates to our RFC 6962 logs prior to the read-only date, but other CAs will be able to write certificates to our RFC 6962 logs until the read-only date.
Conclusion
The Static CT API has proven to be operationally better and more scalable than the RFC 6962 design in almost every way. With the substantial increase in certificate volume over time, we need that improved efficiency to make running CT logs cost-effective. As a result, we’re switching fully to the new log architecture in order to make the best use of our resources. The Static CT API logs we operate will provide exactly the same security and transparency benefits as our old RFC 6962 log did.
As we explained above, this requires no changes at all for end users. It may require configuration changes on the part of certificate authorities that have been submitting certs to our old log (they can start submitting to one or both of our new logs instead). It also requires software updates for ecosystem participants who monitor logs; they’ll need to ensure that they have client software that’s compatible with the new API. Overall, this change should help ensure that our CT logging continues to be able to grow with the Web PKI.
Today we turned off our Online Certificate Status Protocol (OCSP) service, as announced in December of last year. We stopped including OCSP URLs in our certificates more than 90 days ago, so all Let’s Encrypt certificates that contained OCSP URLs have now expired. Going forward, we will publish revocation information exclusively via Certificate Revocation Lists (CRLs).
We ended support for OCSP primarily because it represents a considerable risk to privacy on the Internet. When someone visits a website using a browser or other software that checks for certificate revocation via OCSP, the Certificate Authority (CA) operating the OCSP responder immediately becomes aware of which website is being visited from that visitor’s particular IP address. Even when a CA intentionally does not retain this information, as is the case with Let’s Encrypt, it could accidentally be retained or CAs could be legally compelled to collect it. CRLs do not have this issue.
We are also taking this step because keeping our CA infrastructure as simple as possible is critical for the continuity of compliance, reliability, and efficiency at Let’s Encrypt. For every year that we have existed, operating OCSP services has taken up considerable resources that can soon be better spent on other aspects of our operations. Now that we support CRLs, our OCSP service has become unnecessary.
At the height of our OCSP service’s traffic earlier this year, we handled approximately 340 billion OCSP requests per month. That’s more than 140,000 requests per second handled by our CDN, with 15,000 requests per second handled by our origin. We’d like to thank Akamai for generously donating CDN services for OCSP to Let’s Encrypt for the past ten years.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
