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.

2026 Websites Trust Bit Removals

In accordance with the schedule above, Mozilla will remove the websites trust bit for following Root CAs on April 15, 2026:

CA Name	SHA 256 Hash
certSIGN ROOT CA	EAA962C4FA4A6BAFEBE415196D351CCD888D4F53F3FA8AE6D7C466A94E6042BB
SwissSign Gold CA - G2	62DD0BE9B9F50A163EA0F8E75C053B1ECA57EA55C8688F647C6881F2C8357B95
Secure Global CA	4200F5043AC8590EBB527D209ED1503029FBCBD41CA1B506EC27F15ADE7DAC69
SecureTrust CA	F1C1B50AE5A20DD8030EC9F6BC24823DD367B5255759B4E71B61FCE9F7375D73
DigiCert Assured ID Root CA	3E9099B5015E8F486C00BCEA9D111EE721FABA355A89BCF1DF69561E3DC6325C
DigiCert Global Root CA	4348A0E9444C78CB265E058D5E8944B4D84F9662BD26DB257F8934A443C70161
DigiCert High Assurance EV Root CA	7431E5F4C3C1CE4690774F0B61E05440883BA9A01ED00BA6ABD7806ED3B118CF
QuoVadis Root CA 2	85A0DD7DD720ADB7FF05F83D542B209DC7FF4528F7D677B18389FEA5E5C49E86
QuoVadis Root CA 3	18F1FC7F205DF8ADDDEB7FE007DD57E3AF375A9C4D8D73546BF4F1FED1E18D35
Entrust Root Certification Authority	73C176434F1BC6D5ADF45B0E76E727287C8DE57616C1E6E6141A2B2CBC7D8E4C
COMODO Certification Authority	0C2CD63DF7806FA399EDE809116B575BF87989F06518F9808C860503178BAF66
Certigna	E3B6A2DB2ED7CE48842F7AC53241C7B71D54144BFB40C11F3F1D0B42F5EEA12D
TeliaSonera Root CA v1	DD6936FE21F8F077C123A1A521C12224F72255B73E03A7260693E8A24B0FA389
Izenpe.com	2530CC8E98321502BAD96F9B1FBA1B099E2D299E0F4548BB914F363BC0D4531F

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).