Published file metadata, source observations, indicators, and research history in one bounded catalog.
2,400+Reachable catalog records
26 / 100Current catalog page
24Maximum records per page
0Samples downloaded by this page
Feed collection status
Sources represented on this page. Publication and observation dates describe the content; successful batch dates describe local collection. A recent batch does not certify complete coverage or current provider availability.
intelligence_src_823f7b237762257237Recent successful batchLast successful batch: Last attempt:
Stale means older than twice the recorded collection interval, with a minimum of one hour; without an interval, the threshold is 24 hours. Cached content remains available while a feed is stale, paused, or unverified.
2,400+ MATCHING RECORDSMETADATA ONLY / SOURCE ATTRIBUTION PRESERVED
We issued our billionth certificate on February 27, 2020. We’re going to use this big round number as an opportunity to reflect on what has changed for us, and for the Internet, leading up to this event. In particular, we want to talk about what has happened since the last time we talked about a big round number of certificates - one hundred million. One thing that’s different now is that the Web is much more encrypted than it was. In June of 2017 approximately 58% of page loads used HTTPS globally, 64% in the United States. Today 81% of page loads use HTTPS globally, and we’re at 91% in the United States! This is an incredible achievement. That’s a lot more privacy and security for everybody. Another thing that’s different is that our organization has grown a bit, but not by much! In June of 2017 we were serving approximately 46M websites, and we did so with 11 full time staff and an annual budget of $2.61M. Today we serve nearly 192M websites with 13 full time staff and an annual budget of approximately $3.35M. This means we’re serving more than 4x the websites with only two additional staff and a 28% increase in budget. The additional staff and budget did more than just improve our ability to scale though - we’ve made improvements across the board to provide even more secure and reliable service. Nothing drives adoption like ease of use, and the foundation for ease of use in the certificate space is our ACME protocol. ACME allows for extensive automation, which means computers can do most of the work. It was also standardized as RFC 8555 in 2019, which allows the Web community to confidently build an even richer ecosystem of software around it. Today, thanks to our incredible community, there is an ACME client for just about every deployment environment. Certbot is one of our favorites, and they’ve been working hard to make it even easier for people to use. When you combine ease of use with incentives, that’s when adoption really takes off. Since 2017 browsers have started requiring HTTPS for more features, and they’ve greatly improved the ways in which they communicate to their users about the risks of not using HTTPS. When websites put their users at risk by not using HTTPS, major browsers now show stronger warnings. Many sites have responded by deploying HTTPS. Thanks for taking the time to reflect on this milestone with us. As a community we’ve done incredible things to protect people on the Web. Having issued one billion certificates is affirmation of all the progress we’ve made as a community, and we’re excited to keep working with you to create an even more secure and privacy-respecting Web for everyone. We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to sponsor Let’s Encrypt please email us at sponsor@letsencrypt.org. We ask that you make an individual contribution if it is within your means.
First reported Feb 27, 2020 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Our first full year as a live CA was an exciting one. I’m incredibly proud of what our team and community accomplished during 2016. I’d like to share some thoughts about how we’ve changed, what we’ve accomplished, and what we’ve learned. At the start of 2016, Let’s Encrypt certificates had been available to the public for less than a month and we were supporting approximately 240,000 active (unexpired) certificates. That seemed like a lot at the time! Now we’re frequently issuing that many new certificates in a single day while supporting more than 20,000,000 active certificates in total. We’ve issued more than a million certificates in a single day a few times recently. We’re currently serving an average of 6,700 OCSP responses per second. We’ve done a lot of optimization work, we’ve had to add some hardware, and there have been some long nights for our staff, but we’ve been able to keep up and we’re ready for another year of strong growth. We added a number of new features during the past year, including support for the ACME DNS challenge, ECDSA signing, IPv6, and Internationalized Domain Names. When 2016 started, our root certificate had not been accepted into any major root programs. Today we’ve been accepted into the Mozilla, Apple, and Google root programs. We’re close to announcing acceptance into another major root program. These are major steps towards being able to operate as an independent CA. You can read more about why here. The ACME protocol for issuing and managing certificates is at the heart of how Let’s Encrypt works. Having a well-defined and heavily audited specification developed in public on a standards track has been a major contributor to our growth and the growth of our client ecosystem. Great progress was made in 2016 towards standardizing ACME in the IETF ACME working group. We’re hoping for a final document around the end of Q2 2017, and we’ll announce plans for implementation of the updated protocol around that time as well. Supporting the kind of growth we saw in 2016 meant adding staff, and during the past year Internet Security Research Group (ISRG), the non-profit entity behind Let’s Encrypt, went from four full-time employees to nine. We’re still a pretty small crew given that we’re now one of the largest CAs in the world (if not the largest), but it works because of our intense focus on automation, the fact that we’ve been able to hire great people, and because of the incredible support we receive from the Let’s Encrypt community. Let’s Encrypt exists in order to help create a 100% encrypted Web. Our own metrics can be interesting, but they’re only really meaningful in terms of the impact they have on progress towards a more secure and privacy-respecting Web. The metric we use to track progress towards that goal is the percentage of page loads using HTTPS, as seen by browsers. According to Firefox Telemetry, the Web has gone from approximately 39% of page loads using HTTPS each day to just about 49% during the past year. We’re incredibly close to a Web that is more encrypted than not. We’re proud to have been a big part of that, but we can’t take credit for all of it. Many people and organizations around the globe have come to realize that we need to invest in a more secure and privacy-respecting Web, and have taken steps to secure their own sites as well as their customers’. Thank you to everyone that has advocated for HTTPS this year, or helped to make it easier for people to make the switch. We learned some lessons this year. When we had service interruptions they were usually related to managing the rapidly growing database backing our CA. Also, while most of our code had proper tests, some small pieces didn’t and that led to incidents that shouldn’t have happened. That said, I’m proud of the way we handle incidents promptly, including quick and transparent public disclosure. We also learned a lot about our client ecosystem.
First reported Jan 06, 2017 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Update: January 15, 2026 Six-day and IP address certificates are now generally available. See 6-day and IP Address Certificates are Generally Available for details. This year we will continue to pursue our commitment to improving the security of the Web PKI by introducing the option to get certificates with six-day lifetimes (“short-lived certificates”). We will also add support for IP addresses in addition to domain names. Our longer-lived certificates, which currently have a lifetime of 90 days, will continue to be available alongside our six-day offering. Subscribers will be able to opt in to short-lived certificates via a certificate profile mechanism being added to our ACME API. Shorter Certificate Lifetimes Are Good for Security When the private key associated with a certificate is compromised, the recommendation has always been to have the certificate revoked so that people will know not to use it. Unfortunately, certificate revocation doesn’t work very well. This means that certificates with compromised keys (or other issues) may continue to be used until they expire. The longer the lifetime of the certificate, the longer the potential for use of a problematic certificate. The primary advantage of short-lived certificates is that they greatly reduce the potential compromise window because they expire relatively quickly. This reduces the need for certificate revocation, which has historically been unreliable. Our six-day certificates will not include OCSP or CRL URLs. Additionally, short-lived certificates practically require automation, and we believe that automating certificate issuance is important for security. IP Address Support For Securing Additional Use Cases We will support including IP addresses as Subject Alternative Names in our six-day certificates. This will enable secure TLS connections, with publicly trusted certificates, to services made available via IP address, without the need for a domain name. Validation for IP addresses will work much the same as validation for domain names, though validation will be restricted to the http-01 and tls-alpn-01 challenge types. The dns-01 challenge type will not be available because the DNS is not involved in validating IP addresses. Additionally, there is no mechanism to check CAA records for IP addresses. Timeline We expect to issue the first valid short-lived certificates to ourselves in February of this year. Around April we will enable short-lived certificates for a small set of early adopting subscribers. We hope to make short-lived certificates generally available by the end of 2025. The earliest short-lived certificates we issue may not support IP addresses, but we intend to enable IP address support by the time short-lived certificates reach general availability. How To Get Six-Day and IP Address Certificates Once short-lived certificates are an option for you, you’ll need to use an ACME client that supports ACME certificate profiles and select the short-lived certificate profile (the name of which will be published at a later date). Once IP address support is an option for you, requesting an IP address in a certificate will automatically select a short-lived certificate profile. Looking Ahead The best way to prepare to take advantage of short-lived certificates is to make sure your ACME client is reliably renewing certificates in an automated fashion. If that’s working well then there should be no costs to switching to short-lived certificates. If you have questions or comments about our plans, feel free to let us know on our community forums.
First reported Jan 16, 2025 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Update March 16, 2026: Thanks to some timeline changes in the root program requirements, we have been able to push back the removal of the tlsclient profile slightly. If you are already using the tlsclient profile before May 13, 2026, now you will be able to continue to do so through July 8, 2026. Let’s Encrypt will no longer include the “TLS Client Authentication” Extended Key Usage (EKU) in our certificates beginning in 2026. Most users who use Let’s Encrypt to secure websites won’t be affected and won’t need to take any action. However, if you use Let’s Encrypt certificates as client certificates to authenticate to a server, this change may impact you. To minimize disruption, Let’s Encrypt will roll this change out in multiple stages, using ACME Profiles: Today: Let’s Encrypt already excludes the Client Authentication EKU on our tlsserver ACME profile. You can verify compatibility by issuing certificates with this profile now. October 1, 2025: Let’s Encrypt will launch a new tlsclient ACME profile which will retain the TLS Client Authentication EKU. Users who need additional time to migrate can opt-in to this profile. February 11, 2026: the default classic ACME profile will no longer contain the Client Authentication EKU. July 8, 2026: the tlsclient ACME profile will no longer be available and no further certificates with the Client Authentication EKU will be issued. Once this is completed, Let’s Encrypt will switch to issuing with new intermediate Certificate Authorities which also do not contain the TLS Client Authentication EKU. For some background information, all certificates include a list of intended uses, known as Extended Key Usages (EKU). Let’s Encrypt certificates have included two EKUs: TLS Server Authentication and TLS Client Authentication. TLS Server Authentication is used to authenticate connections to TLS Servers, like websites. TLS Client Authentication is used by clients to authenticate themselves to a server. This feature is not typically used on the web, and is not required on the certificates used on a website. After this change is complete, only TLS Server Authentication will be available from Let’s Encrypt. This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs. Many uses of client authentication are better served by a private certificate authority, and so Let’s Encrypt is discontinuing support for TLS Client Authentication ahead of this deadline.
First reported May 14, 2025 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Update: January 15, 2026 Six-day and IP address certificates are now generally available. See 6-day and IP Address Certificates are Generally Available for details. 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
First reported Jul 01, 2025 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Vital personal and business information flows over the Internet more frequently than ever, and we don’t always know when it’s happening. It’s clear at this point that encrypting is something all of us should be doing. Then why don’t we use TLS (the successor to SSL) everywhere? Every browser in every device supports it. Every server in every data center supports it. Why don’t we just flip the switch? The challenge is server certificates. The anchor for any TLS-protected communication is a public-key certificate which demonstrates that the server you’re actually talking to is the server you intended to talk to. For many server operators, getting even a basic server certificate is just too much of a hassle. The application process can be confusing. It usually costs money. It’s tricky to install correctly. It’s a pain to update. Let’s Encrypt is a new free certificate authority, built on a foundation of cooperation and openness, that lets everyone be up and running with basic server certificates for their domains through a simple one-click process. Mozilla Corporation, Cisco Systems, Inc., Akamai Technologies, Electronic Frontier Foundation, IdenTrust, Inc., and researchers at the University of Michigan are working through the Internet Security Research Group (“ISRG”), a California public benefit corporation, to deliver this much-needed infrastructure in Q2 2015. The ISRG welcomes other organizations dedicated to the same ideal of ubiquitous, open Internet security. The key principles behind Let’s Encrypt are: Free: Anyone who owns a domain can get a certificate validated for that domain at zero cost. Automatic: The entire enrollment process for certificates occurs painlessly during the server’s native installation or configuration process, while renewal occurs automatically in the background. Secure: Let’s Encrypt will serve as a platform for implementing modern security techniques and best practices. Transparent: All records of certificate issuance and revocation will be available to anyone who wishes to inspect them. Open: The automated issuance and renewal protocol will be an open standard and as much of the software as possible will be open source. Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the entire community, beyond the control of any one organization. If you want to help these organizations in making TLS Everywhere a reality, here’s how you can get involved: Sponsor ISRG Help Us Build Let’s Encrypt To learn more about the ISRG and our partners, check out our About page.
First reported Nov 18, 2014 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
We are proud to announce that The Ford Foundation has awarded us a grant to help our growing operations. The Ford Foundation is a major philanthropic entity both in the US and globally. One of its programmatic areas, Internet Freedom, is focused on creating a more open and inclusive Internet experience for all people. Our relationship with Ford was born out of this mutual desire. According to Michael Brennan, Ford Foundation Internet Freedom Program Officer, “We are thrilled to be able to support the growth of a Web that meets the needs of all its users through Let’s Encrypt.” This grant will support various software development staff and activities, including the work we recently did to add support for Internationalized Domain Name (IDN) certificates. If your company or organization would like to sponsor Let’s Encrypt, please email us at sponsor@letsencrypt.org.
First reported Oct 27, 2016 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
We’re excited that Squarespace has decided to protect the millions of sites they host with HTTPS! While talking with their team we learned they were deploying OCSP Stapling from the get-go, and we were impressed. We asked them to share their experience with our readers in our first guest blog post (hopefully more to come). - Josh Aas, Executive Director, ISRG / Let’s Encrypt OCSP stapling is an alternative approach to the Online Certificate Status Protocol (OCSP) for checking the revocation status of certificates. It allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses by appending (“stapling”) a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA. The certificate holder queries the OCSP responder at regular intervals and caches the responses. Traditional OCSP requires the CA to provide responses to each client that requests certificate revocation information. When a certificate is issued for a popular website, a large amount of queries start hitting the CA’s OCSP responder server. This poses a privacy risk because information must pass through a third party and the third party is able to determine who browsed which site at what time. It can also create performance problems, since most browsers will contact the OCSP responder before loading anything on the web page. OCSP stapling is efficient because the user doesn’t have to make a separate connection to the CA, and it’s safe because the OCSP response is digitally signed so it cannot be modified without detection. OCSP Stapling @ Squarespace As we were planning our roll out of SSL for all custom domains on the Squarespace platform, we decided that we wanted to support OCSP stapling at time of launch. A reverse proxy built by our Edge Infrastructure team is responsible for terminating all SSL traffic, it’s written in Java and is powered by Netty. Unfortunately, the Java JDK 8 only has preliminary, client-only, OCSP stapling support. JDK 9 introduces OCSP stapling with JEP 249, but it is not available yet. Our reverse proxy does not use the JDK’s SSL implementation. Instead, we use OpenSSL via netty-tcnative. At this time, neither the original tcnative nor Netty’s fork have OCSP stapling support. However, the tcnative library exposes the inner workings of OpenSSL, including the address pointers for the SSL context and engine. We were able to use JNI to extend the netty-tcnative library and add OCSP stapling support using the tlsext_status OpenSSL C functions. Our extension is a standalone library but we could equally well fold it into the netty-tcnative library itself. If there is interest, we can contribute it upstream as part of Netty’s next API-breaking development cycle. One of the goals of our initial OCSP stapling implementation was to take the biggest edge off of the OCSP responder’s operator, in this case Let’s Encrypt. Due to the nature of the website traffic on our platform, we have a very long tail. At least to start, we don’t pre-fetch and cache all OCSP responses. We decided to fetch OCSP responses asynchronously and we try to do it only if more than one client is going to use it in the foreseeable future. Bloom filters are utilized to identify “one-hit wonders” that are not worthy of being cached. Squarespace invests in the security of our customers’ websites and their visitors. We will continue to make refinements to our OCSP stapling implementation to eventually have OCSP staples on all requests. For a more in depth discussion about the security challenges of traditional OCSP, we recommend this blog post.
First reported Oct 24, 2016 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Let’s Encrypt is proud to introduce Sunlight, a new implementation of a Certificate Transparency log that we built from the ground up with modern Web PKI opportunities and constraints in mind. In partnership with Filippo Valsorda, who led the design and implementation, we incorporated feedback from the broader transparency logging community, including the Chrome and TrustFabric teams at Google, the Sigsum project, and other CT log and monitor operators. Their insights have been instrumental in shaping the project’s direction. CT plays an important role in the Web PKI, enhancing the ability to monitor and research certificate issuance. The operation of a CT log, however, faces growing challenges with the increasing volume of certificates. For instance, Let’s Encrypt issues over four million certificates daily, each of which must be logged in two separate CT logs. Our well-established “Oak” log currently holds over 700 million entries, reflecting the significant scale of these challenges. In this post, we’ll explore the motivation behind Sunlight and how its design aims to improve the robustness and diversity of the CT ecosystem, while also improving the reliability and performance of Let’s Encrypt’s logs. Bottlenecks from the Database Let’s Encrypt has been running public CT logs since 2019, and we’ve gotten a lot of operational experience with running them, but it hasn’t been trouble-free. The biggest challenge in the architecture we’ve deployed for our “Oak” log 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 5 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 16TiB 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. Serving Tiles Initially, Let’s Encrypt only planned on building a new CT log implementation. However, our discussions with Filippo made us realize that other transparency systems had improved on the original Certificate Transparency design, and we could make our logs even more robust and scalable by changing the read path APIs. In particular, the Go Checksum Database is inspired by Certificate Transparency, but uses a more efficient format for publishing its data as a series of easily stored and cached 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. Sunlight 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 Sunlight specification. Even Trillian, the current implementation of CT we run, uses a subtree system simila
First reported Mar 14, 2024 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Today we’d like to explain what it costs to run Let’s Encrypt. We’re doing this because we strive to be a transparent organization, we want people to have some context for their contributions to the project, and because it’s interesting. Let’s Encrypt will require about $2.9M USD to operate in 2017. We believe this is an incredible value for a secure and reliable service that is capable of issuing certificates globally, to every server on the Web free of charge. We’re currently working to raise the money we need to operate through the next year. Please consider donating or becoming a sponsor if you’re able to do so! In the event that we end up being able to raise more money than we need to just keep Let’s Encrypt running we can look into adding other services to improve access to a more secure and privacy-respecting Web. Here’s how our 2017 budget breaks down: Expense Cost Staffing $2.06M USD Hardware/Software $0.20M USD Hosting/Auditing $0.30M USD Legal/Administrative $0.35M USD Total $2.91M USD Staffing is our dominant cost. We currently have eight full time employees, plus two full time staff that are employed by other entities (Mozilla and EFF). This includes five operations/sysadmin staff, three software developers, one communications and fundraising person, and an executive director. Our 2017 budget covers salary and benefits for ten employees. Our systems administration staff are at the heart of our day to day operations. They are responsible for building and improving our server, networking, and deployed software infrastructure, as well as monitoring the systems every hour of every day. It’s the critical 24/7 nature of the work that makes this our biggest team. Any issues need to be dealt with immediately, ideally with multiple people on hand. Our software developers work primarily on boulder, our open source CA software. We needed to write our own software in order to create a secure, reliable, and fully-automated CA that is capable of issuing and managing enough certificates to serve the entire Web. Our software development staff also allow us to support new features much more quickly than we could if we relied on third party software for implementation. The majority of our administrative support (e.g. HR, payroll, accounting) is provided by the Linux Foundation, so we don’t hire for those roles and related expenses come in under the “Legal/Administrative” category. Hardware expenses include compute, storage, networking, and HSM hardware, as well as the associated support contracts. There is quite a bit of duplication for redundancy. Software expenses are low since the majority of the software we use is freely available open source software. Hosting costs include space in two different highly secure geographically separated rooms inside secure data centers, as well as internet connections and power. The hardware and physical infrastructure we have in place is capable of issuing hundreds of millions of certificates - enough for every server on the Web. We need to maintain strong physical control over all hardware and infrastructure related to certificate issuance and management for security and auditing reasons. Auditing costs include the required annual WebTrust audits as well as third party expert security review and testing. The third party security audits include code review, infrastructure review, penetration testing, and ACME protocol analysis. We are not required to do third party auditing beyond the WebTrust audits, but it would be irresponsible of us not to. Legal costs go towards attorney time, primarily in the areas of corporate governance, contract development and review, and trademarks. Administrative costs include HR, payroll and benefits management, accounting and tax services, as well as travel and other miscellaneous operating costs. Our 2016 budget is very similar to our 2017 budget, the
First reported Sep 20, 2016 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
We’re pleased to announce that OVH has become a Platinum sponsor of Let’s Encrypt. According to OVH CTO and Founder Octave Klaba, “OVH is delighted to become a Platinum sponsor. With Let’s Encrypt, OVH will be able to set a new standard for security by offering end-to-end encrypted communications by default to all its communities.” The Web is an increasingly integral part of our daily lives, and encryption by default is critical in order to provide the degree of security and privacy that people expect. Let’s Encrypt’s mission is to encrypt the Web and our sponsors make pursuing that mission possible. OVH’s sponsorship will help us to pay for staff and other operation costs in 2016. If your company or organization would like to sponsor Let’s Encrypt, please email us at sponsor@letsencrypt.org.
First reported Dec 21, 2015 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Update 2015-10-12: These documents are now out of date. Please visit our Policy and Legal Repository for up-to-date documents. Today we’re publishing an updated draft of our Certificate Policy (CP) and the first public draft of our Certification Practice Statement (CPS). These are important documents for any Certificate Authority (CA), and we want to give people a chance to review ours before we start issuing certificates. Please let us know if you have any questions or comments.
First reported Apr 23, 2015 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
For more than ten years, we at the nonprofit Internet Security Research Group (ISRG) have been focused on our mission of building a more secure and privacy-respecting Internet for everyone, everywhere. As we touch on in our 2023 Annual Report, we now serve more than 360 million domains with free TLS certificates. Beyond being a big number, what does that signify? What’s the importance of having TLS being widely adopted anyway? We’ll take a closer look at these questions through the lens of one group of Subscribers we can relate to particularly well: nonprofits. Serving .org at Internet scale Let’s Encrypt serves 57% of all websites using the .org top level domain (TLD), which is commonly used by nonprofits. In the US alone there are 1.8M registered nonprofit organizations. And while the focus of these organizations is varied, all of them rely on the Internet in some capacity. When a nonprofit uses a TLS certificate on their website, it protects their visitors and stakeholders from snoopers, MITM attacks, and surveillance. Without TLS, nonprofits’ content could be changed without their knowledge or their visitors’ private information could be compromised. Access to free and automated TLS via Let’s Encrypt means these nonprofits face as few barriers as possible to adopting TLS. In short, something as fundamental as security and privacy should be as easy to access as possible. For nonprofits both large and small, Let’s Encrypt makes it easy to provide security and privacy for users of their websites, enabling them to remain focused on their missions. Zooming in on three nonprofits we serve The American Civil Liberties Union (ACLU) uses Let’s Encrypt as it works to realize its focus of being a “guardian of liberty” for US citizens. Using Let’s Encrypt protects ACLU’s constituents when they’re trying to know their rights or take action. With more than 4 million page views per month, ACLU’s website is a critical part of their mission. Human Rights Watch (HRW) is an international nonprofit organization. With more than 500 individuals on staff around the world, HRW’s website is a trove of information empowering individuals and organizations alike to be informed and take action with a global perspective. Nearly 70% of HRW’s web traffic comes from people outside of the United States; that’s millions of page views per month secured by Let’s Encrypt—and by extension, millions of people around the world benefitting from a more secure and privacy-respecting Web. The Center for Democracy & Technology (CDT) uses Let’s Encrypt to advance its mission to promote democratic values by shaping technology policy and architecture, with a focus on the rights of the individual. The CDT website offers updated and insightful information into the ways policy and innovation impact the digital space. Without a TLS certificate, the content of these pages could be intercepted and changed. What’s more, for those looking to financially support CDT, using TLS on their donation page encrypts the transaction protecting user details such as credit card and other personal information. Mallory Knodel, CTO at CDT and longtime digital rights defender and advocate commented, “Billions of people in over 60 countries access the internet with less censorship and surveillance because Let’s Encrypt hastened the adoption of web security measures by making certificates easy to obtain.” Serving philanthropic foundations In the United States, the work of nonprofits is made possible in large part through philanthropic foundations and organizations. When it comes to philanthropy’s web presence, Let’s Encrypt is there, too. We provide TLS to billion dollar philanthropic organizations like the Hewlett Foundation, the Silicon Valley Community Foundation, Yield Giving, and many others. Taking a look at the top 50 philanthropic
First reported Dec 13, 2023 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
As planned, the DST Root CA X3 has expired and we’re now using our own ISRG Root X1 for trust. We used a cross-sign with DST Root CA X3 to gain broad trust for our certificates when we were just starting out. Now our own root is widely trusted. For most websites, it was just another day on the Internet, but inevitably with such a big change some sites and configurations have issues. Our overview of the planned expiration is here. You can read about what we’ve done to make the process smoother. Most problems can be solved by updating the software on the machine that is having trouble. You may also find these links helpful: Our certificate compatibility page. Workarounds for OpenSSL 1.0.2. Whenever there is a significant change to our API, we post in the API Announcements category in our community forum. Sign in and click the bell for notifications to be sent to your email! If you want to hear even more from Let’s Encrypt and the nonprofit team behind it, subscribe to our newsletter. You’ll only receive a handful of emails each year. We (and our community) are here for you! If you have any questions about this change, search on our community forum or post on the thread we have to help you with this very topic. Supporting Let’s Encrypt As a nonprofit project, 100% of our funding comes from contributions from our community of users and supporters. We depend on their support in order to provide our services for the public benefit. If your company or organization would like to sponsor Let’s Encrypt please email us at sponsor@letsencrypt.org. If you can support us with a donation, we ask that you make an individual contribution.
First reported Oct 01, 2021 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Since its inception, Let’s Encrypt has been sending expiration notification emails to subscribers that have provided an email address to us via the ACME API. This service ended on June 4, 2025. The decision to end the service is the result of the following factors: Over the past 10 years more and more of our subscribers have been able to put reliable automation into place for certificate renewal. Providing expiration notification emails means that we have to retain millions of email addresses connected to issuance records. As an organization that values privacy, removing this requirement is important to us. Providing expiration notifications costs Let’s Encrypt tens of thousands of dollars per year, money that we believe can be better spent on other aspects of our infrastructure. Providing expiration notifications adds complexity to our infrastructure, which takes time and attention to manage and increases the likelihood of mistakes being made. Over the long term, particularly as we add support for new service components, we need to manage overall complexity by phasing out system components that can no longer be justified. For those who would like to continue receiving expiration notifications, we recommend using a third party service such as Red Sift Certificates Lite (formerly Hardenize). Red Sift’s monitoring service providing expiration emails is free of charge for up to 250 certificates. More monitoring options can be found here. We have deleted the email addresses provided to Let’s Encrypt via the ACME API that were stored in our CA database in association with issuance data. This doesn’t affect addresses signed up to mailing lists and other systems. They are managed in a separate ISRG system unassociated with issuance data. Going forward, if an email address is provided to Let’s Encrypt via the ACME API, Let’s Encrypt will not store the address but will instead forward it to the general ISRG mailing list system unassociated with any account data. If the email address has not been seen before, that system may send an onboarding email with information about how to subscribe to various sources of updates. If you’d like to stay informed about technical updates and other news about Let’s Encrypt and our parent nonprofit, ISRG, based on the preferences you choose, you can sign up for our email lists below:
First reported Jun 26, 2025 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
We’re pleased to announce that OVH has renewed their support for Let’s Encrypt as a Platinum sponsor for the next three years. OVH’s strong support for Let’s Encrypt will go a long way towards creating a more secure and privacy-respecting Web. OVH initially got in touch with Let’s Encrypt to become a Platinum sponsor shortly after our public launch in December of 2015. It was clear that they understood the need for Let’s Encrypt and our potential impact on the Web. “Over a year ago, when Let’s Encrypt came out of beta, it was an obvious choice for OVH to support this new certificate authority, and become a Platinum sponsor,” said Octave Klaba, Founder, CTO and Chairman. “We provided free Let’s Encrypt certificates to all our Web customers. At OVH today, over 2.2 million websites can be reached over a secure connection, and a total of 3.6 million certificates were created for our customers during the first year.” In the past year, Let’s Encrypt has grown to provide 28 million certificates to more than 31 million websites. The Web went from around 40% HTTPS page loads at the end of 2015 to 50% HTTPS page loads at the start of 2017. This is phenomenal growth for the Web, and Let’s Encrypt is proud to have been a driving force behind it. Of course, it wouldn’t have been possible without major hosting providers like OVH making it easier for their customers to enable HTTPS with Let’s Encrypt. OVH was one of the first major hosting providers to make HTTPS available to a large number of their customers, and they are continuing to expand the scope of services that are secure by default. “We then wanted to go one step further,” continues Octave Klaba. “We decided to launch SSL Gateway, powered by Let’s Encrypt. It’s an all-in-one front-end for your infrastructure with HTTPS encryption and anti-DDOS capability. It makes the Web even more secure and reliable. This service is now available to everyone, for free.” Financial and product commitments like these from OVH are moving the Web toward our goal of 100% encryption. We depend on support from organizations like OVH to continue operating. If your company or organization would like to sponsor Let’s Encrypt please email us at sponsor@letsencrypt.org.
First reported Mar 23, 2017 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
On Thursday, June 6th, 2024, we will be switching issuance to use our new intermediate certificates. Simultaneously, we are removing the DST Root CA X3 cross-sign from our API, aligning with our strategy to shorten the Let’s Encrypt chain of trust. We will begin issuing ECDSA end-entity certificates from a default chain that just contains a single ECDSA intermediate, removing a second intermediate and the option to issue an ECDSA end-entity certificate from an RSA intermediate. The Let’s Encrypt staging environment will make an equivalent change on April 24th, 2024. Most Let’s Encrypt Subscribers will not need to take any action in response to this change because ACME clients, like certbot, will automatically configure the new intermediates when certificates are renewed. The Subscribers who will be affected are those who currently pin intermediate certificates (more on that later). The following diagram depicts what the new hierarchy looks like. You can see details of all of the certificates on our updated Chain of Trust documentation page. New Intermediate Certificates Earlier this year, Let’s Encrypt generated new intermediate keys and certificates. They will replace the current intermediates, which were issued in September 2020 and are approaching their expiration. All certificates - issued by both RSA and ECDSA intermediates - will be served with a default chain of ISRG Root X1 → (RSA or ECDSA) Intermediate → End-Entity Certificate. That is, all certificates, regardless of whether you choose to have an RSA or ECDSA end-entity certificate, will have one intermediate which is directly signed by the ISRG Root X1, which is Let’s Encrypt’s most widely trusted root. The new ECDSA intermediates will also have an alternate chain to ISRG Root X2: ISRG Root X2 → ECDSA Intermediate → End-Entity Certificate. This is only applicable to a small number of Subscribers who prefer the smallest TLS handshake possible. To use this ECDSA-only chain, see your ACME client’s documentation on how to request alternate chains. There will not be any alternative chains for the RSA intermediates. It is important to note that there will now be multiple active RSA and two active ECDSA intermediates at the same time. An RSA leaf certificate may be signed by any of the active RSA intermediates (a value from “R10” to “R14” in the issuer common name field of your certificate), and an ECDSA leaf certificate may be signed by any of the active ECDSA intermediates (“E5” through “E9”). Again, your ACME client should handle this automatically. A Certificate Authority’s intermediate certificates expire every few years and need to be replaced, just like a website’s certificate is routinely renewed. Going forward, Let’s Encrypt intends to switch what intermediates are in use annually, which will help enhance the overall security of the certificates. Removing DST Root CA X3 Cross-sign The new intermediate chains will not include the DST Root CA X3 cross-sign, as previously announced in our post about Shortening the Let’s Encrypt Chain of Trust. By eliminating the cross-sign, we’re making our certificates leaner and more efficient, leading to faster page loads for Internet users. We already stopped providing the cross-sign in the default certificate chain on February 8th, 2024, so if your ACME client is not explicitly requesting the chain with DST Root CA X3, this will not be a change for you. ECDSA Intermediates as Default for ECDSA Certificates Currently, ECDSA end-entity certificates are signed by our RSA intermediates unless users opted in via a request form to use our ECDSA intermediates. With our new intermediates, we will begin issuing all ECDSA end-entity certificates from the ECDSA intermediates. The request form and allow-list will no longer be used, which we had introduced to make ECDSA intermediates available. Earlier, the default
First reported Apr 12, 2024 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
The trust of our users is ISRG’s most critical asset. Transparency regarding legal requests is an important part of making sure our users can trust us, and to that end we will be publishing reports twice annually. Reports will be published three months after the period covered in order to allow us time to research all requests and orders received during the period. Download Legal Transparency Report, July 2015 - December 2015
First reported Apr 01, 2016 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
If you work at a hosting provider or CDN, ACME’s DNS-01 validation method can make it a lot easier to onboard new customers who have an existing HTTPS website at another provider. Before your new customer points their domain name at your servers, you need to have a certificate already installed for them. Otherwise visitors to the customer’s site will see an outage for a few minutes while you issue and install a certificate. To fix this, you and your new customer should use the DNS-01 validation method to issue a certificate before the customer switches over DNS for their site. How the DNS Validation Method Works The DNS-01 validation method works like this: to prove that you control www.example.com, you create a TXT record at _acme-challenge.www.example.com with a “digest value” as specified by ACME (your ACME client should take care of creating this digest value for you). When the TXT record is ready, your ACME client informs the ACME server (for instance, Let’s Encrypt) that the domain is ready for validation. The ACME server looks up the TXT record, compares it to the expected digest value, and if the result is correct, considers your account authorized to issue for www.example.com. Your new customer can set up this TXT record (or a CNAME) without interfering with normal website operations. The Advantages of a CNAME There’s an additional trick that I recommend for hosting providers and CDNs: Instead of giving the digest value to your new customer and telling them to make a TXT record with it, tell your customer to configure a CNAME from _acme-challenge.www.example.com to a domain name that you control and that is unique to the domain being validated. For instance, you might use www.example.com.validationserver.example.net. Then, once your software has verified that this CNAME is set up (accounting for propagation delay and anycast), your ACME client should begin the validation process for www.example.com, provisioning a TXT record at www.example.com.validationserver.example.net. Because the ACME server’s TXT lookup follows CNAMEs (as do all DNS lookups), it will see the value you provisioned, and consider your account authorized. This approach is preferable to handing your customers a raw digest value for a few reasons. First, it gives your customers all the time they need to set up the CNAME. If you create a pending authorization up front and give your customer a digest value to deploy themselves, it has a fixed lifetime before it expires (for Let’s Encrypt this lifetime is 7 days). If your customer doesn’t complete the process in that time, you’ll have to create a new pending authorization and give your customer a new digest value. That’s annoying and time consuming for both you and your customer. The CNAME method means even if it takes your new customer a month to make the needed changes to their DNS, you can get things up and running as soon as they do. Another reason to prefer the CNAME method over having new customers directly provision their TXT records is to support the best practice of periodically rotating your ACME account key. Because the digest value used for DNS-01 validation is computed based on your current ACME account key, it will change whenever you rotate your account key. If you asked customers to provision their TXT record manually, that means notifying potential new customers that the value you asked them to put in DNS isn’t valid anymore, and they need to use a different one. That’s pretty inconvenient! If you use the CNAME method instead, there’s only one ACME-related value you’ll ever need to have your new customers put in DNS, and it won’t change as you change your account key. Cleaning Up Unused CNAMES One last note: This is a good way to onboard customers, but you also need to detect when customers offboard themselves. They may simply change their A records to point at a different CDN, without telling you that their plans have changed. You should monit
First reported Oct 09, 2019 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
On Wednesday, March 13, 2024, Let’s Encrypt generated 10 new Intermediate CA Key Pairs, and issued 15 new Intermediate CA Certificates containing the new public keys. These new intermediate certificates provide smaller and more efficient certificate chains to Let’s Encrypt Subscribers, enhancing the overall online experience in terms of speed, security, and accessibility. First, a bit of history. In September, 2020, Let’s Encrypt issued a new root and collection of intermediate certificates. Those certificates helped us improve the privacy and efficiency of Web security by making ECDSA end-entity certificates widely available. However, those intermediates are approaching their expiration dates, so it is time to replace them. Our new batch of intermediates are very similar to the ones we issued in 2020, with a few small changes. We’re going to go over what those changes are and why we made them. The New Certificates We created 5 new 2048-bit RSA intermediate certificates named in sequence from R10 through R14. These are issued by ISRG Root X1. You can think of them as direct replacements for our existing R3 and R4 intermediates. We also created 5 new P-384 ECDSA intermediate certificates named in sequence from E5 through E9. Each of these is represented by two certificates: one issued by ISRG Root X2 (exactly like our existing E1 and E2), and one issued (or cross-signed) by ISRG Root X1. You can see details of all of the certificates on our updated hierarchy page. Rotating Issuance Rotating the set of intermediates we issue from helps keep the Internet agile and more secure. It encourages automation and efficiency, and discourages outdated practices like key pinning. “Key Pinning” is a practice in which clients — either ACME clients getting certificates for their site, or apps connecting to their own backend servers — decide to trust only a single issuing intermediate certificate rather than delegating trust to the system trust store. Updating pinned keys is a manual process, which leads to an increased risk of errors and potential business continuity failures. Intermediates usually change only every five years, so this joint is exercised infrequently and client software keeps making the same mistakes. Shortening the lifetime from five years to three years means we will be conducting another ceremony in just two years, ahead of the expiration date on these recently created certificates. This ensures we exercise the joint more frequently than in the past. We also issued more intermediates this time around. Historically, we’ve had two of each key type (RSA and ECDSA): one for active issuance, and one held as a backup for emergencies. Moving forward we will have five: two conducting active issuance, two waiting in the wings to be introduced in about one year, and one for emergency backup. Randomizing the selected issuer for a given key type means it will be impossible to predict which intermediate a certificate will be issued from. We are very hopeful that these steps will prevent intermediate key pinning altogether, and help the WebPKI remain agile moving forward. These shorter intermediate lifetimes and randomized intermediate issuance shouldn’t impact the online experience of the general Internet user. Subscribers may be impacted if they are pinning one of our intermediates, though this should be incredibly rare. Providing Smaller Chains When we issued ISRG Root X2 in 2020, we decided to cross-sign it from ISRG Root X1 so that it would be trusted even by systems that didn’t yet have ISRG Root X2 in their trust store. This meant that Subscribers who wanted issuance from our ECDSA intermediates would have a choice: they could either have a very short, ECDSA-only, but low-compatibility chain terminating at ISRG Root X2, or they could have a longer, high-compatibility chain terminating at ISRG Root X1. At the time, this tradeoff (TLS handshake size vs compatibility)
First reported Mar 19, 2024 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
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 cert
First reported Aug 14, 2025 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Let’s Encrypt has been running a Certificate Transparency (CT) log since 2019 as part of our commitment to keeping the Web PKI ecosystem healthy. CT logs have become important infrastructure for an encrypted Web 1, but have a well-deserved reputation for being difficult to operate at high levels of trust: Only 6 organizations run logs that are currently considered to be “qualified.” 2 Our Oak log is the only qualified CT log that runs on an entirely open source stack 3. In the interest of lowering the barrier for other organizations to join the CT ecosystem, we want to cover a few recent changes to Oak that might be helpful to anyone else planning to launch a log based on Google’s Trillian backed by MariaDB: The disk I/O workload of Trillian atop MariaDB is easily mediated by front-end rate limits, and It’s worth the complexity to split each new annual CT log into its own Trillian/MariaDB stack. This post will update some of the information from the previous post How Let’s Encrypt Runs CT Logs. Growing Oak While Staying Open Source Oak runs on a free and open source stack: Google’s Trillian data store, backed by MariaDB, running at Amazon Web Services (AWS) via Amazon’s Relational Database Service (RDS). To our knowledge, Oak is the only trusted CT log without closed-source components 3. Open Source Stack Other operators of Trillian have opted to use different databases which segment data differently, but the provided MySQL-compatible datastore has successfully kept up with Let’s Encrypt’s CT log volume (currently above 400 GB per month). The story for scaling Oak atop MariaDB is quite typical for any relational database, though the performance requirements are stringent. Keeping Oak Qualified The policies that Certificate Transparency Log operators follow require there to be no significant downtime, in addition to the more absolute and difficult requirement that the logs themselves make no mistakes: Given the append-only nature of Certificate Transparency, seemingly minor data corruption prompts permanent disqualification of the log 4. To minimize the impacts of corruption, as well as for scalability reasons, it’s become normal for CT logs to distribute the certificates they contain in different, smaller individual CT logs, called shards. Splitting Many Years Of Data Among Many Trees The Let’s Encrypt Oak CT log is actually made up of many individual CT log shards each named after a period of time: Oak 2020 contains certificates which expired in 2020; Oak 2022 contains certificates which expire in 2022. For ease of reference, we refer to these as “temporal log shards,” though in truth each is an individual CT log sharing the Oak family name. It is straightforward to configure a single Trillian installation to support multiple CT log shards. Each log shard is allocated storage within the backing database, and the Trillian Log Server can then service requests for all configured logs. The Trillian database schema is quite compact and easy to understand: Each configured log gets a Tree ID, with metadata in several tables. All log entries – certificates in our case – get a row in LeafData. Entries that haven’t been sequenced yet get a row in the table Unsequenced, which is normally kept empty by the Trillian Log Signer service. Once sequenced, entries are removed from the Unsequenced table and added as a row in SequencedLeafData. Database Layout In a nutshell: No matter how many different certificate transparency trees and subtrees you set up for a given copy of Trillian, all of them will store the lion’s share of their data, particularly the DER-encoded certificates themselves, interwoven into the one LeafData table. Since Trillian Log Server can only be configured with a single MySQL connection URI, limiting it to a single database, that single table can get quite big. For Oak, the database currently grow
First reported May 19, 2022 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
Today we kicked off our first crowdfunding campaign with the goal of raising enough funds to cover about one month of our operations - $200,000. That amount covers the operational and engineering staff, the hardware and the software, and general operating expenses needed to securely and reliably issue and manage many millions of certificates. We decided to run a crowdfunding campaign for a couple of reasons. First, there is a gap between the funds we’ve raised and what we need for next year. Second, we believe individual supporters from our community can come to represent a significant diversification of our annual revenue sources, in addition to corporate sponsorship and grants. We will provide updates on our progress throughout the campaign via Twitter (@letsencrypt). Thank you for your support!
First reported Nov 01, 2016 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
We’re excited that Facebook is supporting our work through a three-year Platinum sponsorship! We asked them to share their thoughts on HTTPS adoption here. Please join us in thanking Facebook for their support of Let’s Encrypt and our mission to encrypt the Web! - Josh Aas, Executive Director, ISRG / Let’s Encrypt If the web is more secure, everybody wins. A key technology for making this happen is HTTPS, which enables encrypted connections between people and the websites that they visit. Among its many benefits, HTTPS helps to prevent sensitive data from leaking over the network, and from connections being censored or otherwise maliciously manipulated. The more widely it is deployed, the more secure and private the web becomes for everyone. We have long worked to protect Facebook users from spammy or malicious content when navigating away from our platform, and last year we extended this protection to upgrading outbound HTTP links to HTTPS where possible. In this way we can help improve people’s security and privacy as they leave our platform. While we take these steps to improve the security and safety of Facebook users, ultimately we hope to see more websites allowing HTTPS connections. Enabling HTTPS was historically a non-trivial task for any site. It required investment in buying and installing a TLS certificate, which verifies control over the website so that HTTPS can work. The technical difficulty and cost used to serve as barriers to expanding the use of HTTPS across the web. However, things have recently started to change, largely thanks to Let’s Encrypt, a non-profit certificate authority, launched in 2015. Let’s Encrypt provides free TLS certificates, which are often installed using a tool maintained by the Electronic Frontier Foundation, to massively simplify enabling HTTPS. With that, Let’s Encrypt is effectively upgrading the security and privacy of the web, at no cost to over 150 million websites, including those frequented by Facebook users. We’re excited to see the continuous increase in HTTPS adoption across the internet. More websites are choosing to enable secure connections which provide the security and privacy benefits and enable a better browsing experience. For example, navigating from Facebook to another site can be faster over encrypted connections than HTTP, and an increasing number of browser features will only work when sites use HTTPS. We have sponsored Let’s Encrypt from the start, and are proud to share that we are increasing that support as a platinum sponsor. We believe that Let’s Encrypt has played a significant and important role in bringing encryption into the mainstream and raising the number of secure sites across the internet. As we automatically crawl web content on Facebook (for example, to generate link previews), about 38% of HTTPS domains we observe use Let’s Encrypt, making it the top certificate authority. Over 19% of outbound clicks from Facebook to HTTPS-enabled websites go to sites that use certificates from Let’s Encrypt. Overall, more than 72% of outbound clicks from Facebook are now destined for HTTPS-enabled websites, including the links that we upgrade to HTTPS in real time. We’re proud to continue to collaborate with Let’s Encrypt on helping to improve web security. To any website owners who haven’t yet enabled encryption, we strongly encourage you to use Let’s Encrypt to protect your users and allow HTTPS connections.
First reported Feb 12, 2019 00:00 UTCCatalog metadata updated Oct 14, 2026 12:12 UTCOpen evidence record
The public shared-host view reaches the newest 2,400 matching records. Narrow the filters or search an exact MD5, SHA-1, or SHA-256 value to reach a specific record.
A filename, label, or report mention alone does not establish maliciousness. Observation dates describe cited sources; collection dates describe this local metadata catalog. No malware samples are stored, fetched, or executed by these pages.