惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
T
Tailwind CSS Blog
Google DeepMind News
Google DeepMind News
D
DataBreaches.Net
P
Proofpoint News Feed
Simon Willison's Weblog
Simon Willison's Weblog
Microsoft Azure Blog
Microsoft Azure Blog
MongoDB | Blog
MongoDB | Blog
腾讯CDC
月光博客
月光博客
A
Arctic Wolf
T
Threatpost
Jina AI
Jina AI
博客园 - 聂微东
美团技术团队
V
V2EX
云风的 BLOG
云风的 BLOG
宝玉的分享
宝玉的分享
Recent Commits to openclaw:main
Recent Commits to openclaw:main
M
MIT News - Artificial intelligence
S
Secure Thoughts
Martin Fowler
Martin Fowler
Webroot Blog
Webroot Blog
V
Vulnerabilities – Threatpost
爱范儿
爱范儿
人人都是产品经理
人人都是产品经理
Help Net Security
Help Net Security
Google Online Security Blog
Google Online Security Blog
博客园 - Franky
The Last Watchdog
The Last Watchdog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
阮一峰的网络日志
阮一峰的网络日志
博客园 - 【当耐特】
S
Schneier on Security
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Know Your Adversary
Know Your Adversary
Latest news
Latest news
有赞技术团队
有赞技术团队
AWS News Blog
AWS News Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Y
Y Combinator Blog
G
Google Developers Blog
NISL@THU
NISL@THU
H
Heimdal Security Blog
L
LangChain Blog
T
Troy Hunt's Blog
I
InfoQ
U
Unit 42
C
Check Point Blog
Engineering at Meta
Engineering at Meta

Let's Encrypt

The difficulty of making sure your website is broken Simplifying Certificate Renewals for Millions of Domains with ACME Renewal Information (ARI) Six-Day and IP Address Certificates Available in Certbot Shorter Certificate Lifetimes and Rate Limits DNS-PERSIST-01: A New Model for DNS-based Challenge Validation On the Importance of "Hello" and "Thanks" 6-day and IP Address Certificates are Generally Available 10 Years of Let's Encrypt Certificates Decreasing Certificate Lifetimes to 45 Days New "Generation Y" Hierarchy of Root and Intermediate Certificates Ten Years of Community Support ACME Renewal Information (ARI) Published as RFC 9773 Native ACME Support Comes to NGINX End of Life Plan for RFC 6962 Certificate Transparency Logs OCSP Service Has Reached End of Life We've Issued Our First IP Address Certificate Expiration Notification Service Has Ended Reflections on a Year of Sunlight How We Reduced the Impact of Zombie Clients Sustaining a More Secure Internet: The Power of Recurring Donations Ending TLS Client Authentication Certificate Support in 2026 How Pebble Supports ACME Client Developers Ten Years of Let's Encrypt: Announcing support from Jeff Atwood We Issued Our First Six Day Cert Encryption for Everybody Scaling Our Rate Limits to Prepare for a Billion Active Certificates Ending Support for Expiration Notification Emails Announcing Six Day and IP Address Certificate Options in 2025 Announcing Certificate Profile Selection Ending OCSP Support in 2025 Intent to End OCSP Service More Memory Safety for Let’s Encrypt: Deploying ntpd-rs Let’s Encrypt Continues Partnership with Princeton to Bolster Internet Security Takeaways from Tailscale’s Adoption of ARI An Engineer’s Guide to Integrating ARI into Existing ACME Clients New Intermediate Certificates Introducing Sunlight, a CT implementation built for scalability, ease of operation, and reduced cost A Year-End Letter from our Vice President Our role in supporting the nonprofit ecosystem Increase your security governance with CAA Shortening the Let's Encrypt Chain of Trust ISRG’s 10th Anniversary Improving Resiliency and Reliability for Let’s Encrypt with ARI Thank you to our 2023 renewing sponsors A Look into the Engineering Culture at ISRG Let’s Encrypt improves how we manage OCSP responses A New Life for Certificate Revocation Lists Nurturing Continued Growth of Our Oak CT Log TLS Beyond the Web: How MongoDB Uses Let’s Encrypt for Database-to-Application Security Let’s Encrypt Receives the Levchin Prize for Real-World Cryptography New Major Funding from the Ford Foundation TLS Simply and Automatically for Europe’s Largest Cloud Customers Making the Web safer and more secure for everyone Resources for Certificate Chaining Help Speed at scale: Let’s Encrypt serving Shopify’s 4.5 million domains Preparing to Issue 200 Million Certificates in 24 Hours The Next Gen Database Servers Powering Let's Encrypt A Year-End Letter from the Executive Director of Let's Encrypt and ISRG Extending Android Device Compatibility for Let's Encrypt Certificates Standing on Our Own Two Feet [Updated] Let's Encrypt's New Root and Intermediate Certificates Let's Encrypt Has Issued a Billion Certificates Multi-Perspective Validation Improves Domain Validation Security How Let's Encrypt Runs CT Logs Onboarding Your Customers with Let's Encrypt and ACME Introducing Oak, a Free and Open Certificate Transparency Log Transitioning to ISRG's Root The ACME Protocol is an IETF Standard Facebook Expands Support for Let’s Encrypt Looking Forward to 2019 Let's Encrypt Root Trusted By All Major Root Programs Engineering deep dive: Encoding of SCTs in certificates Looking Forward to 2018 ACME Support in Apache HTTP Server Project Wildcard Certificates Coming January 2018 Milestone: 100 Million Certificates Issued ACME v2 API Endpoint Coming January 2018 OVH Renews Platinum Sponsorship of Let's Encrypt Let’s Encrypt 2016 In Review Launching Our Crowdfunding Campaign Our First Grant: The Ford Foundation Squarespace OCSP Stapling Implementation Introducing Internationalized Domain Name (IDN) Support ISRG Legal Transparency Report, January 2016 - June 2016 What It Costs to Run Let's Encrypt Let's Encrypt Root to be Trusted by Mozilla Full Support for IPv6 Defending Our Brand [Updated] Progress Towards 100% HTTPS, June 2016 Leaving Beta, New Sponsors ISRG Legal Transparency Report, July 2015 - December 2015 New Name, New Home for the Let's Encrypt Client Software Our Millionth Certificate OVH Sponsors Let's Encrypt Entering Public Beta Facebook Sponsors Let's Encrypt Public Beta: December 3, 2015 Why ninety-day lifetimes for certificates? The CA's Role in Fighting Phishing and Malware Let's Encrypt is Trusted
Deploying Let's Encrypt's New Issuance Chains
2024-04-12 · via Let's Encrypt

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.

Let’s Encrypt 2024 Ceremony

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.

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 ECDSA chain included two intermediates: both E1 and the cross-signed ISRG Root X2 (i.e. ISRG Root X1 → ISRG Root X2 → E1 → End-Entity Certificate). After the change, it will contain only a single intermediate: the version of one of our new ECDSA intermediates cross-signed by ISRG Root X1 (i.e. ISRG Root X1 → E5 → End-Entity Certificate). This ensures that all of our intermediates, both RSA and ECDSA, are signed directly by our most widely-trusted ISRG Root X1.

We expect this change to benefit most users with smaller TLS handshakes. If compatibility problems with ECDSA intermediates arise, we recommend Let’s Encrypt users switch to RSA certificates. Android 7.0 is known to have a bug preventing it from working with most Elliptic Curve (EC) certificates, including our ECDSA intermediates; however, that version of Android doesn’t trust our ISRG Root X1 and thus is already incompatible.

We do not recommend pinning or otherwise hard-coding intermediates or roots. Pinning intermediates is especially not advisable as they change often. If you do pin intermediates, make sure you have the complete set of new intermediates (available here).

Questions?

We’re grateful for the millions of subscribers who have trusted us to carry out best practices to make the web more secure and privacy-respecting, and rotating intermediates more frequently is one of them. We’d also like to thank our great community and the funders whose support makes this work possible. If you have any questions about this transition or any of the other work we do, please ask on our community forum.

We depend on contributions from our supporters in order to provide our services. If your company or organization can help our work by becoming a sponsor of Let’s Encrypt please email us at sponsor@letsencrypt.org. We ask that you make an individual contribution if it is within your means.