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

推荐订阅源

WordPress大学
WordPress大学
H
Help Net Security
Jina AI
Jina AI
V
V2EX
G
Google Developers Blog
B
Blog
GbyAI
GbyAI
U
Unit 42
爱范儿
爱范儿
腾讯CDC
Engineering at Meta
Engineering at Meta
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 三生石上(FineUI控件)
宝玉的分享
宝玉的分享
小众软件
小众软件
D
DataBreaches.Net
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - Franky
博客园 - 聂微东
The Cloudflare Blog
I
InfoQ
Microsoft Azure Blog
Microsoft Azure Blog
Hugging Face - Blog
Hugging Face - Blog
大猫的无限游戏
大猫的无限游戏

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 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
New "Generation Y" Hierarchy of Root and Intermediate Cer...
2025-11-24 · via Let's Encrypt

By Aaron Gable ·

In a ceremony held in September, Let’s Encrypt generated two new Root Certification Authorities (CAs) and six new Intermediate CAs, which we’re collectively calling the “Generation Y” hierarchy. Now we’re moving to begin issuing certificates from this new hierarchy, and to submit it to various root programs for inclusion in their trust stores.

Diagram of the new Generation Y Root and Intermediate CAs

The two new roots look very similar to our existing roots. The new ISRG Root YR has an RSA 4096 key and is valid for twenty years, just like ISRG Root X1. Similarly, the new ISRG Root YE has an ECDSA P-384 key, just like ISRG Root X2. We’ve made a few adjustments (for example, replacing “Internet Security Research Group” with “ISRG” to save a few bytes), but nothing major. Each of these new roots is intended to eventually replace its corresponding predecessor, and to that end we have cross-signed the new roots from the old ones.

The six new intermediates consist of three intermediates each issued from each of the two new roots. ISRG Root YE has issued the YE1, YE2, and YE3 intermediates, while ISRG Root YR has issued the YR1, YR2, and YR3 intermediates. These have two key differences from our current crop of issuing intermediates. First, their names: we’re now numbering intermediates under each root sequentially, rather than using the same numbering sequence across all intermediates. This makes it slightly easier to keep track of which intermediates are currently in use, and prepares for a possible post-quantum future where we have additional key types.

Second and more importantly: these intermediates do not contain the “TLS Web Client Authentication” Extended Key Usage. This means that these intermediates cannot issue end-entity certificates containing that EKU. As we’ve already announced, we will be phasing out issuance of tlsClientAuth certificates in 2026 due to a root program requirement. Until that time, we will only be using the new hierarchy to issue certificates under the “tlsserver” and “shortlived” profiles, which already omit that EKU. After the tlsClientAuth deprecation is complete, we will shift to using the new intermediates for all issuance.

If you’re requesting the tlsserver or shortlived profile, you can expect to see issuance from (the Staging equivalent of) the new hierarchy as of today. We expect to make the same change in our Production environment next month. As before, each issuance will choose which intermediate to use at random, to discourage intermediate key pinning.

We’ll be submitting the new roots for inclusion in the Apple, Chrome, Microsoft, Mozilla, and other root programs shortly thereafter. We look forward to updating you again when the new hierarchy is officially included in those trust stores!