Root Causes 493: Disentangling Public and Private Certificate Use Cases

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

May 8, 2025

Changing root store requirements mean CAs must separate their root hierarchies for different certificate types. We explain why enterprises should consider private CA for some use cases.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanSo Jason, one of the changes that's occurring in the public CA space, the WebPKI space that you and I don't talk about all that much, is the decoupling and disentanglement of PKI architectures for different use cases. So we've seen traditionally that someone will have a root architecture or a root intermediate, and they'll issue leave certificates for different forms. They'll have S/MIME and Code Signing and Client Auth and SSL all sitting on that same root hierarchy, and this is going to be going away as a practice.

Jason SorokoFor some CAs, it's going to be a change. For many people who consume certificates, it's going to be a big change. That's why this is an important podcast, Tim. So a lot of people are surprised but you can use certificates for a lot of things if it's defined as being allowed by the certificate. And the root. Therefore, signing, encryption, authentication, certificates can do all of it. In fact, S/MIME certificates do do all of it. They really do.

In fact, a lot of people don't think about using S/MIME certificates for authentication, but you can. You can use them for authenticating into email systems. I think Tim, what we're saying is Google - we podcasted on this about the decoupling of private and public - I'm gonna put the link to the previous podcast on the screen here somewhere - and then this is an update, really, to that, because I think I had said in the 2025 predictions episode that Google was going to, based off of their blog that came out in October 2024, that there would be some kind of update later in 2025. Well, I was wrong in that it would be later in 2025. It happened February 2025 and that update specifically came in in the update to the Chrome Root Store Program version 1.6; came out in February. For those of you who want to read it, Section 3.2.1, Section 3.2.2.

Now I know you have some basis and knowledge of what it is saying, describe it, and then we're going to get down to what it really means.

Tim CallanSo it's building off what I said before, which is Chrome has for a while, for a few years, been telegraphing and pursuing this path of really requiring that root hierarchies be designated for one purpose. So your TLS root hierarchy can only be used for TLS. Your S/MIME root hierarchy can only be used for S/MIME, etc. Now, to be clear, their sandbox, Chrome's world, is TLS. Chrome doesn't feel they can tell you what to do with Code Signing. Do whatever what you want with your Code Signing, but what they really want is they want your TLS certificates not to be anything else.

Jason SorokoTLS Server Certificates.

Tim CallanCorrect. Thank you. They want your Server Certificates not to be anything else, just to be Server Certificates. So that is accomplished by having different root hierarchies, different intermediates that serve your different your different kinds of end leaf certificates. At least part of the reason Chrome wants this, Chrome wants this for a few reasons, but a lot of it is they want to disentangle these use cases in order to promote agility and the ability to do specific things that are necessary for that use case. So for instance, as people talk about shortening the maximum lifespan of a TLS certificate, if someone comes back and says, well, you know what, this is going to hurt us because we have authentication use cases where we can't update them that quickly, then the response to that is, well, yeah, but those should be different products. Those should be different technical certificate root hierarchies that don't intermingle with each other. And once that's the case, then you can take your Client Auth and you can do whatever you want. Not my sandbox, I don't care. If you want to have 17 year Client Auth certificates, that's between you and whoever, but I'm going to have TLS certificates that do what I need them to do for servers. So that sort of reasoning takes us down this path and this has been phased in over time. The starting point was that new roots, new root inclusion requests, had to be designated. That's where it started. But they're going to wind up at a place where anything that's multi-purpose is essentially going to have to be retired and replaced by something that is not.

Jason SorokoLet's put it into really plain English, because we've now said all the facts, but I think that people who are consumers of certificates might not understand the full implication, which is Google Root Store Program is only going to trust TLS Server Certificates, and certificates that were issued by roots that only issue TLS Server Certificates.

So the application to become a new root, your ability to have anything other than pure TLS Server Certificates ends June 15 of this year. June 15, of 2026 is the really crazy date where all certificates that are trusted by Google's Root Store Program, Chrome, will have to be TLS Server Certificates.

Now what does that really mean is that there are a lot of you who are using TLS client certificates issued by public CAs, and you are using them for Client Authentication. Google had said a great number of CAs and a great number of certificates from a lot of CAs had no association at all with TLS server purposes. In other words, SSL, as we know it.

They were mostly being used for Client Authentication. So if you are using a publicly trusted certificate for the purposes of Client Authentication, logging into salesforce.com, your sales person was issued a certificate onto their laptop, they log into salesforce.com with it. That's something you could absolutely do at the moment.

What Google is saying is Google is only one Root Store Program, and they're not saying that they can stop a lot of these things, other than distrusting roots that are only TLS Server Certificates but what they are saying is those roots will no longer be trusted unless they are only TLS Server. Therefore they're basically pushing you towards using a private Certificate Authority, essentially, for the purposes of private Client Authentication.

Tim CallanOne of the pragmatic consequences of this, like in theory, CAs, public CAs, could offer other products on their publicly trusted roots and that would be fine. One of the pragmatic consequences of this is, once I'm not using the same kind of certificate for everything and just fire hosing them that the expectation is that a lot more of these non-server cert use cases will migrate to an internal CA. And furthermore, the expectation is that's probably better. One of the things that we saw - this goes back to the Bugzilla blood bath and all that - one of the things that we saw in 2024 was this frequent objection - this also was built around the shortening certificate lifespans debate - This frequent objection of, well, we use these certificates in certain conditions where we can't meet the requirements that are being thrust on us by the CA/Browser Forum, and also we can't have outages. So the answer to that is, if you can't meet those requirements, and you can't have outages, then you can't be on public certificates. This needs to be an internal PKI architecture.

Jason SorokoCorrect, Tim. So it all comes down to certificate agility. The problem is a lot of these TLS Client Authentication certificates are put into places that are not agile at all. A salesperson who's in an airplane right now who has a revoked cert isn't going to get that cert revoked in time, and probably doesn't want to anyway, because that's a function where he's got to be connected to a network, etc., etc. Not a terribly agile system. However, if that salesperson logging into salesforce.com with a private certificate, you can make that a much longer lived certificate or have policies that allow for much longer revocation length. Whatever. And so Google is making it really clear that certificate agility is going to be the rule.

Tim CallanAnd Google's philosophy on this is we only consume server certificates. Therefore we only want to dictate server certificates. Also, though, we want to be able to dictate server certificates, and we don't want objections about a use case that we have no stake in to prevent us from doing what must be done with server certificates.

Tim CallanCompletely makes sense.

Jason SorokoUnlike the MPIC topic where there's no effect to you as the consumer of the certificates, it's more of a special interest to us, and we're sharing information. This particular topic affects all of you who consume certificates, because there's a lot of you out there. You may not even know who you are. That's the problem. You might be consuming publicly trusted certificates for the purposes of Client Authentication, and that's gonna have to change. And you have a little bit over a year, but not more than that, to change what you're doing. That's not a ton of time. And that's why even I was surprised, Tim, in the 2025 predictions episode, when we talked about this, and I said later in 2025. It was February, folks. February. Where this determination came down. So this is a first shot warning from us on this podcast. You’re gonna hear it again from us. We're going to be talking about this over and over again.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!