CA/Root CA Lifecycles< CA
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.
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
|April 15, 2025
|April 15, 2028
|April 15, 2026
|April 15, 2029
|April 15, 2027
|April 15, 2030
|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.
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 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).