Distrust dates for GLOBALTRUST 2020 CA

3,849 views
Skip to first unread message

Ben Wilson

unread,
Jun 11, 2024, 10:59:41 AMJun 11
to dev-secur...@mozilla.org

All,


We appreciate the comments received from the community on m-d-s-p and in Bugzilla regarding several recent incidents involving e-commerce monitoring GmbH (ECM). A summary of the most recent Bugzilla incidents has been published on the Mozilla wiki, https://wiki.mozilla.org/CA/e-commerce-monitoring_Issues

Public discussion and our review have highlighted long-running and unresolved compliance issues with ECM, including but not limited to (1) a failure to recognize, understand, and adhere to the compliance obligations of a publicly trusted CA, (2) repeated failure to meet the requirements for timely updates in line with incident reporting requirements (i.e. https://www.ccadb.org/cas/incident-report#incident-reports and https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed), and (3) inadequate responses, root cause analyses, and mitigations.

Problems with ECM's operations and compliance began surfacing in February 2023, with the mis-issuance of certificates reported in Bug 1815534 and further detailed in Bug 1830536. This revealed a substantial misunderstanding of root program requirements around timely incident response and rectification, leading to a delayed revocation incident (Bug 1862004). The overall finalization of these incident reports took over a year, completing in February 2024, due to both failures to include necessary information and excessive delays in responses by ECM.

These issues have intensified in recent months, with a mis-issuance reported in Bug 1883711, which was then revoked with the incorrect reason code. Numerous further issues emerged in the incident response, including excessive delays in responses, failure to disclosure a similarly mis-issued certificate that was revoked but not mentioned in the subsequent incident report, failure to promptly self-report the initial incident when the CA became aware of it, and failure to identify suitable preventative steps to address the root cause. This incident remains unresolved as of this post, and it is unclear that sufficient preventative actions have been taken by ECM.  

In Bug 1888371 reported on March 28, 2024, ECM was discovered to be serving incorrectly signed CRLs, violating the CA/Browser Forum’s TLS Baseline Requirements. Although ECM attempted an initial fix which proved ineffective, ECM has now missed the target date they set for themselves for a solution (May 31, 2024), meaning that their revocation infrastructure for some of their certificates has been unavailable for over 70 days, and ECM has not given any update on their progress towards resolution for over 30 days.

ECM's general failure to respond in line with incident reporting requirements in a timely fashion is discussed further in Bug 1893546.

Mozilla’s expectations for all CA operators participating in its root store are clear: they must provide timely updates and effective resolutions to incidents, they must ensure that root cause analyses are thorough and promptly updated based on community feedback, and they must maintain adequate staffing and resources.

In light of ECM’s persistent issues, we will be setting  “Distrust After” dates for websites and email trust bits associated with ECM’s GLOBALTRUST 2020 root CA, effective June 30, 2024. TLS server authentication and S/MIME certificates issued before June 30, 2024, will be unaffected by this change, but certificates issued after June 30, 2024, will not be trusted.

We want to clarify that although a separate assessment of ECM’s continued inclusion in Mozilla’s Root Store was underway due to their acquisition by AUSTRIA CARD, this decision to remove ECM is unrelated to that ownership change and should not be considered a negative finding against AUSTRIA CARD. Should AUSTRIA CARD or a related entity seek inclusion in Mozilla’s Root Store in the future, that application will be considered on its merits. 

Sincerely yours,

Ben Wilson

Mozilla Root Program Manager

Ben Wilson

unread,
Jun 11, 2024, 11:39:39 AMJun 11
to David Adrian, dev-secur...@mozilla.org
Hi David,
We are currently not using CT, but we will keep a close eye on any reports of backdating based on discrepancies between SCTs and notBefore dates.
Our long-term plan is to enhance our validity checking with CT.
Thanks,
Ben

On Tue, Jun 11, 2024 at 9:02 AM David Adrian <dad...@chromium.org> wrote:
> In light of ECM’s persistent issues, we will be setting  “Distrust After” dates for websites and email trust bits associated with ECM’s GLOBALTRUST 2020 root CA, effective June 30, 2024.

Hi Ben,

Will this be enforced solely based on NotBefore? Or will SCT timestamps be taken into account. If solely based on NotBefore, are you monitoring for backdated certificates in any way?

Thanks,

-dadrian

--
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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZMYjgxYAi72yPwcN3X_QJNqDUydpTyAuvmtBR9X80f1w%40mail.gmail.com.

Mike Shaver

unread,
Jun 11, 2024, 11:43:33 AMJun 11
to Ben Wilson, David Adrian, dev-secur...@mozilla.org
On Tue, Jun 11, 2024 at 11:39 AM 'Ben Wilson' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:.
Our long-term plan is to enhance our validity checking with CT.

This is great to hear. Are there bugs that can be followed that cover the necessary work here (I assume in NSS and then in Firefox and Thunderbird)?

Mike

Ben Wilson

unread,
Jun 11, 2024, 11:49:16 AMJun 11
to dev-secur...@mozilla.org
Ben

On Tuesday, June 11, 2024 at 9:43:33 AM UTC-6 Mike Shaver wrote:
On Tue, Jun 11, 2024 at 11:39 AM 'Ben Wilson' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> wrote:.

Mike Shaver

unread,
Jun 11, 2024, 11:55:21 AMJun 11
to Ben Wilson, dev-secur...@mozilla.org
Sorry, I meant for the CT-based validity checking!

Mike

On Tue, Jun 11, 2024 at 11:49 AM 'Ben Wilson' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:
On Tuesday, June 11, 2024 at 9:43:33 AM UTC-6 Mike Shaver wrote:
On Tue, Jun 11, 2024 at 11:39 AM 'Ben Wilson' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:.
Our long-term plan is to enhance our validity checking with CT.

This is great to hear. Are there bugs that can be followed that cover the necessary work here (I assume in NSS and then in Firefox and Thunderbird)?

Mike

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

Ben Wilson

unread,
Jun 11, 2024, 12:00:30 PMJun 11
to Mike Shaver, dev-secur...@mozilla.org
For CT-checking - the meta bug is here - https://bugzilla.mozilla.org/show_bug.cgi?id=1281469
Ben

Andrew Ayer

unread,
Jun 11, 2024, 1:13:09 PMJun 11
to Ben Wilson, 'Ben Wilson' via dev-security-policy@mozilla.org
Hi Ben,

I strongly encourage Mozilla to not use a distrust after date with this
CA and to distrust it outright, as was done with other untrustworthy
CAs like Certinomis and Camerfirma. Since Firefox does not require CT,
I would assume that any malicious backdated certificates will not be
logged and therefore no one will detect them.

According to CT, ECM has only 43 unexpired TLS certificates in
circulation, for a total of 84 distinct DNS names (see attached). (In
contrast, Certinmois had 1,381 unexpired certificates at the time that
they were removed -
https://bugzilla.mozilla.org/show_bug.cgi?id=1552374) If we exclude
ECM's own domains, this drops down to just 36 distinct DNS names.
Therefore, the compatibility risk of distrusting ECM is practically
nonexistent. If breaking these 36 sites is a concern, then I suggest
name constraining the root to the 13 eTLD+1s which use ECM (also
attached).

ECM's incidents should give us very little faith in the adequacy of
their controls. Continuing to trust their certificates on the basis of
the notBefore date will only prolong the time during which Firefox
users are at risk of security incidents involving ECM.

Regards,
Andrew

On Tue, 11 Jun 2024 08:59:25 -0600
> All,
>
> We appreciate the comments received from the community on m-d-s-p and
> in Bugzilla regarding several recent incidents involving e-commerce
> monitoring GmbH (ECM). A summary of the most recent Bugzilla
> incidents has been published on the Mozilla wiki,
> https://wiki.mozilla.org/CA/e-commerce-monitoring_Issues.
>
> Public discussion and our review have highlighted long-running and
> unresolved compliance issues with ECM, including but not limited to
> (1) a failure to recognize, understand, and adhere to the compliance
> obligations of a publicly trusted CA, (2) repeated failure to meet
> the requirements for timely updates in line with incident reporting
> requirements (i.e.
> https://www.ccadb.org/cas/incident-report#incident-reports and
> https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed),
> and (3) inadequate responses, root cause analyses, and mitigations.
>
> Problems with ECM's operations and compliance began surfacing in
> February 2023, with the mis-issuance of certificates reported in Bug
> 1815534 <https://bugzilla.mozilla.org/show_bug.cgi?id=1815534> and
> further detailed in Bug 1830536
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1830536>. This revealed
> a substantial misunderstanding of root program requirements around
> timely incident response and rectification, leading to a delayed
> revocation incident (Bug 1862004
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1862004>). The overall
> finalization of these incident reports took over a year, completing
> in February 2024, due to both failures to include necessary
> information and excessive delays in responses by ECM.
>
> These issues have intensified in recent months, with a mis-issuance
> reported in Bug 1883711
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1883711>, which was then
> revoked with the incorrect reason code. Numerous further issues
> emerged in the incident response, including excessive delays in
> responses, failure to disclosure a similarly mis-issued certificate
> that was revoked but not mentioned in the subsequent incident report,
> failure to promptly self-report the initial incident when the CA
> became aware of it, and failure to identify suitable preventative
> steps to address the root cause. This incident remains unresolved as
> of this post, and it is unclear that sufficient preventative actions
> have been taken by ECM.
>
> In Bug 1888371 <https://bugzilla.mozilla.org/show_bug.cgi?id=1888371>
> reported on March 28, 2024, ECM was discovered to be serving
> incorrectly signed CRLs, violating the CA/Browser Forum___s TLS
> Baseline Requirements. Although ECM attempted an initial fix which
> proved ineffective, ECM has now missed the target date they set for
> themselves for a solution (May 31, 2024), meaning that their
> revocation infrastructure for some of their certificates has been
> unavailable for over 70 days, and ECM has not given any update on
> their progress towards resolution for over 30 days.
>
> ECM's general failure to respond in line with incident reporting
> requirements in a timely fashion is discussed further in Bug 1893546
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1893546>.
>
> Mozilla___s expectations for all CA operators participating in its root
> store are clear: they must provide timely updates and effective
> resolutions to incidents, they must ensure that root cause analyses
> are thorough and promptly updated based on community feedback, and
> they must maintain adequate staffing and resources.
>
> In light of ECM___s persistent issues, we will be setting ___Distrust
> After___ dates for websites and email trust bits associated with ECM___s
> GLOBALTRUST 2020 root CA, effective June 30, 2024. TLS server
> authentication and S/MIME certificates issued before June 30, 2024,
> will be unaffected by this change, but certificates issued after June
> 30, 2024, will not be trusted.
>
> We want to clarify that although a separate assessment of ECM___s
> continued inclusion in Mozilla___s Root Store was underway due to their
> acquisition by AUSTRIA CARD, this decision to remove ECM is unrelated
> to that ownership change and should not be considered a negative
> finding against AUSTRIA CARD. Should AUSTRIA CARD or a related entity
> seek inclusion in Mozilla___s Root Store in the future, that
> application will be considered on its merits.
>
> Sincerely yours,
>
> Ben Wilson
>
> Mozilla Root Program Manager
>
> --
> 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
> on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZMYjgxYAi72yPwcN3X_QJNqDUydpTyAuvmtBR9X80f1w%40mail.gmail.com.
ecm_dns_names.txt
ecm_etldplus1s.txt

Ben Wilson

unread,
Jun 11, 2024, 2:33:02 PMJun 11
to Andrew Ayer, 'Ben Wilson' via dev-security-policy@mozilla.org
Hi Andrew,

Although we have lost faith in ECM's ability to operate within the requirements of our root program, we've seen no evidence to suggest that they've engaged in or will engage in actively malicious behavior. 

We will continue to monitor the situation, and if evidence is found of misbehavior, then we will remove the root certificate on an expedited timeline, but still, we won't be waiting a year before filing a root-removal bug.

Thanks,

Ben

Andrew Ayer

unread,
Jun 11, 2024, 3:32:12 PMJun 11
to Ben Wilson, 'Ben Wilson' via dev-security-policy@mozilla.org
On Tue, 11 Jun 2024 12:32:47 -0600
"'Ben Wilson' via dev-secur...@mozilla.org"
<dev-secur...@mozilla.org> wrote:

> Hi Andrew,
>
> Although we have lost faith in ECM's ability to operate within the
> requirements of our root program, we've seen no evidence to suggest
> that they've engaged in or will engage in actively malicious behavior.
>
> We will continue to monitor the situation, and if evidence is found of
> misbehavior, then we will remove the root certificate on an expedited
> timeline, but still, we won't be waiting a year before filing a
> root-removal bug.
>
> Thanks,
>
> Ben

Hi Ben,

My concern isn't malicious behavior by ECM, but rather their lax
practices leading to a compromise which allows attackers to get
unlogged, backdated certificates that are used to attack Firefox
users, which Mozilla would have no way of detecting. I'm particularly
worried that they seem to have checked out from being a CA, leaving a
CRL broken for over 60 days and not answering any more questions in
Bugzilla.

It's really hard to understand why the distrust is being done this way
in light of what I pointed out about the tiny number of websites that
would be impacted by immediate distrust. Could you explain the
reasoning some more?

Regards,
Andrew

Andrew Ayer

unread,
Jun 11, 2024, 3:55:15 PMJun 11
to dev-secur...@mozilla.org
On Tue, 11 Jun 2024 13:11:16 -0400
Andrew Ayer <ag...@andrewayer.name> wrote:

> If we exclude ECM's own domains, this drops down to just 36 distinct
> DNS names.

Further analysis: of the 36 DNS names,

18 are serving a non-ECM certificate on port 443
9 are serving an ECM certificate on port 443
6 did not respond on port 443
3 are wildcard DNS names

Regards,
Andrew

Mike Shaver

unread,
Jun 11, 2024, 5:55:29 PMJun 11
to Andrew Ayer, dev-secur...@mozilla.org
I have to agree with Andrew. Continuing to trust this root and the integrity of "notBefore" on the certs it issues seems like it adds risk to Firefox and Thunderbird users without basically any value to the world. If those certificates have their key material leak, do we have any reason to believe that ECM will actually spring to life and help the subscribers? I cannot think of such a reason.

IMO we should excise it cleanly, and let Mozilla's users deal with the fact that they can't access those handful of sites--if indeed they ever ever notice.

Mike


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

Wayne

unread,
Jun 11, 2024, 6:58:02 PMJun 11
to dev-secur...@mozilla.org
I have to echo the sentiments, and question what setting a notBefore date weeks into the future signals to a non-compliant CA. If we're already in agreement that trust is lost, what does this grace period provide if not more room for either unintionally malicious, or actively malicious actions even by a third party? Any actions that have caused a CA to get into this trust state are doubtless continuing in the leadup to the final notBefore day.

Isn't this in effect a tacit agreement for a non-compliant CA to do what they wish for the next few weeks, because ultimately what is going to happen if they don't? What would be a root program's response is on the issuance of a distrust statement a CA then quietly sells non-SCT certificates for, say, interception purposes? It's a narrower window of opportunity but I can see a CA who is looking to make one last grab for cash on the way out abusing this system as it stands. I'm of the opinion that we need to build these enforcement mechanisms defensively and presume a malicious party if only for the security implications.

I can see an argument for a few days for the CA to recognize they are no longer trusted and to remove all documentation stating that their future issuances would work in specific root chains. I just don't see the security or integrity rationale in such a wide window, although I recognize that it has previous precedent I'd echo my statements to those as well.

- Wayne

Ben Wilson

unread,
Jun 12, 2024, 10:55:22 AMJun 12
to dev-secur...@mozilla.org

Dear Andrew and all,

We understand your concerns.

We are evaluating and considering your suggestions.

Thanks,

Ben Wilson

Mozilla Root Program Manager

Mike Shaver

unread,
Jun 12, 2024, 11:30:34 AMJun 12
to Ben Wilson, dev-secur...@mozilla.org
Thanks, that’s good to hear.

I think that there’s value in the thought experiment of “if Globaltrust for some weird reason asked to be added to the root store now, with a notBefore limit a little ways in the future and only the current trivial. set of certs in the wild, would we allow that? does it make Firefox and the web better for that root to be trusted that way?”

For me the answer is “no, making those handful of certs work is not worth the exposure”.

If we don’t remove the root, then I think we should set the notBefore limit to match the last cert that has already been issued. I don’t think we want to honour any certs that GlobalSign issues over the next few weeks…

Mike

e-commerce monitoring

unread,
Jun 14, 2024, 11:46:10 AMJun 14
to dev-secur...@mozilla.org, dev-secur...@mozilla.org, Ben Wilson
As you might know, browsers have decided to remove e-commerce monitoring GmbH (ECM) with its Root Certificate "GLOBALTRUST 2020" from their Root Programs as of June 30, 2024. Certificates issued before this date will retain their full validity.

The reasons for the removal have been comprehensively discussed Bugzilla forum. We acknowledged and accepted the decision. We have identified the shortcomings in our processes, particularly related to reaction time. Consequently, we are taking these issues very seriously and are committed to address them. An action plan is being rolled out to restructure our Certificate Authority (CA) functions. Our goal is to be included again in the Root Programs.

ECM’s shareholder, AUSTRIA CARD, is committed to regains full compliance with the Browser/OS Root Store Policies. This commitment, which is strongly supported by our recently changed management, underscores our dedication to maintaining the widest compatibility and coverage.
As an immediate action, and until full remediation, ECM has ceased the issuance of TLS certificates according to the CA/Browser Forum Requirements. TLS certificates will be provided solely based on Regulation (EU) No 910/2014, Annex IV, as recently amended by Regulation (EU) 2024/1183 (“QWACs”). Certificates for interoperability testing purposes are excluded from this decision.

ECM, with its product lines GLOBALTRUST and TRUST2GO, is a Qualified Trust Service Provider (QTSP) according to EU eIDAS regulation and is under continuous supervision by the Austrian regulatory authority (RTR/TKK). Our activities are regularly evaluated by an accredited conformity assessment body based on numerous standards (e.g., eIDAS, ETSI), which include comprehensive logical, physical, and organizational security measures.

Our goal is to rebuild trust and demonstrate our commitment to upholding the highest standards in our industry.

For inquiries, please contact the Compliance & Product Management team, Attn: Mr. Daniel Zens, at c...@globaltrust.eu
Reply all
Reply to author
Forward
0 new messages