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.
Ar Iau, 21 Mai 2026 am 12:45 Martijn Katerbarg < [email protected]> ysgrifennodd: > 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 [email protected] < > [email protected]> > *Date: *Thursday, 21 May 2026 at 10:43 > *To: *Hanno Böck <[email protected]> > *Cc: *[email protected] <[email protected]> > *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 > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/J5K_pWsD!B8YZvmjb8QjWoztqdHC96hcvUGBEfLzDuzl8YM8dchr63tFwGU9whH8LLEpnJuHVd6DQXkNe3GLB9AkZq8YY8JZ-6IpCGkZHOV392uZb7jHnaKgzd-Zktpootxi0N5gXLD8$> > > On a quick re-read of the Baseline Requirements, what DigiCert did here is > unusual, but per the letter of the law, not forbidden. > > Ar Iau, 21 Mai 2026 am 10:13 Hanno Böck <[email protected]> ysgrifennodd: > > 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 > <https://urldefense.com/v3/__https://knowledge.digicert.com/general-information/digicert-root-and-intermediate-ca-certificate-updates-2023__;!!J5K_pWsD!zVYUaEsdyovFYibEP4K4xjBGOp-DMFuQAM3ztOHs9ScwYTET1dqVRMRaaZc1T0EoBBDqbXXaacP7WNqtMBjXT65xCqH9tqxtRsI3$> > > Subsequently, Mozilla removed the trust bit: > https://wiki.mozilla.org/CA/Root_CA_Lifecycles > <https://urldefense.com/v3/__https://wiki.mozilla.org/CA/Root_CA_Lifecycles__;!!J5K_pWsD!zVYUaEsdyovFYibEP4K4xjBGOp-DMFuQAM3ztOHs9ScwYTET1dqVRMRaaZc1T0EoBBDqbXXaacP7WNqtMBjXT65xCqH9tvnZtiMi$> > > 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://urldefense.com/v3/__https://itsec.hboeck.de/__;!!J5K_pWsD!zVYUaEsdyovFYibEP4K4xjBGOp-DMFuQAM3ztOHs9ScwYTET1dqVRMRaaZc1T0EoBBDqbXXaacP7WNqtMBjXT65xCqH9tjgThEST$> > https://badkeys.info/ > <https://urldefense.com/v3/__https://badkeys.info/__;!!J5K_pWsD!zVYUaEsdyovFYibEP4K4xjBGOp-DMFuQAM3ztOHs9ScwYTET1dqVRMRaaZc1T0EoBBDqbXXaacP7WNqtMBjXT65xCqH9tlvmVCNM$> > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20260521101253.2522b540%40hboeck.de > <https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20260521101253.2522b540*40hboeck.de__;JQ!!J5K_pWsD!zVYUaEsdyovFYibEP4K4xjBGOp-DMFuQAM3ztOHs9ScwYTET1dqVRMRaaZc1T0EoBBDqbXXaacP7WNqtMBjXT65xCqH9tgjgonN9$> > . > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMEWqGvkfXs1fBR10gV1jEHzJHPkAQCr1Sq8A%3DfLiLzzX2DjkQ%40mail.gmail.com > <https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMEWqGvkfXs1fBR10gV1jEHzJHPkAQCr1Sq8A*3DfLiLzzX2DjkQ*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSU!!J5K_pWsD!zVYUaEsdyovFYibEP4K4xjBGOp-DMFuQAM3ztOHs9ScwYTET1dqVRMRaaZc1T0EoBBDqbXXaacP7WNqtMBjXT65xCqH9tsFJl1W0$> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMEWqGvc-OfkaSfWVvYVfJBsKeZWwh2Hes_99bxuPxgMhKJS7g%40mail.gmail.com.
