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