Chrome's deadline for deprecation of the clientAuth EKU and mTLS in public certificates has moved out. We give you the what, when, and why.
**Jason Soroko** (00:00.00)
Hey Tim, got a question for you.
**Tim Callan** (00:02.32)
I got an answer for you. Always.
**Jason Soroko** (00:09.04)
So one topic that has been one of my hobby horses, because I'm fascinated by this change, has been the client auth EKU. Client authentication certificates that are publicly trusted. There was a no longer trusted date by Google — Chrome root program, June 15, 2026, was the date. And this isn't BR, this is a Chrome root program requirement, but that still has the same power in terms of all CAs winding up complying. Chrome root program requirement was June 15, 2026, that public TLS certificates could no longer contain the client auth EKU.
**Tim Callan** (01:02.11)
I think I know where you're going with this, but go ahead.
**Jason Soroko** (01:06.99)
Yeah, Tim, you know exactly where I'm going with this, which is the date was set in kind of stone-ish, and then it moved. I'd love to hear your take on the story of the change.
**Tim Callan** (01:12.22)
Okay. So first of all, let's make sure the listeners know this because they may not. Very recently, in the latter days of January 2026 — might even have been early February now that I think about it — Chrome moved that date out, and they moved that date to March 15, 2027, which is a long way — nine months. So that is the change, and your question is what motivated that.
So I think it was two things, and this is me reading tea leaves, so anybody from Chrome root program, if you want to let me know, I will clarify if I'm getting this wrong. But I think that it is a combination of two factors. One of which is that there was definitely a lot of feedback from the market of this is hard, and this is going to be painful to get this done. And one of the things that Chrome has been really clear about, and all the major browsers have been clear about — and I believe that this is earnestly the case — is they do want to modernize and progress the WebPKI, but they really, as much as they can, want to do it in a way where they're not breaking things. I think they feel that if things must be broken because we have no choice, they're willing to break things, but they try to find paths forward that don't break things, if that makes sense. Right? So in this case — and we see this in other things, we saw Apple pushing out the dates for ten-day DCV and forty-seven-day cert term by a year to give people more time to adjust because they don't want to break things. So this "don't want to break things" factor works into their plans, even though they're very committed to changing and modernizing and progressing the WebPKI. And this is the balancing act they go through. So I think that was part of it — a lot of market feedback, possibly more than anticipated, that this is going to be really painful, this is going to hurt, so give everybody an extra nine months.
The other thing is there's a lot going on in 2026. We have three step-ups for MPIC, we have step-downs for both DCV and maximum certificate term, we have deprecations of DCV methods — it is a crazy year, as was '25, in terms of what has to be done. And I think there was a sense of, we're just going to load one more thing onto the enterprise at a time when the PKI teams are already overtaxed. And again, in the spirit of we don't want to break things, maybe having all this stuff coming in rapid succession in the first half of a single calendar year is too dangerous.
**Jason Soroko** (04:50.13)
Tim, I think that's a great thought, because we've had some podcasts we just published — all the dates — and it was just a massive number of dates. In fact, the thumbnail I chose for the YouTube site was just this guy face-palming and looking at a calendar with so many things on it.
I think, Tim, that my first reaction when I heard about that distrust of client authentication certificates in 2026 was holy smokes. I really didn't believe that we were going to be in a world where you could completely strip that away. And I tell you, the number one reason isn't even going to be the sheer difficulty of switching everything to private certificate authorities. That's going to be hard enough. It's — do people even know that they're using this certificate type?
**Tim Callan** (05:50.17)
And so this is another thing that we touch, and I think it's valuable and important. We've touched this in the past and we'll do it again, which is we at Sectigo have learned empirically that oftentimes these large, complex digital environments are operated by people who do not have a full understanding of how they work.
And so the best example of this was we had a root expiration that occurred maybe about five years ago. And root expirations can't be delayed — they expire when they expire. And so we started communicating long in advance, two years in advance, to say, by the way, this root is expiring. And we told everybody as much as we could, and we reached out to all of the large enterprise customers. And we were at the point when that root expiration came that 100% of the large enterprise customers were of the opinion that they were going to be entirely unaffected. And then the day came and stuff broke all over. And that was an aha moment for me, which was to say, no offense to anybody, but you don't know what's happening in your environment. And so when a large enterprise PKI manager tells me, "Well, that won't affect us," what my brain translates that to is "We are not aware of any ways that that will affect us" — which is not the same thing.
**Jason Soroko** (07:35.76)
Tim, I'm going to make an uncomfortable statement. I'm good at making uncomfortable statements. Tim, it's 2026. As of right now, we're in the future, man. And I'm going to tell you, I think enterprise IT — I remember back in the nineties, it was fragile. In the 2000s, it was fragile. In the 2010s, it was fragile. We are now in the second half of the 2020s. It's fragile, Tim. And this is just another example. I'm almost thinking we should have a podcast about what are all the things I guarantee you don't know about your own environment. And one of them is — do you use client authentication certificates? Do you use DNSSEC? Is it configured properly?
**Tim Callan** (08:31.99)
So let's take another thirty seconds before we close this out to talk about how Sectigo is helping with the client authentication problem. And we may have covered this in an earlier episode, but I think it's worth hitting this again.
So we have a system that we just call the toggle — it's our informal name. And what we can do is for certain capabilities, we can shut it off universally for all the certs, and then on an account-by-account basis, we can temporarily reactivate it. And this is what we do. Now, you can't do that in the case of a root expiration, but for other changes that come, this is what we do to avoid that exact problem.
So literally — new thing, there's going to be, we're going to get rid of the ability to do X, Y, and Z. And everybody says, "I don't use X, Y, and Z." Well, we go, okay, well, maybe you do and you don't know it. So what we'll do is we'll do the universal shutoff. And then now it's scream test time. When something starts breaking, people call us up and say, "Oh my God, my stuff's not working." We say, okay, fine, we'll turn you back on. "My stuff's working, thank you so much." Okay, you got ninety days, get it fixed, and I'm turning you back off. And that is how we run it.
And so we have been running that since Q4 for the client auth deprecation. We have a discrete list of accounts — we know who they are — who have been turned back on. With all of them, we have a handshake agreement on when they're going to get this fixed, and then we're going to turn them back off. And then when they break again, we'll turn them back on, and we'll have a handshake agreement on when they're going to fix the new problem, and we do this until it gets fixed.
And I think that is the best practice for changes like this, because the other choice is you say, "Told you, not my fault, too bad, so sad." And while I could sit on my high horse and say, well, I told them and it's not my fault — too bad, so sad — at the end of the day, like the root programs, what we want to do is not break stuff. And this is the best way to not break stuff.
**Jason Soroko** (11:02.89)
Gentle breakage that is recoverable is the signal of, oh, you have something you need to change.
**Tim Callan** (11:14.33)
It's unfortunate that you can't just know where to make your change without having to have the breakage and the oops moments. But it's just a reality. Wanting is easy — I can want things all day. I want everybody to know what's going on in their environments, but they don't. And we just need to accept the reality of that and make the smart decisions that help us progress the technology while breaking as little as we can.
**Jason Soroko** (11:43.65)
Very good, Tim.
**Tim Callan** (11:44.50)
Thanks, Jay. Thank you.