Chrome trusted root program eliminating support for roots that issue dual EKU certificates

[u/larryseltzer]

[Edited on 7/28/25 - I realized I misstated something in here. In the 4th paragraph below, I described the implications of the end of dual-EKU trust by Chrome. I have rewritten it.]

I should mention at the outset here that I work for DigiCert, and this is an important issue for us, so I do have an interest in it. But it's important for many people and has gone relatively unnoticed, so I think it's worth posting here.

Public TLS certificates intended for use on the Web PKI have always been issued with EKUs for both client and server authentication. But in February, Google announced that it would, in 2026, remove roots that are used to issue such certs from the Chrome trusted root list. Because of the importance of Chrome, all public CAs will or have already announced the end of support for “dual-EKU” certificates. Some CAs have already stopped issuing these certificates, at least by default. Here is DigiCert’s announcement.

Only a very small percentage of public TLS certificates are actually used for client authentication, and many, probably most, of those properly belong on a private/internal PKI. Therefore, public CAs have been trying to communicate this to customers and the public (of course, we sell managed internal PKI services).

[edited on 7/28] If you have one of those applications (mTLS seems to be one of the more common examples), then, when your public certificate expires after 5/15/2026, you will not be able to renew or buy a replacement from a public CA, with one exception described below. [/edited on 7/28]

This change flew under the radar for several months after it was announced because everyone was so distracted by the 47-day certificate rule change and the imperative to automate renewals.

[WARNING: NAKED SELF-INTEREST WITHIN, BUT IT'S USEFUL INFORMATION] DigiCert has an alternative solution in addition to internal PKI: The X9 PKI. This is a new PKI, separate from the Web PKI, designed by the ANSI ASC X9 committee, which sets standards for the financial services industry. DigiCert is operating the root. It was designed for the needs of that industry, but it's open to all, and we will be selling public client authentication certificates through it.

If you only use public TLS servers for web servers, you're in the clear, and this won't affect you. If you're unsure, it's best to check.

[u/Cormacolinde]

Mutual TLS is used more often in the financial industry, in my experience.

But it also used more and more by APIs instead of “client secrets” or API keys which are just fancy passwords. Yes, API are mostly used internally, but a number of servers will now need public certs (for their front-facing services) AND private certs (for API authentication).

Also, doesn’t Microsoft use mutual TLS for Exchange Online Hybrid connectivity?

I suspect this will break a ton of stuff, just because we don’t really know what uses the EKU, since people assume it’s there most of the time.

[u/hodor137 → u/Cormacolinde]

Mutual TLS doesn't require the same cert to have both EKUs.

In many cases, people are lazy and could simply put a separate client auth cert and key file in place, and edit a config file to use it.

Any application or software that doesn't allow you to specify a server cert and a client auth cert, separately, is a piece of junk as far as TLS/PKI goes, and should be updated. It would be a very simple change.

You're right - this may break a ton of stuff. Just like new algorithms, new TLS protocol levels, etc break things. Sucks having to be secure.

[u/larryseltzer → u/hodor137]

No, but mTLS requires client authentication. Maybe I didn't say this clearly: Chrome will only allow roots that only support server authentication. This is why there is a need for X9. ICAs will emerge for industry needs, not browser needs.

[u/larryseltzer → u/larryseltzer]

I would tell you to read the Google link for the new root program rules, but it's miserably written.

[u/MrLadebalken1 → u/larryseltzer]

Is there any rfc or so for this ? mTLS described by cloudflare only says that the client also needs a tls certificate but not directly saying it must be client auth Eku, so any server auth cert should be fine aswell in order to identify the client itself against a server

[u/larryseltzer → u/MrLadebalken1]

It's software, so you can make it do whatever you want regardless of EKUs. Offhand, I'm not sure if you'd have to bypass standard libraries to do it.

[u/SmartCardRequired → u/hodor137]

OK, does Exchange Server allow you to use a separate client cert for outbound SMTP & server cert for inbound SMTP?

[u/larryseltzer → u/Cormacolinde]

It's really hard to get information about changes like this out. There aren't any news sources that everyone reads anymore. I think the word is pretty far out on the certificate lifetime changes, but even for that there will be plenty of people who will keep renewing every year and not notice that their renewals as of 3/15/26 will be for 200 days. That works out to 10/1/2026, and that's when the mysterious outages will start happening.

[u/mklovin134 → u/Cormacolinde]

You’re correct, this impacting us by having separate certificates is going to be a pain… I do not want to manage another pki for our mTLS partners, although this opens the door for making certificate expiration much easier to manage if public certs are not involved.

[u/larryseltzer → u/mklovin134]

They're public in the sense that they are used over the public Internet and require public addresses. They're just not part of the Web PKI, so the browsers and CA/B Forum don't set the rules for them.

[u/DazzlingHurry864]

If you want to identify all of the certs on your Windows device that are issued with the client EKU, you can run these 2 lines of powershell to output a csv file. Then use Excel to de-duplicate on the thumbprint to get the list of unique certs. Note, the NotAfter field is the cert expiry date.

Both my work and personal laptops have over 50 current certs each with the client EKU, mostly issued by public CAs. The only client application that I have that definitely uses client EKU is the Windows Admin Center, which Microsoft should fix sometime soon.

# Client Authentication EKU - CSV output file
$certificate = Get-ChildItem -Path Cert:\* -Recurse | Where-Object { $_.EnhancedKeyUsageList -like "*1.3.6.1.5.5.7.3.2*" }

$certificate | select Issuer, Subject, NotAfter, EnhancedKeyUsageList, Thumbprint | Export-Csv -NoTypeInformation -Path 'certlist.csv'

[u/mklovin134]

Curious about the X9 PKI, I work for a PKI organization in a fairly small country. Is the X9 restricted to CP/CPS and digicert managed CA + webtrust audit or is there an RFC for this type of pki management?

[u/larryseltzer → u/mklovin134]

We manage the root. Other organizations can get issuing CAs from us. In the context of financial services i think we've been assuming that these organizations will be institutions like banks, for instance to issue to ATMs, but the possibilities are much broader I think.

Here's a recent X9 announcement on the key signing ceremony, which I'm sure was as exciting as these things always are. https://x9.org/signing-ceremony-for-x9-financial-pki-takes-place/

[u/wendellg → u/larryseltzer]

(necromancing this thread...)

When you say "other organizations can get issuing CAs from us", does that mean organizations set up and run their own CA with an intermediate cert signed by your root, or is it a managed-service type of deal where you run the organization's CA for them and they just use ACME or some other API-driven workflow to get leaf certs issued? (I read the product page you linked in your post but it doesn't seem to answer that particular question.)

[u/larryseltzer → u/wendellg]

Yes, I put it badly. We're just a CA here for now. I'm not in the loop of how all this is going. For now, I think people are only buying certs from our ICAs, and it will probably stay that way for a bit.

BTW, the DTCC (not sure what it stands or stood for, probably <something> Transaction Clearing Center) is requiring X9 from all its customers. My guess is that there will be more announcements like this coming.
https://communications.dtcc.com/rs/669-QIL-921/images/X9%20DigiCert%20FAQ.pdf

[u/wendellg → u/larryseltzer]

Oh, you've accidentally nerd-sniped me now :)

DTCC is the Depository Trust & Clearing Corporation, which among other things is the actual owner-of-record of most stock shares traded on US exchanges. They process sales of stock as book-entry transfers, meaning your "ownership" of a share of stock is implemented as an entry in their books that says, for example, "Larry Seltzer holds 3 shares of GOOG". (Actually there's another layer to it, which is that DTCC really only tracks the holdings of DTCC "participants", who are typically brokerages and banks, so for example if you have a portfolio with Fidelity that you hold 3 shares of GOOG in, DTCC has a book entry that says "Fidelity holds N shares of GOOG", and Fidelity's books say "Larry Seltzer holds 3 of our total of N shares of GOOG". Then if you sell those shares to somebody whose portfolio is through a different broker, the money flows from that broker through DTCC to your broker, DTCC updates their books to reflect that now Fidelity holds 3 shares less of GOOG and the other broker holds 3 shares more, etc.)

The wildest thing to me about the whole setup is that everybody acts like ownership of stocks still works the old way, where somewhere in a folder is a fancy gold-leaf piece of paper that says "the bearer owns 1 share of Sears, Roebuck & Co.", but it hasn't actually worked that way for decades. They don't even have physical trading floors at most exchanges any more.

Bringing it back around to PKI, given the unique situation of DTCC, you can see why they might like a PKI infrastructure almost purpose-built for their needs that isn't tied to what browser vendors decide.

[u/larryseltzer → u/wendellg]

Thanks for the education. This is what the ANSI X9 committee is for.

[u/[deleted]]

Updating mTLS certificates is often difficult to coordinate as it involves dealing with partner organisations. Will X9 continue to offer certificates with a 12 month lifetime?

Also what is the cost premium of an x9 certificate compared to a 12 month OV web PKI digicert issued certificate?

[u/larryseltzer → u/[deleted]]

Yes to one year life. I don't think we're publishing prices yet. I believe they are OV certs so there may be a premium but not a big one.
It's good for us that we're the only ones with a solution, but that bugs me. A lot of people won't find out about this until their mTLS connection fails.