CA/Root CA Lifecycles

Section 7.4 of the Mozilla Root Store Policy (Root CA Lifecycles) notes:

• For a root CA certificate trusted for server authentication, Mozilla will remove the websites trust bit when the CA key material is more than 15 years old.
• For a root CA certificate trusted for secure email, Mozilla will set the "Distrust for S/MIME After Date" for the CA certificate to 18 years from the CA key material generation date.

Transition Schedule

For transition purposes, root CA certificates in the Mozilla root store will be distrusted according to the following schedule:

Key Material Created	Removal of Websites Trust Bit	Distrust for S/MIME After Date
Before 2006	April 15, 2025	April 15, 2028
2006-2007	April 15, 2026	April 15, 2029
2008-2009	April 15, 2027	April 15, 2030
2010-2011	April 15, 2028	April 15, 2031
2012- April 14, 2014	April 15, 2029	April 15, 2032
April 15, 2014 - present	15 years from creation	18 years from creation

This schedule is subject to change if underlying algorithms become more susceptible to cryptanalytic attack or if other circumstances arise that make this schedule obsolete.

CA operators are strongly urged to apply to Mozilla for inclusion of their next generation root certificate at least 2 years before the distrust date of the CA certificate they wish to replace.

2025 Webtrust Bit Removals

In accordance with the schedule above, and Bug #1937338 https://bugzilla.mozilla.org/show_bug.cgi?id=1937338, Mozilla will remove the websites trust bit for these eight (8) CAs on April 15, 2025:

CA Name	SHA 256 Hash
Baltimore CyberTrust Root (expires 5/12/2025)	16AF57A9F676B0AB126095AA5EBADEF22AB31119D644AC95CD4B93DBF3F26AEB
Entrust.net Certification Authority (2048)	6DC47172E01CBCB0BF62580D895FE2B8AC9AD4F873801E0C10B9C837D21EB177
AAA Certificate Services	D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4
Go Daddy Class 2 CA	C3846BF24B9E93CA64274C0EC67C1ECC5E024FFCACD2D74019350E81FE546AE4
Starfield Class 2 CA	1465FA205397B876FAA6F0A9958E5590E40FCC7FAA4FB7C2C8677521FB5FB658
XRamp Global Certification Authority	CECDDC905099D8DADFC5B1D209B737CBE2C18CFB2C10C0FF0BCF0D3286FC1AA2
Chunghwa Telecom Co., Ltd. - ePKI Root Certification Authority	C0A6F4DC63A24BFDCF54EF2A6A082A0A72DE35803E2FF5FF527AE5D87206DFD5
GlobalSign Root CA	EBD41040E4BB3EC742C9E381D31EF2A41A48B6685C96E7CEF3C1DF6CD4331C99

Background

Old Roots CAs and Hierarchies do not meet Current Requirements

Mozilla's Root Store Policy and the CA/Browser Forum Baseline Requirements (CABF BRs) are constantly evolving in order to improve security on the web. As new requirements are introduced, existing CA hierarchies are grandfathered in. Over time, these CA hierarchies need to be replaced so that they become fully compliant with current policies. Having a policy about root CA lifecycles will ensure that CA hierarchies get updated and become fully compliant.
Examples of how requirements and practices have changed over time include, but are not limited to, the following:

• Mozilla's first root store policy was published in 2004.
• The CA/Browser Forum EV Guidelines were adopted in October 2006, and for root CA keys to be trusted for EV treatment in browsers they had to be created in an auditor-witnessed key generation ceremony.
• In July 2012 the CA/Browser Forum Baseline Requirements became effective and required that for all publicly-trusted TLS CA hierarchies, the root CA keys had to be created in an auditor-witnessed key generation ceremony.
• Mozilla's root store policy required that as of January 2013 CA hierarchies be audited against the CA/Browser Forum Baseline Requirements.
• In June 2017 Mozilla's root store policy began requiring that CAs have cradle-to-grave continuous key protection and period-of-time audits without gaps.
• Intermediate CA certificates created since January 1, 2019, must have an EKU extension and cannot have both serverAuth and emailProtection EKUs in the same CA certificate.

Cryptographic Agility

Cryptographic agility is the ability to replace cryptographic primitives, algorithms, and protocols efficiently at reasonable cost with limited impact on operations. Mozilla is committed to agile management of our root store and the timely rotation of root certificates. Without this, some root CA certificates in Mozilla's root store could otherwise still be in use after 25 years. As computer processing speed increases and technology changes, we expect that cryptographic weaknesses will be discovered, such that it will be necessary to replace aging CA hierarchies. Or there will be advances in technology supporting cryptanalysis, and it will be necessary to replace cryptographic algorithms.

Why 15 years for TLS and 18 years for S/MIME?

It typically takes 2 to 3 years for a root certificate to get included into the major root stores. Time is also needed to complete the transition from an older hierarchy to the newer hierarchy before a CA can be distrusted for TLS. Therefore, a 15-year term allows for approximately 10 years of root CA use within the Mozilla root store.

Root certificates can have the email (S/MIME) trust bit enabled for longer than the server (websites) trust bit, because S/MIME certificates have a longer lifetime (3 years) than TLS server certificates (1 year). Additionally, we will use the "Distrust for S/MIME After Date" rather than immediately turning off the email trust bit, because S/MIME certificates have a different usage scenario and risk profile (than TLS server certificates).