Published file metadata, source observations, indicators, and research history in one bounded catalog.
2,400+Reachable catalog records
97 / 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’re happy to announce that Let’s Encrypt has entered Public Beta. Invitations are no longer needed in order to get free certificates from Let’s Encrypt. It’s time for the Web to take a big step forward in terms of security and privacy. We want to see HTTPS become the default. Let’s Encrypt was built to enable that by making it as easy as possible to get and manage certificates. We’d like to thank everyone who participated in the Limited Beta. Let’s Encrypt issued over 26,000 certificates during the Limited Beta period. This allowed us to gain valuable insight into how our systems perform, and to be confident about moving to Public Beta. We’d also like to thank all of our sponsors for their support. We’re happy to have announced earlier today that Facebook is our newest Gold sponsor. We have more work to do before we’re comfortable dropping the beta label entirely, particularly on the client experience. Automation is a cornerstone of our strategy, and we need to make sure that the client works smoothly and reliably on a wide range of platforms. We’ll be monitoring feedback from users closely, and making improvements as quickly as possible. Instructions for getting a certificate with the Let’s Encrypt client can be found here. Update: Feb. 10 2016, instructions for getting a certificate with Certbot (Let’s Encrypt recommended client) can be found here. Let’s Encrypt Community Support is an invaluable resource for our community, we strongly recommend making use of the site if you have any questions about Let’s Encrypt. Let’s Encrypt depends on support from a wide variety of individuals and organizations. Please consider getting involved, and if your company or organization would like to sponsor Let’s Encrypt please email us at sponsor@letsencrypt.org.
First reported Dec 03, 2015 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
Let’s Encrypt launched a Certificate Transparency (CT) log this past spring. We’re excited to share how we built it in hopes that others can learn from what we did. CT has quickly become an important piece of Internet security infrastructure, but unfortunately it’s not trivial to run a good log. The more the CT community can share about what has been done, the better the ecosystem will be. Sectigo and Amazon Web Services have generously provided support to cover a significant portion of the cost of running our CT log. “Sectigo is proud to sponsor the Let’s Encrypt CT Log. We believe this initiative will provide much-needed reinforcement of the CT ecosystem,” said Ed Giaquinto, Sectigo’s CIO. For more background information about CT and how it works, we recommend reading “How Certificate Transparency Works.” If you have questions about any of what we’ve written here, feel free to ask on our community forums. Objectives Scale: Let’s Encrypt issues over 1 million certificates per day, and that number grows each month. We want our log to consume our certificates as well as those from other CAs, so we need to be able to handle as many as 2 million or more certificates per day. To support this ever-increasing number of certificates, CT software and infrastructure need to be architected for scale. Stability and Compliance: We target 99% uptime, with no outage lasting longer than 24 hours, in compliance with the Chromium and Apple CT policies. Sharding: Best practice for a CT log is to break it into several temporal shards. For more information on temporal sharding, check out these blog posts. Low Maintenance: Staff time is expensive, we want to minimize the amount of time spent maintaining infrastructure. System Architecture Staging and Production Logs We run two equivalent logs, one for staging and one for production. Any changes we plan to make to the production log are first deployed to the staging log. This is critical for making sure that updates and upgrades don’t cause problems before being deployed to production. You can find access details for these logs in our documentation. We keep the staging log continually under production-level load so that any scale-related problems manifest there first. We also use the staging CT log to submit certificates from our staging CA environment, and make it available for use by other CAs’ staging environments. As a point of clarification, we consider a log to be comprised of several temporal shards. While each shard is technically a separate log, it makes sense to conceptualize the shards as belonging to a single log. Amazon Web Services (AWS) We decided to run our CT logs on AWS for two reasons. One consideration for us was cloud provider diversity. Since there are relatively few trusted logs in the ecosystem, we don’t want multiple logs to go down due to a single cloud provider outage. At the time we made the decision there were logs running on Google and Digital Ocean infrastructure, as well as self-hosted. We were not aware of any on AWS (in hindsight we may have missed the fact that Digicert had started using AWS for logs). If you’re thinking about setting up a trusted log for CAs to use, please consider cloud provider diversity. Additionally, AWS provides a solid set of features and our team has experience using it for other purposes. We had little doubt that AWS was up to the task. Terraform Let’s Encrypt uses Hashicorp Terraform for a number of cloud-based projects. We were able to bootstrap our CT log infrastructure by reusing our existing Terraform code. There are roughly 50 components in our CT deployments, including EC2, RDS, EKS, IAM, security groups, and routing. Centrally managing this code allows our small team to reproduce a CT infrastructure in any Amazon region of the globe, prevent configuration drift, and easily test infrastructure changes. Database We chose to use MariaDB for our CT log database because we have extensive experience us
First reported Nov 20, 2019 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
NGINX and Let's Encrypt share a common vision of an open and secure web. Now, with built-in support for ACME, the world's most popular web server, reverse proxy and ingress controller for Kubernetes can simplify certificate management for everyone. From the home lab to scaled-out, mission-critical enterprise deployments. — Liam Crilly, Sr Dir, Product Management, F5 NGINX 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.
First reported Sep 11, 2025 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
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 t
First reported Dec 09, 2025 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
This letter was originally published in our 2023 Annual Report. We typically open our annual report with a letter from our Executive Director and co-founder, Josh Aas, but he’s on parental leave so I’ll be filling in. I’ve run the Brand & Donor Development team at ISRG since 2016, so I’ve had the pleasure of watching our work mature, our impact grow, and I’ve had the opportunity to get to know many great people who care deeply about security and privacy on the Internet. One of the biggest observations I’ve made during Josh’s absence is that all 23 people who work at ISRG fall into that class of folks. Of course I was a bit nervous as Josh embarked on his leave to discover just how many balls he has been keeping in the air for the last decade. Answer: it’s a lot. But the roster of staff that we’ve built up made it pretty seamless for us to keep moving forward. Let’s Encrypt is supporting 40 million more websites than a year ago, bringing the total to over 360 million. The engineering team has grown to 12 people who are responsible for our continued reliability and ability to scale. But they’re not maintaining the status quo. Let’s Encrypt engineers are pushing forward our expectations for ourselves and for the WebPKI community. We’ve added shorter-lived certificates to our 2024 roadmap. We’re committing to this work because sub-10 day certificates significantly reduce the impact of key compromise and it broadens the universe of people who can use our certs. In addition, the team started an ambitious project to develop a new Certificate Transparency implementation because the only existing option cannot scale for the future and is prone to operational fragility. These projects are led by two excellent technical leads, Aaron Gable and James Renken, who balance our ambition with our desire for a good quality of life for our teams. Prossimo continues to deliver highly performant and memory safe software and components in a world that is increasingly eager to address the memory safety problem. This was evidenced by participation at Tectonics, a gathering we hosted which drew industry leaders for invigorated conversation. Meanwhile, initiatives like our memory safe AV1 decoder are in line to replace a C version in Google Chrome. This change would improve security for billions of people. We’re grateful to the community that helps to guide and implement our efforts in this area, including Dirkjan Ochtman, the firms Tweede golf and Ferrous Systems, and the maintainers of the many projects we are involved with. Our newest project, Divvi Up, brought on our first two subscribers in 2023. Horizontal, a small international nonprofit serving Human Rights Defenders, will be collecting privacy-preserving telemetry metrics about the users of their Tella app, which people use to document human rights violations. Mozilla is using Divvi Up to gain insight into aspects of user behavior in the Firefox browser. It took a combination of focus and determination to get us to a production-ready state and our technical lead, Brandon Pitman, played a big role in getting us there. We hired Kristin Berdan to fill a new role as General Counsel and her impact is already apparent within our organization. She joins Sarah Heil, our CFO, Josh, and me in ISRG leadership. Collectively, we operate three impactful and growing projects for $7 million a year. This is possible because of the amazing leadership assembled across our teams and the ongoing commitment from our community to validate the usefulness of our work. As we look toward 2024 and the challenges and opportunities that face us, I ask that you join us in building a more secure and privacy respecting Internet by sponsoring us, making a donation or gift through your DAF, or sharing with the folks you know why security and privacy matter to them. Support Our Work ISRG is a 501(c)(3) nonprofit organization that is 100
First reported Dec 28, 2023 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
When the scripts that generate the data for letsencrypt.org/stats broke yet again, we decided to retire them rather than repair them. Let’s Encrypt issues six to ten million certificates each day, producing a large volume of logs that keeps growing. It became increasingly time-consuming and difficult to answer questions about our own issuance like “how many certificates use the ‘shortlived’ profile.” Using raw logs, this requires finding, parsing and extracting relevant portions of loglines. Querying the database behind our issuance API is not a practical option, as it’s built for transactions rather than analysis. We’d also used a log search SaaS product, but our bills were growing much faster than we’d like, and while it was fine for searching, it wasn’t able to do the analytic workloads we needed. We knew we could dream bigger and better. Daily issuance of Let’s Encrypt certificates over the last 180 days This led us to seek a self-hosted solution with efficient storage for structured data in addition to logs. We chose ClickHouse because of its potential as a data warehouse; the combination of cost-efficient storage and fast aggregation over large datasets appealed to us. A bonus of ClickHouse is that it is open source, a key principle valued by Let’s Encrypt. The first step in building our new infrastructure was to purchase new hardware. To back our ClickHouse warehouse, we bought three PowerEdge R7715 servers. Each is equipped with a 32-core AMD EPYC 9355P 3.55GHz processor, 384 GB of RAM and 32 × 3.2TB NVMe drives, working out to roughly 100TB raw storage. With structured data and 100 days’ worth of logs already in our database, we are only at ~14% of total capacity, leaving lots of room for future growth. Logs are the bulk of our storage use and the foundation of our structured data, as every other table we build is derived from them. When it comes to log search, ClickHouse covers our basic needs with quick ingest and interactive SQL. However, there are query ergonomics that we want to improve, like using OpenTelemetry’s tracing features and ClickHouse’s tokenization settings. Our primary target for structured data is our issuance records. A materialized view extracts those records from logs into their own table, and further views pre-aggregate from there. One such view counts issuance by day per profile. Now, questions like “what is our issuance by profile over the last 180 days” can be answered within milliseconds. Daily issuance count of certificates by profile, excluding “classic”, over the last 180 days We used this approach to completely rebuild the pipeline for our public stats page. The scripts we abandoned used to take hours each day to read and process dozens of compressed data files. The Rube-Goldberg-Machine-like collection of steps failed several times a year, requiring us to intervene and fix it. ClickHouse now computes those same stats in less than 10 seconds. Aside from pre-aggregated issuance tables, we can accomplish this because ClickHouse’s native functions are capable of quick and complex aggregations. Below is a simplified snippet of our materialized view for daily stats, counting the unique set of active domains over months across millions of rows. Two things to point out about this query: array handling means we can query nested fields without reshaping the underlying data, and uniq uses approximations to stay fast at scale. SELECT uniq(arrayJoin(arrayMap(x -> x.value, arrayFilter(x -> x.type = 'dns', identifiers)))) AS fqdns_active, uniq(arrayJoin(etld_plus_one)) AS reg_domains_active FROM boulder.cert_issuances WHERE not_before >= yesterday() - 90 AND not_after >= yesterday() AND not_before <= yesterday() Our ClickHouse issuance data also addresses the previous headache of identifying affected certificates during incidents. It used to take hours of engineer time to correctly scan and parse logs to find the affected set of ser
First reported Sep 17, 2026 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
Let’s Encrypt is pleased to introduce support for issuing certificates that contain Internationalized Domain Names (IDNs). This means that our users around the world can now get free Let’s Encrypt certificates for domains containing characters outside of the ASCII set, which is built primarily for the English language. We’re excited about this feature because our goal is to serve the entire Web, including those who want to use domains with language-specific characters. This feature was also commonly requested by our community. There are more details on how to request a certificate containing IDNs at our community forum. Visit our Getting Started page for information on how to request certificates in general. Let’s Encrypt depends on industry and community support. Please consider getting involved, and if your company or organization would like to sponsor Let’s Encrypt please email us at sponsor@letsencrypt.org.
First reported Oct 21, 2016 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
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 a
First reported Dec 02, 2025 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
It has long been a dream of ours for there to be a standardized protocol for certificate issuance and management. That dream has become a reality now that the IETF has standardized the ACME protocol as RFC 8555. I’d like to thank everyone involved in that effort, including Let’s Encrypt staff and other IETF contributors. Having a standardized protocol for certificate issuance and management is important for two reasons. First, it improves the quality of the software ecosystem because developers can focus on developing great software for a single protocol, instead of having many pieces of less well maintained software for bespoke APIs. Second, a standardized protocol makes switching from one CA to another easier by minimizing technical dependency lock-in. We consider the standardized version of the ACME protocol to be the second major version of ACME, so we refer to it as ACMEv2. The first version, which we call ACMEv1, is the version of ACME that Let’s Encrypt has used since our launch in 2015. Now that ACMEv2 is standardized, we are announcing an end-of-life plan for our ACMEv1 support. Let’s Encrypt is currently providing certificates for more than 150 million websites. We look forward to being able to serve even more websites as efforts like this make deploying HTTPS with Let’s Encrypt even easier. If you’re as excited about the potential for a 100% HTTPS Web as we are, please consider getting involved, making a donation, or sponsoring Let’s Encrypt.
First reported Mar 11, 2019 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
Since March 2023, Let’s Encrypt has been improving our resiliency and reliability via ACME Renewal Information (ARI). ARI makes it possible for our Subscribers to handle certificate revocation and renewal easily and automatically. A primary benefit of ARI is that it sets Subscribers up for success in terms of ideal renewal times in the event that Let’s Encrypt offers certificates with even shorter lifetimes than 90 days. We recently published a guide for engineers on how to integrate ARI into existing ACME Clients. In this blog post, we’ll explore Let’s Encrypt Subscriber Tailscale’s experience adopting ARI. In total, it took just two Tailscale engineers less than two days to implement ARI. Prior to ARI, the Tailscale team had made other iterations of cert renewal logic, including hardcoding renewal 14 days before expiry and hardcoding 1/3rd of remaining time until expiry. An issue with these approaches was that assumptions were made about the validity period of certificates issued by Let’s Encrypt, which will change in the future. In contrast, ARI allows Tailscale to offload the renewal decision to Let’s Encrypt without making any assumptions. Tailscale noted that ARI was especially useful to add before certificates’ validity period starts shortening, as their client software in charge of requesting and renewing certificates is running on user machines. This makes it so they cannot easily update the whole fleet overnight if any issues come up. Thanks to ARI, they’ve reduced the risk of not rotating certificates for client machines in time, or causing excessive load on Let’s Encrypt’s infrastructure with overly-eager rotation logic. One consideration the Tailscale team factored in deciding to adopt ARI was wanting to avoid adding a hard dependency on the Let’s Encrypt infrastructure for renewal. To remedy this, Tailscale certificate renewal logic falls back to a local time-based check if the ARI endpoint cannot be reached for any reason. Tailscale’s roadmap for getting ARI in production: Updated their fork of golang.org/x/crypto to support ARI Updated the renewal code in the Tailscale client Tested it locally by requesting certificates for a dev domain Tested renewal by stubbing out ARI response with hardcoded data Tested fallback by blocking ARI requests Shipped it! The team reported running into one snag during the process. Because the RFC is not finalized, the upstream Go package for ACME doesn’t support ARI yet. As a solution, they added support in their fork of that Go package. Tailscale’s main piece of advice for Subscribers adopting ARI: don’t forget to put a timeout on your ARI request! We’re grateful to the Tailscale team for taking the time to share with us their experience adopting ARI and advice for fellow Subscribers. In addition to being an ARI adopter, Tailscale is a Let’s Encrypt Sponsor! We appreciate their support of our work to build a more secure Web. We’re also grateful to be partnering with Princeton University on our ACME Renewal Information work, thanks to generous support from the Open Technology Fund. Internet Security Research Group (ISRG) is the parent organization of Let’s Encrypt, Prossimo, and Divvi Up. ISRG is a 501(c)(3) nonprofit. If you’d like to support our work, please consider getting involved, donating, or encouraging your company to become a sponsor.
First reported May 01, 2024 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
At Let’s Encrypt we know that building a secure Internet isn’t just a technical challenge—it’s a long-term commitment. Over the past decade we’ve made enormous strides: from issuing billions of TLS certificates to continually innovating to keep the web safer and more accessible. But none of this would be possible without recurring donations from individuals and organizations around the world. Recurring donations are more than just financial support; they allow us to plan, innovate, and keep improving with confidence, knowing that month after month, year after year, our supporters are there. This consistent backing empowers us to maintain a secure, privacy-respecting Internet for all. Our tenth anniversary tagline, Encryption for Everybody, highlights this vision. It’s both a technical goal and a fundamental belief that secure communication should be available to everyone, everywhere. When we asked our recurring donors why they give, their responses affirmed how essential this commitment is. One longtime supporter shared: Supporting Let's Encrypt aligns with my belief in a privacy-conscious world, where encrypted communication is the default. For some, it’s about paying it forward, helping future users benefit as they once did: For my 18th birthday, I got my last name as a domain. As a young tech enthusiast with little money, Let's Encrypt made it possible for me to get a TLS certificate and learn about technology. Back then, I was a student using it for free. Now that I have a stable income, donating is my way of giving back and helping others have the same opportunities I did. The next decade of Let’s Encrypt will likely be about maintaining that commitment to encryption for everybody. It’s about ensuring that our work remains reliable, accessible, and—most importantly—supported by people who believe in what we do. To everyone who’s been part of this journey, thank you. We couldn’t do it without you. During Let’s Encrypt’s 10th Anniversary Year, we’re celebrating our community and reflecting on our journey. We’d be thrilled to hear from you. Connect with us on LinkedIn, our community forum, or email us at outreach@letsencrypt.org. Let’s keep building a secure Internet together! Let’s Encrypt is a project of the nonprofit Internet Security Research Group, a 501(c)(3) nonprofit. To support our work, visit letsencrypt.org/donate.
First reported May 21, 2025 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
On February 10, 2027, all Let’s Encrypt subscribers will move to certificates with 64 day lifetimes by default unless they select an even shorter lifetime (45 or 6 days, as previously announced). This means that any certificate we issue or renew on and after that date will have a 64 day validity period, and we expect the last 90-day certificate to expire on May 11, 2027. We will not revoke valid certificates as a part of this process. We will switch to issuing 64 day certificates in our staging environment on October 14, 2026 to enable testing. We recommend testing in staging before the change takes effect in production. If your renewals are automated and your client supports ACME Renewal Info (ARI), you should be all set since ARI allows Let’s Encrypt to tell your client when to renew (you can review your ACME client’s documentation to determine if ARI is implemented). If your renewals are hard-coded to a date from expiration you should update them to renew at approximately ⅔ of the lifetime instead. Taking this step in preparation for 64 day lifetimes will lay the groundwork for default lifetimes of 45 days in 2028. Grep for common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks if you’re not sure. We will also be reducing the authorization reuse period from 30 days to 10 days. In 2028, the reuse period will shrink to seven hours. We are making this change to comply with a 2029 reduction in maximum validation reuse periods, and to remove the need for “CAA rechecking”, where we have to repeat part of the validation process if the validation data is more than 7 hours old. Unless you have specifically designed your ACME client to rely on validation reuse, you will not need to make any changes. This is also an opportunity to automate certificate management processes like reload and deployment and to add alerting for renewal failures. Rate limits will not be impacted by this change; you can learn more in our previous blog post. This change will not affect ACME endpoints or our issuance chains. We are moving to shorter certificate lifetimes because this reduces the risk of key compromise and mis-issuance. As a nonprofit we see it as part of our mission to make this change to advance security for everyone using the Web globally. We anticipate a smooth transition, but if you experience issues, our community forum and documentation are good resources.
First reported Oct 07, 2026 00:00 UTCCatalog metadata updated Oct 13, 2026 00:10 UTCOpen evidence record
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 13, 2026 00:10 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 13, 2026 00:10 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 13, 2026 00:10 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 13, 2026 00:10 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 13, 2026 00:10 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 13, 2026 00:10 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 13, 2026 00:10 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 13, 2026 00:10 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 13, 2026 00:10 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 13, 2026 00:10 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 13, 2026 00:10 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 13, 2026 00:10 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.