Microsoft MX servers use certificate chaining to obsolete DigiCert Global Root CA

[Hanno Böck]

Hi,

This issue was brought up recently on the mailop list by Geert
Hendrickx, but it has no public archive, so I can't link to it.

It appears Microsoft MX servers are using certificates from DigiCert
that are chaining to an obsolete root certiifcate.

E.g., for the host
outlook-com.olc.protection.outlook.com.:25
I get a cert chain with a leaf cert signed by
DigiCert Cloud Services CA-1
This intermediate cert is signed by
DigiCert Global Root CA

DigiCert declared this root to be TLS-distrusted by April 15, 2026:
https://knowledge.digicert.com/general-information/digicert-root-and-intermediate-ca-certificate-updates-2023

Subsequently, Mozilla removed the trust bit:
https://wiki.mozilla.org/CA/Root_CA_Lifecycles

Most Linux distros have some form of certificate package that
indirectly utilizes the Mozilla root store. I've heard a report from
someone already affected by this using the latest nixos package.

Due to MTA-STS, an untrusted MX certificate leads to connection
failures.

While I'm not sure if this is any form of policy violation, it is
certianly surprising that DigiCert declared a root as "TLS-distrusted"
and did not make sure that all certs chaining to that root are expired
or revoked/replaced.

--
Hanno Böck - Independent security researcher
https://itsec.hboeck.de/
https://badkeys.info/

[Q Misell]

On a quick re-read of the Baseline Requirements, what DigiCert did here is unusual, but per the letter of the law, not forbidden. 

--
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/20260521101253.2522b540%40hboeck.de.

[Martijn Katerbarg]

I would not even go as far as calling this unusual. In fact, to an extent, this is required behavior.

There’s two items ongoing here: 

1. A CA issuing a certificate from a hierarchy which is distrusted by at least 1 root program
2. A Subscriber utilizing a certificate issued from a hierarchy not trusted by at least 1 root program.

I’ll start off with item 2: There are plenty of reasons why this might happen. We’ve seen cases where cross-signing chains do not properly work, unfortunately, and likewise we as CA also see many cases where customers are dealing with very old trust stores, and thus still need certificates issued by what I’ll call legacy chains. I don’t like it, I believe this is a problem we shouldn’t have, but alas, we do. Certificate Pinning and limited, outdated trust stores, are a fact of life I deal with on a daily basis, and education by CAs only goes  to a certain point. 

I believe a CA should warn subscribers of the potential issues that may arise when requesting legacy chains, but to an extent, the final decision and risk analysis should be up to the subscriber.

With regards to item 1, which I think this thread focused on: No, this is absolutely not unusual, and if this would be forbidden, that would directly be the cause of incidents for CAs. 

The fact that a CA hierarchy has been distrusted, does not dismiss it’s trusted states within other trusted root stores. That means such CA must remain compliant with the BRs, and therefore must be able to issue certificates, purely for the fact that CAs are required to host test websites for those CAs, so long as the CA is trusted by at least 1 root store. Hence forbidding issuance, would put the CA in an unresolvable conflict between different root stores. 

I would add two items there: 

1. The distrust of a CA hierarchy, depending on what type of distrust method is used, essentially means the CA hierarchy no longer needs to comply with the browser’s own root store. In short: You can’t have a say over something you don’t include. (Yes, there’s some nuance here about those CAs still being included in older version of that root store, a discussion we should have, probably in this thread: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/ApQ96PKH8r0)
2. Most of these distrusts are based on their trust bit removal. Trust bits essentially work this way: “Whatever this CA issues, we will only trust it if the EKU matches the trust bit we’ve enabled”. Again, this does not prevent the CA from doing something else with those CA keys, it just won’t be trusted within the root program in question. 

Regards,

Martijn

From: 'Q Misell' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Date: Thursday, 21 May 2026 at 10:43
To: Hanno Böck <ha...@hboeck.de>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Microsoft MX servers use certificate chaining to obsolete DigiCert Global Root CA

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMEWqGvkfXs1fBR10gV1jEHzJHPkAQCr1Sq8A%3DfLiLzzX2DjkQ%40mail.gmail.com.

[Q Misell]

Thanks Martijn for the reply. Considering your points, I agree and revise down my statement of this being unusual behaviour by DigiCert. I think, then, we can chalk this up to Microsoft making a mistake by selecting an unsuitable chain, weather they understood the consequences of that or not.