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]<mailto:[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]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:dev-security-policy%[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]<mailto:[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/DS0PR17MB6079F0328006A145886BBE82E30E2%40DS0PR17MB6079.namprd17.prod.outlook.com.
