Postponement of Removal of Websites Trust Bit for ePKI Root CA

[Ben Wilson]

Per - https://bugzilla.mozilla.org/show_bug.cgi?id=1891438#c15:

"In the interest of transparency, Mozilla received a formal request from Taiwan’s Ministry of Digital Affairs (MODA), dated March 15, 2025, requesting that we delay the removal of the “websites” trust bit for Chunghwa Telecom’s ePKI Root CA, which is currently scheduled to occur on or about April 15, 2025, in accordance with Mozilla’s Root CA Lifecycles Transition Schedule.

MODA explained that the requested delay is intended to support the ongoing transition of government websites away from certificates issued by CHT’s GTLSCA-G1 subordinate CA. As we understand it, MODA is already implementing a short-term migration plan involving the dual issuance of approximately 12,000 new certificates for government websites—one from Chunghwa Telecom and one from Taiwan CA (TWCA)—to ensure continued availability of government services and minimize user disruption.

While we have not yet finalized a decision, we are currently contemplating:

• Postponing the removal of the “websites” trust bit;
• Implementing a distrust-after date; or
• Taking other actions consistent with Mozilla Root Store Policy and ecosystem risk management.

We note that:

• The ePKI Root CA uses a 4096-bit RSA key, which provides stronger security than other similarly aged root certificates.
• Any extension under consideration would be strictly time-bounded (e.g., not to exceed August 1, 2025), reflecting a short-term accommodation, not a change in long-term policy direction.
• Mozilla would retain the right to remove or revoke trust at any time, based on new information or evolving risk factors.

We welcome feedback on any of these approaches."

Thanks,

Ben

[Arabella Barks]

Is it more reasonable to use the condition, notBefore of the leaf cert greater than April 15th, 2025 as a condition for the untrusted anchor point? At the same time, it can also achieve the purpose of phasing out CAs that are too old.

Correction is welcome if any of my idea is wrong.

[Ben Laurie]

I assumed that is what they meant by "distrust-after date" - I might be wrong. In any case, I think it's a good idea.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/05d31347-d1c0-474d-9c2f-22778116c1c6n%40mozilla.org.

[Jeffrey Walton]

On Tue, Apr 1, 2025 at 11:03 AM 'Ben Wilson' via
dev-secur...@mozilla.org <dev-secur...@mozilla.org>
wrote:

Please consider avoiding the DistrustAfter strategy. It causes
problems for tools which use Google, Mozilla (and friends) curated
lists of trusted CAs. The tools include utilities like cURL and Wget.
See, for example, <https://github.com/curl/curl/issues/15547>.

Jeff

[Ben Wilson]

Thanks for your feedback. Currently, our proposed strategy for handling this particular issue will be to postpone processing the websites trust bit removal from the Chunghwa Telecom ePKI Root CA by two or three months (until approximately Firefox Release 141). In other words, we do not anticipate using the distrust-after mechanism in the present case.

Thanks again, 

Ben

[Arabella Barks]

Ben,

I still suggest adopting the distrust-after.
Among the root intermediates that Mozilla plans to remove trust, there is the "AAA Certificates Servies" of Sectigo CA, which is being widely issued and used by a subordinate CA of Cloudflare, namely "Cloudflare TLS Issuing ECC CA 1" (https://crt.sh/?caid=282054, and issued by "SSL.com TLS Transit ECC CA R2"). However, SSL.com TLS Transit ECC CA R2 is just a subordinate CA and not a Root.

If Mozilla directly removes the "AAA Certificates Servies" and others, more than 12,435,053 websites issued by "Cloudflare TLS Issuing ECC CA 1" will be affected, It has bad impact on the business of CloudFlare's customers.
The above is what I have found out through about few minutes of research, based on the sites count and I think it will have a gravity impact.

I request the community to conduct an assessment to reduce this impact.

[Arabella Barks]

Sorry, I forgot to post one case https://www.relialabtest.com it is the hierarchy I mentioned.

[Ben Wilson]

Hi Arabella,

Thanks for your comments on this topic. Unfortunately, the decision to remove the “websites” trust bit for several older root certificates—including the AAA Certificate Services Root—follows a long-standing transition plan that is publicly documented here: https://wiki.mozilla.org/CA/Root_CA_Lifecycles. We understand that changes like this can raise concerns. However, this transition has been in motion for quite some time. We appreciate everyone’s understanding as we continue to ensure the trustworthiness and security of the web.

Ben

[Ryan Dickson]

Hi Arabella,

The example provided can validate to multiple anchors. 

For example, an alternate path to an SSL.com root is provided below.

Anchor: SSL.com TLS ECC Root CA 2022

 ---> SSL.com TLS Transit ECC CA R2

     ---> Cloudflare TLS Issuing ECC CA 1

          ---> www.relialabtest.com

Hope this helps!

- Ryan

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c0794245-c1c8-417c-a40e-a7154a4720d2n%40mozilla.org.

[Martijn Katerbarg]

All,

> If Mozilla directly removes the "AAA Certificates Servies" and others, more than 12,435,053 websites issued by "Cloudflare TLS Issuing ECC CA 1" will be affected, It has bad impact on the business of CloudFlare's customers. 

> The above is what I have found out through about few minutes of research, based on the sites count and I think it will have a gravity impact. 

> I request the community to conduct an assessment to reduce this impact. 

As already pointed out by Ryan, these certificates can all be validated through multiple chains.  

With the experience we’ve gained from preparing for this root certificate removal, we do want to add that we believe future scheduled root certificate deprecations would benefit from utilizing the mechanisms for distrust based on notBefore (Mozilla) and SCTNotAfter (Chrome), rather than a hard deadline for trust bit removal. This probably warrants its own discussion thread though, potentially on the CCADB Public list. 

> Please consider avoiding the DistrustAfter strategy. It causes problems for tools which use Google, Mozilla (and friends) curated lists of trusted CAs. The tools include utilities like cURL and Wget. 

We don’t agree with this. The DistrustAfter mechanism is one very suitable for a graceful removal of trust, be it for scheduled deprecations, or other forms of trust removal.  

The tools mentioned, or more broadly, Linux distributions that build their ca-certificates packages based on the data available in Mozilla/NSS, have hopefully chosen to do so for a reason: They believe the open source root store that Mozilla provides fits their needs and provides the transparency the open source community is usually looking for.  

If the Mozilla root store believes the DistrustAfter mechanism is viable and is a better option (which we agree with in general), then the parties relying on the root store need to adjust to follow that guidance, or re-assess their needs. They should at no point be holding back innovation and improvements of the Mozilla root store / NSS. 

We’d like to remind everyone of this Mozilla blog post, which mentions this wiki page that discusses additional factors (including DistrustAfter) that application developers need to be aware of if they are using Mozilla’s root store.

Regards,

Martijn Katerbarg
Sectigo

Op woensdag 9 april 2025 om 19:08:43 UTC+2 schreef Ryan Dickson:

[Andrew Ayer]

On Wed, 9 Apr 2025 11:54:22 -0400
Jeffrey Walton <nolo...@gmail.com> wrote:

> Please consider avoiding the DistrustAfter strategy. It causes
> problems for tools which use Google, Mozilla (and friends) curated
> lists of trusted CAs. The tools include utilities like cURL and Wget.
> See, for example, <https://github.com/curl/curl/issues/15547>.

That bug has been fixed, as have the bugs in python-certifi and Go.
Are you aware of more bugs? If so, I'd like to try to get them fixed
too.

Regards,
Andrew

[Dimitris Zacharopoulos]

Martijn,

Can you please share more details about the risks you see between the following options, for a Root CA with a hierarchy that no longer issues new end-entity certificates (OCSP responder certificates excluded) and all of its subscriber certificates have either been revoked or expired?

1. Utilizing distrust notAfter/notBefore modern browser methods
2. Removal of "trust bits"
3. Removal of the Root CA entirely, especially if there are no "trust bits" enabled.

I'm very interested to hear the ecosystem risks for each of these choices. It feels that the order is correct in terms of risks but I'm more interested to hear what you and others feel about the 3rd option.

Best regards,

Dimitris.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/136da9cf-e967-401c-9cc9-d2031655d605n%40mozilla.org.

[Arabella Barks]

Dear Ryan,

Thank you for bringing up the topic of the multiple anchors.

I'm wondering if Chrome and Firefox have implemented the feature to automatically look up the trust anchor. From my tests (specifically, removing AAA Certificate Services locally), it seems that Chrome can perform this look-up, but Firefox cannot. However, I'm not entirely certain.

This case is far more complex than a typical scenario involving cross-signing between an Old Root and a Modern Root.

AAA Certificate Services doesn't have a cross-signing certificate with SSL.com TLS ECC Root CA 2022. If there were a cross-signing relationship, things would be much simpler. I'm quite sure it wouldn't impact trust, and there would be no need for further discussion.

But the subscriber hierarchy of Cloudflare TLS Issuing ECC CA 1's moden root SSL.com TLS ECC Root CA 2022, is not cross-signed with AAA Certificate Services. So, if AAA Certificate Services is removed, the ability to automatically look up the trust anchor hierarchy becomes crucial for Cloudflare and its customers. In few days to replace 12,435,053 sites certificate configuration, It should be a disaster.

Thank you.

Ara 

[Ryan Dickson]

Hi Arabella,

I'm wondering if Chrome and Firefox have implemented the feature to automatically look up the trust anchor. From my tests (specifically, removing AAA Certificate Services locally), it seems that Chrome can perform this look-up, but Firefox cannot. However, I'm not entirely certain.

Generally speaking, Chrome’s certificate path discovery and validation behavior follows RFC 4158 and RFC 5280.

At a high-level, Chrome is capable of discovering paths using two approaches, either separately, or in combination:

1. Certificates provided by the server’s configuration during the TLS handshake.

2. Paths built from “chasing” certificates disclosed in the Authority Information Access (AIA) extension.

If Chrome can successfully build a valid path from a leaf to a root included in the Chrome Root Store using the certificates provided by the server, great - AIA does not need to be considered. While chasing AIA is considered less preferred due to performance concerns (e.g., bandwidth usage and time of discovery), it is a useful fallback in the event of server misconfigurations and cases like the example being discussed in this thread.

As a general note, I wanted to share some context for Chrome’s standard approach related to participating in MDSP. Out of respect for the Mozilla Root Program's distinct policy governance and decision-making processes, over the past few years, the Chrome Root Program team has generally focused our participation on broader community forums like pub...@ccadb.org. We feel this helps maintain clearer boundaries between program-specific discussions and related decisions made to improve security for those specific user communities. However, given the direct implications for website compatibility and user experience related to the AAA root removal – which also affects the Chrome Root Store due to our policy – we thought it was important to contribute to this specific conversation.

For added background on the Chrome Root Program’s approach, for all “term-limit” removals taking place from the Chrome Root Store we:

• leveraged our internal PKI monitoring tooling to identify and evaluate the impact of our planned term-limit removals.

• contacted affected CA Owners about 3 months ago, to remind them of the upcoming removal. In cases where we discovered time-valid server authentication certificates only capable of chaining to a “to-be-removed” root and whose validity extended past the planned removal date (April 15, 2025), we (1) confirmed the CA Owner’s understanding of the planned removal and (2) asked about their plans to transition affected subscribers to avoid potential breakage. 

Most responses from CA Owners specifically indicated subscriber awareness of the upcoming changes and a signal that (a) subscribers have already replaced affected certificates, (b) subscribers had plans in place to replace the affected certificates before the removal, and/or (c) subscribers accepted the risk of continuing to rely on these certificates, where in some cases, use of the affected certificates would not be impacted. 

Thanks, 

Ryan

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/1057e65f-8768-4431-9889-a4eac1cf1747n%40mozilla.org.

[Martijn Katerbarg]

Hi Dimitris,

 

I’m forking this to a new thread to separate from the delayed trust bit removal thread.

 

>Can you please share more details about the risks you see between the following options, for a Root CA with a hierarchy that no longer issues new end-entity certificates (OCSP responder certificates excluded) and all of its subscriber certificates have either been revoked or expired?

 

I want to clarify here that just because the trust bits are being removed from Mozilla/NSS and Chrome it doesn’t mean there won’t be some unexpired leaf certificates, or even new certificate issuance from the hierarchy for a small number of subscriber edge cases.

 

For the sake of this discussion, I’ll leave in the middle whether these edge cases are good or bad. We certainly see both. I also believe the WebPKI is currently in a more active transformational state, one where proper customer education about using the right PKI at the right location is more important than ever.

 

1.            Utilizing distrust notAfter/notBefore modern browser methods

2.            Removal of "trust bits"

3.            Removal of the Root CA entirely, especially if there are no "trust bits" enabled.

 

I want to say here that we believe all three mechanisms should be utilized, in the correct order (frankly, the one you specified).

 

At this moment, number 2 and 3 are utilized by Mozilla for the scheduled deprecations due to CA key lifetimes. The main reason for this is the different removal dates for SMIME and TLS. As an example for a multipurpose root:

-              2025-04-15: TLS trust bit removal

-              2028-04-15: S/MIME trust bit removal / complete Root CA removal.

 

When looking at single purpose hierarchies, the direct Root CA removal could be the first step.

 

We would like to advocate adding the first option at the beginning of the process, changing the example to:

-              2024-04-15: DistrustAfter set for TLS and S/MIME

-              2025-04-15: TLS trust bit removal

-              2028-05-15: Complete Root CA removal

 

We believe this approach would help significantly to make root deprecations smoother for CAs and Subscribers alike.

What this change would essentially force is setting a single date for both TLS and S/MIME, after which any newly issued certificate won’t be trusted by Mozilla.

The issue we see currently is that certificates issued at the same time have different trust removal dates. As an example, with our AAA Certificate Services Root CA:

 

-              A TLS certificate issued on 2025-01-15 for 200 days, after 3 months will stop being trusted.

-              A TLS certificate issued on 2025-02-15 for 30 days, would be trusted for its entire lifetime.

-              An S/MIME certificate issued on 2026-04-15 for 3 years, would have its trust removed after 2 years.

-              An S/MIME certificate issued on 2027-04-15 for 1 year, would be trusted for its entire lifetime.

 

We believe (and have noticed in practice) that this easily leads to confusion, whereas having a single “DistrustAfter” date based on the notBefore date for all certificate types allows for more clarity.

 

Additionally, using “DistrustAfter” also has the benefit of showing a non-trusted state immediately after installation of a certificate, rather than (for the Subscriber and Relying Parties perspective) at a random moment.

 

While a CA could obviously choose to halt issuance early on a hierarchy to ensure all leaf certificates expire before the root removal date, that would no longer allow for the sorts of subscriber edge cases that I touched on above.

 

Regards,

Martijn

 

--
You received this message because you are subscribed to a topic in the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/uYAm_c_pfos/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c7ddab01-7145-4b87-a2c0-5532eca6675b%40it.auth.gr.

[Ben Wilson]

Hi Martijn,

Just one clarification regarding the current state of the transition plan: it currently specifies distrustAfter dates for S/MIME roots.

See https://wiki.mozilla.org/CA/Root_CA_Lifecycles

We're open to input on whether any similar changes should be considered for TLS CAs.
Also, please keep in mind that, going forward, root store programs might aim to align on a common removal framework to give CA operators better predictability around when their root certificates will no longer be trusted. However, we're not there yet.

Thanks,

Ben

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SA1PR17MB6503CA06DEF442B9389D4681E3B62%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Arabella Barks]

Dear Ben,

Does firefox respect certificate's AIA Extension(Authority Information Access) like Ryan and chrome did?
It is important for cloudflare customers to reduce their lose those who installed SSL.com's non-cross-signed certificates chaining to AAA Certificate Services.

Thank you.
Ara

[Dimitris Zacharopoulos]

Hi Martijn and thanks for the detailed response. See inline for some additional comments/questions.

On 11/4/2025 6:35 μ.μ., Martijn Katerbarg wrote:

Hi Dimitris,

 

I’m forking this to a new thread to separate from the delayed trust bit removal thread.

 

>Can you please share more details about the risks you see between the following options, for a Root CA with a hierarchy that no longer issues new end-entity certificates (OCSP responder certificates excluded) and all of its subscriber certificates have either been revoked or expired?

 

I want to clarify here that just because the trust bits are being removed from Mozilla/NSS and Chrome it doesn’t mean there won’t be some unexpired leaf certificates, or even new certificate issuance from the hierarchy for a small number of subscriber edge cases.

 

For the sake of this discussion, I’ll leave in the middle whether these edge cases are good or bad. We certainly see both. I also believe the WebPKI is currently in a more active transformational state, one where proper customer education about using the right PKI at the right location is more important than ever.

 

1.            Utilizing distrust notAfter/notBefore modern browser methods

2.            Removal of "trust bits"

3.            Removal of the Root CA entirely, especially if there are no "trust bits" enabled.

 

I want to say here that we believe all three mechanisms should be utilized, in the correct order (frankly, the one you specified).

+1

 

At this moment, number 2 and 3 are utilized by Mozilla for the scheduled deprecations due to CA key lifetimes. The main reason for this is the different removal dates for SMIME and TLS. As an example for a multipurpose root:

-              2025-04-15: TLS trust bit removal

-              2028-04-15: S/MIME trust bit removal / complete Root CA removal.

 

When looking at single purpose hierarchies, the direct Root CA removal could be the first step.

 

We would like to advocate adding the first option at the beginning of the process, changing the example to:

-              2024-04-15: DistrustAfter set for TLS and S/MIME

-              2025-04-15: TLS trust bit removal

-              2028-05-15: Complete Root CA removal

 

We believe this approach would help significantly to make root deprecations smoother for CAs and Subscribers alike.

What this change would essentially force is setting a single date for both TLS and S/MIME, after which any newly issued certificate won’t be trusted by Mozilla.

The issue we see currently is that certificates issued at the same time have different trust removal dates. As an example, with our AAA Certificate Services Root CA:

 

-              A TLS certificate issued on 2025-01-15 for 200 days, after 3 months will stop being trusted.

-              A TLS certificate issued on 2025-02-15 for 30 days, would be trusted for its entire lifetime.

-              An S/MIME certificate issued on 2026-04-15 for 3 years, would have its trust removed after 2 years.

-              An S/MIME certificate issued on 2027-04-15 for 1 year, would be trusted for its entire lifetime.

 

We believe (and have noticed in practice) that this easily leads to confusion, whereas having a single “DistrustAfter” date based on the notBefore date for all certificate types allows for more clarity.

 

Additionally, using “DistrustAfter” also has the benefit of showing a non-trusted state immediately after installation of a certificate, rather than (for the Subscriber and Relying Parties perspective) at a random moment.

 

While a CA could obviously choose to halt issuance early on a hierarchy to ensure all leaf certificates expire before the root removal date, that would no longer allow for the sorts of subscriber edge cases that I touched on above.

I assumed all CAs that introduced newer RootCAs in NSS, especially the single-purpose ones, and even more specifically the server TLS cases, would switch issuance to these new hierarchies including a cross-certificate chaining to the previous, more ubiquitous Root. Of course, this tactic increases the bytes in the TLS handshake (more data on the wire), but it's a necessity that comes with the rollover of the Root.

My question is, if the CA has switched issuance of S/MIME and server TLS to other single-purpose hierarchies, like Sectigo, HARICA and others have already done, are there other use cases that might be affected by the entire removal of the Root (option 3) that the ecosystem should be aware of and prevent from breaking?

The updated "ca-certificates" packages in Linux distributions was mentioned, but that would add the new Root the same time as it would remove the old Root, so it shouldn't cause any issues. Is that correct?

Do you, or anyone else, see any other issues that might be caused by the removal of a Root (assuming a new Root is included)?


Thanks,
Dimitris.

[Dimitris Zacharopoulos]

On 13/4/2025 4:18 μ.μ., Arabella Barks wrote:

Dear Ben,

Does firefox respect certificate's AIA Extension(Authority Information Access) like Ryan and chrome did?
It is important for cloudflare customers to reduce their lose those who installed SSL.com's non-cross-signed certificates chaining to AAA Certificate Services.

Dear Ara,

I don't think there is any trust issue, primarily because of the alternative paths. Older devices that do not update their Root Stores will continue to trust the old Root Certificate while newer devices will trust the new Root Certificate.

AIA chasing is a mechanism which is more targeted to help with missing intermediate CA Certificates from TLS server (mis-)configurations in the CA Certificate chains.


Thanks,
Dimitris.

[Arabella Barks]

Dear Dimitris,

The key issue is that the alternative path AIA doesn't function on Firefox. Please attempt to remove the AAA Certificate Services from your Firefox browser(to simulate what Ben and Mozilla's plan) and then refresh the page at https://www.relialabtest.com.

Firefox will alert this website as insecure.

Thanks,
Ara

[Andrew Ayer]

On Mon, 14 Apr 2025 16:10:47 -0700 (PDT)
Arabella Barks <arabel...@gmail.com> wrote:

> The key issue is that the alternative path AIA doesn't function on
> Firefox. Please attempt to remove the AAA Certificate Services from
> your Firefox browser(to simulate what Ben and Mozilla's plan) and
> then refresh the page at https://www.relialabtest.com.
> Firefox will alert this website as insecure.

I'm not able to reproduce this with either Firefox 137.0.1 or Firefox 128.9.0esr.

Although Firefox doesn't implement AIA, it does have Intermediate Preloading[1], which enables Firefox to build an alternative chain to another trust anchor.

Note it seems to take a brand new Firefox profile a few minutes to download the Intermediate Preloading data, during which time you do get a certificate error. Could that potentially explain the error you got?

Regards,
Andrew

[1] https://blog.mozilla.org/security/2020/11/13/preloading-intermediate-ca-certificates-into-firefox/

[Arabella Barks]

Hi Andrew,

We can't test by deleting "AAA Certificate Services" directly, we have to disable it. 

Because if we try delete, after refresh the testing target website, **Firefox will automaticlly restore  "AAA Certificate Services"** into its truststore.

I reproduced by following steps:

- Install firefox nightly, which my version is Firefox Nightly 139.0a1 (2025-04-16).

- Open firefox and get into its setting, search box input "certificate" and open "Certificate manager" in results.
- Click "Authorities" Tab.

- Edit trust for "Comodo AAA Certificate Services" under the group "Comodo CA Limited", Disable all trust items. 

- Refresh the target site, https://www.relialabtest.com, it should alert "Error code: SEC_ERROR_UNKNOWN_ISSUER".

If you have a better method to disable firefox auto upgrading truststore, please mention me.

Thank you

Ara

[Ben Wilson]

Greetings,

I tested it in Firefox, and the website provided me with a certificate issued by Cloudflare chaining up to an SSL.com root.

Ben