Let's Encrypt News

A Note from our Executive Director

This letter was originally published in our 2025 Annual Report.

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.

Mon, 29 Dec 2025 00:00:00 +0000

---

10 Years of Let's Encrypt Certificates

This letter was originally published in our 2025 Annual Report.

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%.

A few milestones

We’ve blogged about most of Let’s Encrypt’s most significant milestones as they’ve happened, and I invite everyone in our community to look over those blog posts to see how far we’ve come. We’ve also published annual reports for the past seven years, which offer elegant and concise summaries of our work.

As I personally think back on the past decade, just a few of the many events that come to mind include:

• Telling the world about the project in November 2014

• Our first certificate issuance in September 2015

• Our one millionth certificate in March 2016, then our 100 millionth certificate in June 2017, and then our billionth certificate in 2020

• 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.

We’ve also periodically rolled out new features such as internationalized domain name support (2016), wildcard support (2018), and short-lived and IP address (2025) certificates. We’re always working on more new features for the future.

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.

We were honored to be recognized with awards including the 2022 Levchin Prize for Real-World Cryptography and the 2019 O’Reilly Open Source Award. In October of this year some of the individuals who got Let’s Encrypt started were honored to receive the IEEE Cybersecurity Award for Practice.

We documented the history, design, and goals of the project in an academic paper at the ACM CCS ‘19 conference, which has subsequently been cited hundreds of times in academic research.

Our initial sponsors

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.

Tue, 09 Dec 2025 00:00:00 +0000

---

Decreasing Certificate Lifetimes to 45 Days

This letter was originally published in our 2025 Annual Report.

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%.

A few milestones

We’ve blogged about most of Let’s Encrypt’s most significant milestones as they’ve happened, and I invite everyone in our community to look over those blog posts to see how far we’ve come. We’ve also published annual reports for the past seven years, which offer elegant and concise summaries of our work.

As I personally think back on the past decade, just a few of the many events that come to mind include:

• Telling the world about the project in November 2014

• Our first certificate issuance in September 2015

• Our one millionth certificate in March 2016, then our 100 millionth certificate in June 2017, and then our billionth certificate in 2020

• 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.

We’ve also periodically rolled out new features such as internationalized domain name support (2016), wildcard support (2018), and short-lived and IP address (2025) certificates. We’re always working on more new features for the future.

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.

We were honored to be recognized with awards including the 2022 Levchin Prize for Real-World Cryptography and the 2019 O’Reilly Open Source Award. In October of this year some of the individuals who got Let’s Encrypt started were honored to receive the IEEE Cybersecurity Award for Practice.

We documented the history, design, and goals of the project in an academic paper at the ACM CCS ‘19 conference, which has subsequently been cited hundreds of times in academic research.

Our initial sponsors

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.

Tue, 02 Dec 2025 00:00:00 +0000

---

New "Generation Y" Hierarchy of Root and Intermediate Certificates

This letter was originally published in our 2025 Annual Report.

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%.

A few milestones

We’ve blogged about most of Let’s Encrypt’s most significant milestones as they’ve happened, and I invite everyone in our community to look over those blog posts to see how far we’ve come. We’ve also published annual reports for the past seven years, which offer elegant and concise summaries of our work.

As I personally think back on the past decade, just a few of the many events that come to mind include:

• Telling the world about the project in November 2014

• Our first certificate issuance in September 2015

• Our one millionth certificate in March 2016, then our 100 millionth certificate in June 2017, and then our billionth certificate in 2020

• 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.

We’ve also periodically rolled out new features such as internationalized domain name support (2016), wildcard support (2018), and short-lived and IP address (2025) certificates. We’re always working on more new features for the future.

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.

We were honored to be recognized with awards including the 2022 Levchin Prize for Real-World Cryptography and the 2019 O’Reilly Open Source Award. In October of this year some of the individuals who got Let’s Encrypt started were honored to receive the IEEE Cybersecurity Award for Practice.

We documented the history, design, and goals of the project in an academic paper at the ACM CCS ‘19 conference, which has subsequently been cited hundreds of times in academic research.

Our initial sponsors

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!

Mon, 24 Nov 2025 00:00:00 +0000

---

Ten Years of Community Support

This letter was originally published in our 2025 Annual Report.

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%.

A few milestones

We’ve blogged about most of Let’s Encrypt’s most significant milestones as they’ve happened, and I invite everyone in our community to look over those blog posts to see how far we’ve come. We’ve also published annual reports for the past seven years, which offer elegant and concise summaries of our work.

As I personally think back on the past decade, just a few of the many events that come to mind include:

• Telling the world about the project in November 2014

• Our first certificate issuance in September 2015

• Our one millionth certificate in March 2016, then our 100 millionth certificate in June 2017, and then our billionth certificate in 2020

• 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.

We’ve also periodically rolled out new features such as internationalized domain name support (2016), wildcard support (2018), and short-lived and IP address (2025) certificates. We’re always working on more new features for the future.

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.

We were honored to be recognized with awards including the 2022 Levchin Prize for Real-World Cryptography and the 2019 O’Reilly Open Source Award. In October of this year some of the individuals who got Let’s Encrypt started were honored to receive the IEEE Cybersecurity Award for Practice.

We documented the history, design, and goals of the project in an academic paper at the ACM CCS ‘19 conference, which has subsequently been cited hundreds of times in academic research.

Our initial sponsors

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!

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 been the first stop for end users with technical questions. It’s been the main way that client developers got help with ACME and debugged compatibility issues. It’s been the place where Let’s Encrypt staff made technical announcements and got immediate feedback from affected parties.

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:

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!

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!

In other cases, like when there was new functionality announced, or substantive technical changes affecting certificate issuance, or proposed rate limit changes, or problems requiring mass revocation, or expiring root certificates, Let’s Encrypt staff were available talking about all the details and directly answering end users’ questions. Again, there are lots of other examples, where changes large or small got announced, proposed, or discussed on the forum, with Let’s Encrypt’s own experts engaging with the community.

Final thoughts and thanks

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).

Tue, 07 Oct 2025 00:00:00 +0000

---

ACME Renewal Information (ARI) Published as RFC 9773

This letter was originally published in our 2025 Annual Report.

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%.

A few milestones

We’ve blogged about most of Let’s Encrypt’s most significant milestones as they’ve happened, and I invite everyone in our community to look over those blog posts to see how far we’ve come. We’ve also published annual reports for the past seven years, which offer elegant and concise summaries of our work.

As I personally think back on the past decade, just a few of the many events that come to mind include:

• Telling the world about the project in November 2014

• Our first certificate issuance in September 2015

• Our one millionth certificate in March 2016, then our 100 millionth certificate in June 2017, and then our billionth certificate in 2020

• 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.

We’ve also periodically rolled out new features such as internationalized domain name support (2016), wildcard support (2018), and short-lived and IP address (2025) certificates. We’re always working on more new features for the future.

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.

We were honored to be recognized with awards including the 2022 Levchin Prize for Real-World Cryptography and the 2019 O’Reilly Open Source Award. In October of this year some of the individuals who got Let’s Encrypt started were honored to receive the IEEE Cybersecurity Award for Practice.

We documented the history, design, and goals of the project in an academic paper at the ACM CCS ‘19 conference, which has subsequently been cited hundreds of times in academic research.

Our initial sponsors

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!

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 been the first stop for end users with technical questions. It’s been the main way that client developers got help with ACME and debugged compatibility issues. It’s been the place where Let’s Encrypt staff made technical announcements and got immediate feedback from affected parties.

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:

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!

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!

In other cases, like when there was new functionality announced, or substantive technical changes affecting certificate issuance, or proposed rate limit changes, or problems requiring mass revocation, or expiring root certificates, Let’s Encrypt staff were available talking about all the details and directly answering end users’ questions. Again, there are lots of other examples, where changes large or small got announced, proposed, or discussed on the forum, with Let’s Encrypt’s own experts engaging with the community.

Final thoughts and thanks

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.

Tue, 16 Sep 2025 00:00:00 +0000

---

Native ACME Support Comes to NGINX

This letter was originally published in our 2025 Annual Report.

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%.

A few milestones

We’ve blogged about most of Let’s Encrypt’s most significant milestones as they’ve happened, and I invite everyone in our community to look over those blog posts to see how far we’ve come. We’ve also published annual reports for the past seven years, which offer elegant and concise summaries of our work.

As I personally think back on the past decade, just a few of the many events that come to mind include:

• Telling the world about the project in November 2014

• Our first certificate issuance in September 2015

• Our one millionth certificate in March 2016, then our 100 millionth certificate in June 2017, and then our billionth certificate in 2020

• 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.

We’ve also periodically rolled out new features such as internationalized domain name support (2016), wildcard support (2018), and short-lived and IP address (2025) certificates. We’re always working on more new features for the future.

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.

We were honored to be recognized with awards including the 2022 Levchin Prize for Real-World Cryptography and the 2019 O’Reilly Open Source Award. In October of this year some of the individuals who got Let’s Encrypt started were honored to receive the IEEE Cybersecurity Award for Practice.

We documented the history, design, and goals of the project in an academic paper at the ACM CCS ‘19 conference, which has subsequently been cited hundreds of times in academic research.

Our initial sponsors

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!

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 been the first stop for end users with technical questions. It’s been the main way that client developers got help with ACME and debugged compatibility issues. It’s been the place where Let’s Encrypt staff made technical announcements and got immediate feedback from affected parties.

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:

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!

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!

In other cases, like when there was new functionality announced, or substantive technical changes affecting certificate issuance, or proposed rate limit changes, or problems requiring mass revocation, or expiring root certificates, Let’s Encrypt staff were available talking about all the details and directly answering end users’ questions. Again, there are lots of other examples, where changes large or small got announced, proposed, or discussed on the forum, with Let’s Encrypt’s own experts engaging with the community.

Final thoughts and thanks

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.

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.

Other project developers interested in integrating ACME more directly can read about the ACME protocol, find existing ACME library implementations and other reusable software components, and join the Client Dev conversation on our Community Forum.

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.

Thu, 11 Sep 2025 00:00:00 +0000

---

End of Life Plan for RFC 6962 Certificate Transparency Logs

This letter was originally published in our 2025 Annual Report.

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%.

A few milestones

We’ve blogged about most of Let’s Encrypt’s most significant milestones as they’ve happened, and I invite everyone in our community to look over those blog posts to see how far we’ve come. We’ve also published annual reports for the past seven years, which offer elegant and concise summaries of our work.

As I personally think back on the past decade, just a few of the many events that come to mind include:

• Telling the world about the project in November 2014

• Our first certificate issuance in September 2015

• Our one millionth certificate in March 2016, then our 100 millionth certificate in June 2017, and then our billionth certificate in 2020

• 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.

We’ve also periodically rolled out new features such as internationalized domain name support (2016), wildcard support (2018), and short-lived and IP address (2025) certificates. We’re always working on more new features for the future.

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.

We were honored to be recognized with awards including the 2022 Levchin Prize for Real-World Cryptography and the 2019 O’Reilly Open Source Award. In October of this year some of the individuals who got Let’s Encrypt started were honored to receive the IEEE Cybersecurity Award for Practice.

We documented the history, design, and goals of the project in an academic paper at the ACM CCS ‘19 conference, which has subsequently been cited hundreds of times in academic research.

Our initial sponsors

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!

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 been the first stop for end users with technical questions. It’s been the main way that client developers got help with ACME and debugged compatibility issues. It’s been the place where Let’s Encrypt staff made technical announcements and got immediate feedback from affected parties.

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:

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!

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!

In other cases, like when there was new functionality announced, or substantive technical changes affecting certificate issuance, or proposed rate limit changes, or problems requiring mass revocation, or expiring root certificates, Let’s Encrypt staff were available talking about all the details and directly answering end users’ questions. Again, there are lots of other examples, where changes large or small got announced, proposed, or discussed on the forum, with Let’s Encrypt’s own experts engaging with the community.

Final thoughts and thanks

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.

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.

Other project developers interested in integrating ACME more directly can read about the ACME protocol, find existing ACME library implementations and other reusable software components, and join the Client Dev conversation on our Community Forum.

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.

Update, August 18, 2025

We have updated the read-only and shutdown dates to ensure that our new Static CT API logs are fully trusted by browsers before switching Oak to read-only in order to avoid any disruption.

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 30, 2025, we will make our RFC 6962 logs read-only. Past that date, we will write only to our Static CT logs. On February 28, 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.

Static CT tiles are files containing 256 elements each, either hashes at a certain tree “height” or certificates (or pre-certificates) at the leaf level. Russ Cox has a great explanation of how tiles work on his blog, or you can read the relevant section of the Static CT specification.

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.

Thu, 14 Aug 2025 00:00:00 +0000

---

OCSP Service Has Reached End of Life

This letter was originally published in our 2025 Annual Report.

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%.

A few milestones

We’ve blogged about most of Let’s Encrypt’s most significant milestones as they’ve happened, and I invite everyone in our community to look over those blog posts to see how far we’ve come. We’ve also published annual reports for the past seven years, which offer elegant and concise summaries of our work.

As I personally think back on the past decade, just a few of the many events that come to mind include:

• Telling the world about the project in November 2014

• Our first certificate issuance in September 2015

• Our one millionth certificate in March 2016, then our 100 millionth certificate in June 2017, and then our billionth certificate in 2020

• 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.

We’ve also periodically rolled out new features such as internationalized domain name support (2016), wildcard support (2018), and short-lived and IP address (2025) certificates. We’re always working on more new features for the future.

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.

We were honored to be recognized with awards including the 2022 Levchin Prize for Real-World Cryptography and the 2019 O’Reilly Open Source Award. In October of this year some of the individuals who got Let’s Encrypt started were honored to receive the IEEE Cybersecurity Award for Practice.

We documented the history, design, and goals of the project in an academic paper at the ACM CCS ‘19 conference, which has subsequently been cited hundreds of times in academic research.

Our initial sponsors

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!

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 been the first stop for end users with technical questions. It’s been the main way that client developers got help with ACME and debugged compatibility issues. It’s been the place where Let’s Encrypt staff made technical announcements and got immediate feedback from affected parties.

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:

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!

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!

In other cases, like when there was new functionality announced, or substantive technical changes affecting certificate issuance, or proposed rate limit changes, or problems requiring mass revocation, or expiring root certificates, Let’s Encrypt staff were available talking about all the details and directly answering end users’ questions. Again, there are lots of other examples, where changes large or small got announced, proposed, or discussed on the forum, with Let’s Encrypt’s own experts engaging with the community.

Final thoughts and thanks

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.

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.

Other project developers interested in integrating ACME more directly can read about the ACME protocol, find existing ACME library implementations and other reusable software components, and join the Client Dev conversation on our Community Forum.

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.

Update, August 18, 2025

We have updated the read-only and shutdown dates to ensure that our new Static CT API logs are fully trusted by browsers before switching Oak to read-only in order to avoid any disruption.

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 30, 2025, we will make our RFC 6962 logs read-only. Past that date, we will write only to our Static CT logs. On February 28, 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.

Static CT tiles are files containing 256 elements each, either hashes at a certain tree “height” or certificates (or pre-certificates) at the leaf level. Russ Cox has a great explanation of how tiles work on his blog, or you can read the relevant section of the Static CT specification.

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.

Wed, 06 Aug 2025 00:00:00 +0000

---

We've Issued Our First IP Address Certificate

This letter was originally published in our 2025 Annual Report.

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%.

A few milestones

We’ve blogged about most of Let’s Encrypt’s most significant milestones as they’ve happened, and I invite everyone in our community to look over those blog posts to see how far we’ve come. We’ve also published annual reports for the past seven years, which offer elegant and concise summaries of our work.

As I personally think back on the past decade, just a few of the many events that come to mind include:

• Telling the world about the project in November 2014

• Our first certificate issuance in September 2015

• Our one millionth certificate in March 2016, then our 100 millionth certificate in June 2017, and then our billionth certificate in 2020

• 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.

We’ve also periodically rolled out new features such as internationalized domain name support (2016), wildcard support (2018), and short-lived and IP address (2025) certificates. We’re always working on more new features for the future.

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.

We were honored to be recognized with awards including the 2022 Levchin Prize for Real-World Cryptography and the 2019 O’Reilly Open Source Award. In October of this year some of the individuals who got Let’s Encrypt started were honored to receive the IEEE Cybersecurity Award for Practice.

We documented the history, design, and goals of the project in an academic paper at the ACM CCS ‘19 conference, which has subsequently been cited hundreds of times in academic research.

Our initial sponsors

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!

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 been the first stop for end users with technical questions. It’s been the main way that client developers got help with ACME and debugged compatibility issues. It’s been the place where Let’s Encrypt staff made technical announcements and got immediate feedback from affected parties.

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:

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!

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!

In other cases, like when there was new functionality announced, or substantive technical changes affecting certificate issuance, or proposed rate limit changes, or problems requiring mass revocation, or expiring root certificates, Let’s Encrypt staff were available talking about all the details and directly answering end users’ questions. Again, there are lots of other examples, where changes large or small got announced, proposed, or discussed on the forum, with Let’s Encrypt’s own experts engaging with the community.

Final thoughts and thanks

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.

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.

Other project developers interested in integrating ACME more directly can read about the ACME protocol, find existing ACME library implementations and other reusable software components, and join the Client Dev conversation on our Community Forum.

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.

Update, August 18, 2025

We have updated the read-only and shutdown dates to ensure that our new Static CT API logs are fully trusted by browsers before switching Oak to read-only in order to avoid any disruption.

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 30, 2025, we will make our RFC 6962 logs read-only. Past that date, we will write only to our Static CT logs. On February 28, 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.

Static CT tiles are files containing 256 elements each, either hashes at a certain tree “height” or certificates (or pre-certificates) at the leaf level. Russ Cox has a great explanation of how tiles work on his blog, or you can read the relevant section of the Static CT specification.

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.

Since Let’s Encrypt started issuing certificates in 2015, people have repeatedly requested the ability to get certificates for IP addresses, an option that only a few certificate authorities have offered. Until now, they’ve had to look elsewhere, because we haven’t provided that feature.

Today, we’ve issued our first certificate for an IP address, as we announced we would in January. As with other new certificate features on our engineering roadmap, we’ll now start gradually rolling out this option to more and more of our subscribers.

Some Background on IP Address Certs

IP addresses are the underlying numerical addresses used on the Internet. Every device on the Internet has one (though, in modern practice, it might be shared with other devices, like when an entire home network shares a single public IP address). The Internet infrastructure uses them to route communications to their proper destination. IP addresses come in two forms, IPv4 and IPv6, and generally look like 54.215.62.21 (IPv4) or 2600:1f1c:446:4900::65 (IPv6).

Most Internet users rarely see or refer to IP addresses directly. Instead, they almost always use domain names like letsencrypt.org to refer to Internet services. The domain name system (DNS) is a part of the Internet infrastructure that’s responsible for allowing software to find the IP addresses associated with a particular domain name. For instance, your web browser can use DNS to find out that the service https://letsencrypt.org/ (Let’s Encrypt’s own website) is provided from the IP addresses 54.215.62.21 and 2600:1f1c:446:4900::65, among several others. This probably happened behind the scenes before you started reading this article! Your web browser needed to know our IP address in order to actually connect to our site and fetch this article.

Because we overwhelmingly tend to think and talk about Internet services in terms of domain names, those are the identifiers that are normally listed in certificates like those that Let’s Encrypt provides to our subscribers. Since you know us as “letsencrypt.org” and not as, say, “54.215.62.21,” it makes the most sense for our domain name to be on our certificate. After all, that’s what you’ll want your web browser to check against. This also gives Internet services more flexibility to be hosted in multiple locations, or to change where they’re hosted, without necessarily needing separate certificates for each server.

In principle, there’s no reason that a certificate couldn’t be issued for an IP address rather than a domain name, and in fact the technical and policy standards for certificates have always allowed this, with a handful of certificate authorities offering this service on a small scale. In Let’s Encrypt’s case, we’ve preferred to wait until some other pieces, like short-lived certs, were in place before we made this option available for our subscribers.

Why IP Address Certs Are Less Common

First and foremost, it’s because Internet users usually know services by domain names, not by IP addresses, and because IP addresses can easily change “behind the scenes” with no prior notice. For instance, a popular site could switch from one cloud hosting company to a different one, and update its DNS records to point at the new host. Most users wouldn’t ever notice the change at all, even though the site’s underlying IP addresses would be completely different.

Second, because IP addresses can change so easily, the sense of “ownership” one might have for them—or that a certificate authority might be able to attest to—tends to be weaker than for a domain name. If you’re hosting something in your house on a residential broadband connection, your Internet service provider most likely doesn’t guarantee that your IP address will stay the same over time. (That is, most home Internet users have a “dynamic IP address” from their ISPs, rather than a “static IP address.”) In that case, you have to contend with the possibility that that address may change often, possibly without warning, and that your old address may be assigned to somebody else.

Third, most Internet service operators don’t expect that end users will ever intentionally connect to their sites directly by IP address. In some cases, when an IP address is shared by different websites or different devices, connecting by IP address alone wouldn’t even work properly. In that case, there’s not much benefit to obtaining a certificate for the IP address!

How Let’s Encrypt Subscribers May Use IP Address Certs

Most current subscribers should be fine with their existing domain name certs and won’t need IP address certs. Subscribers who have a use for an IP address cert are typically already aware of that. A few use cases that we’re aware of include:

• A default page for hosting providers, in case someone pastes a server’s IP address into a browser instead of an individual site name (right now, this normally produces an error in the browser).

• A way to access your website if you don’t have a domain name at all (at some cost in reliability and convenience compared to getting a domain name).

• Securing DNS over HTTPS (DoH) or other infrastructure services. Having a certificate makes it much easier for DoH servers to prove their identities to clients. That could make it more feasible for DoH users or clients to enforce a requirement for a valid publicly-trusted certificate when connecting to DoH servers.

• Securing remote access to some home devices (like network-attached storage servers and Internet-of-things devices) even without a domain name.

• Securing ephemeral connections within cloud hosting infrastructure, like connections between one back-end cloud server and another, or ephemeral connections to administer new or short-lived back-end servers via HTTPS—as long as those servers have at least one public IP address available.

How To Get an IP Address Cert

IP address certificates are available right now in Staging. They should be generally available in Prod later in 2025, at the same time that short-lived certificates become generally available. Prior to general availability we may allow list issuance for a limited number of partners who can provide us with feedback.

Many Let’s Encrypt client applications should already be able to request certificates for IP addresses, although there can be minor technical changes required to support this in some client software.

As a matter of policy, Let’s Encrypt certificates that cover IP addresses must be short-lived certs, valid for only about six days. As such, your ACME client must support the draft ACME Profiles specification, and you must configure it to request the shortlived profile. And, probably not surprisingly, you can’t use the DNS challenge method to prove your control over an IP address; only the http-01 and tls-alpn-01 methods can be used.

If your client software requests an IP address cert with details that aren’t compatible with these policies, the order will be rejected by the ACME server. In this case, your client application may need to be updated or reconfigured. Feel free to ask for help on the Let’s Encrypt community forum if you encounter any problems, either as a client application developer or as an end user.

Tue, 01 Jul 2025 00:00:00 +0000

---

Social Media

• GitHub
• Google+
• LinkedIn
• Twitter
• Instagram