Let's Encrypt lists ISRG Root X1 as trusted until 2030-06-04, but says that date is approximate because root programs decide how long to trust a root. New roots named YE and YR exist and are not yet in trust stores. If your software ships its own trust store, plan for updates now.
What the issuer publishes
The Let's Encrypt chains page, updated July 2026, describes the roots:
| Root | Key type | Listed trusted until |
|---|---|---|
| ISRG Root X1 | RSA 4096 | 2030-06-04 |
| ISRG Root X2 | ECDSA P-384 | 2035-09-04 |
| Root YE | ECDSA P-384 | Not applicable yet |
| Root YR | RSA 4096 | Not applicable yet |
Roots YE and YR were generated in September 2025. The page says they are not yet in root program trust stores but will be submitted for inclusion soon. The default chains for current intermediates run through them and up to the established roots, via cross signing, so clients that know just the older roots keep working.
Why a root's end date is soft
The page explains that root certificates do not expire the way other certificates do. A root's self signed certificate has a notAfter date, but root programs and trust stores may keep trusting it beyond that date or end trust before it. Treat the listed date as a planning hint, not a promise.
Who should worry
- Apps that bundle their own CA list. Embedded devices, desktop clients, containers with a frozen bundle, and anything that sets a custom CA file.
- Pinned apps. If you pinned a root or intermediate, see why that is fragile.
- Long lived installations that cannot take updates, such as devices in the field.
- Teams that copy a CA bundle once and forget it.
Ordinary web apps using the operating system or language default store, with automatic updates, mostly need nothing beyond keeping platforms patched.
Action list
- Inventory every place a CA bundle is stored or shipped. See trusting CAs in each runtime.
- Make sure trust stores update through your normal patching, and add that to the release checklist.
- For devices, confirm there is a safe way to update roots remotely.
- Test against the issuer's published test sites for valid, revoked and expired certificates.
- Keep serving the full chain. See incomplete chains.
- Recheck the chains page each quarter, since the list changes.
Where Safeguard fits
Safeguard scans dependencies and SBOMs for known vulnerabilities, including those in the TLS and crypto libraries your projects pull in, and you can try it with the free scan at gold.safeguard.sh/scan.
Quick check
Will everything break on 4 June 2030?
Not necessarily. The date is approximate, and trust store operators decide. Treat it as a planning date.
Do I need to do anything if I use the system trust store?
Mostly keep operating systems and runtimes updated. Apps with their own bundles need a plan.
Sources
Last reviewed: 19 October 2026.
