EKU of Root Certificate

We are in the process of rebuilding our servers and have noticed our certificates stopped working, I have tracked down the issue to a certificate chain validation. By all means, I am not a certified expert so do not fully understand what is "intended"

The application in question is one where it uses the certificate for both client and server authentication,

Although the leaf has both Client and ServerAuth EKUs, the chain built to ISRG Root X1 (which only has ServerAuth EKU) fails CertVerifyCertificateChainPolicy when invoked for the auth type ‘client’. When the chain is built up to the DST Root CA X3 , the policy verification succeeds.

The DST Root CA X3 has EKU of Client Auth, Server Auth, Document Signing, Encrypting File System, Secure Email and Time Stamping.

The ISRG Root X1 has EKU of Server Auth only.

Is there any reason why the ISRG Root only has Server Auth Usage and not all the other usages?

Hmm. I think (though I am also far from an expert in such things) that the EKUs "allowed" for the root are more a part of how the trust store is configured rather than something about the certificate itself. Are you by any chance using a Microsoft platform for your tests? There was another thread here a couple months ago where somebody was complaining that the ISRG Root is only enabled for Server Authentication on Windows:

But there really wasn't much of a solution offered there. You might be able to add a copy of the root to your own trust store with more EKUs added for systems that you need to use it for, much like one might do for adding a private CA to one's enterprise, but I'm not sure on the specifics how myself.

2 Likes

We are indeed using the Azure Platform and the Microsoft Windows 2019 OS Images.

We have been using the Lets Encrypt certificates successfully until we re-created the OS images, with the same app configurations etc everything stopped working. The explanation we have from Microsoft is that the Root cert is missing the Client Authentication EKU.

The post you shared, explains it perfectly. Thanks.

1 Like

So the real question, I suppose, is whether there's some process that somebody could take (presumably somebody at Let's Encrypt) to ask Microsoft to include Client Authentication for both ISRG Root X1 and ISRG Root X2. (The X2 root wasn't in Microsoft's list yet at the time of that thread a couple months ago, but looks to be there now, but also with only Server Authentication enabled.)

@lestaff: Is there someone who could comment on whether the Client Authentication EKU being missing from Microsoft's root trust store is intentional? This is the second person who's asked about it (see my link to the prior thread above), and it may become more of an issue as people move away from DST Root CA X3. I know the "typical" use case for Let's Encrypt's certs is for Server Authentication, but as the leaf certs and the intermediates all have Client Authentication enabled as well that implies that it's at least supposed to be an intended "supported" scenario. However, the Microsoft Root List has both ISRG roots only allowed for Server Authentication, which makes using LE certs as client certificates much more complicated on that platform. Or at the very least, it may be worth adding a page to the documentation about client certificates in general and under what cases they're intended to work.

1 Like

@petercooperjr, It is clear that the Windows Certificate Store does lack the necessary for those LE roots to directly issue end leaf certs for Client Authentication.
But won't there always be an intermediate involved?
Can't the roots allow the intermediates to do more than themselves?
Or would least privilege be applied down the chain?

And in any case, please take a minute and give (me) some more info on "much more complicated".

2 Likes

From CA/B BR root certificate themselves are not allowed to have extKeyUsage?

7.1.2 Certificate Content and Extensions; Application of RFC 5280
This section specifies the additional requirements for Certificate content and extensions
for Certificates.
7.1.2.1 Root CA Certificate
....
d. extKeyUsage
This extension MUST NOT be present.

if you look at certificate themselves (self signed one) they don't have extendedkeyusage extension

x1: https://letsencrypt.org/certs/isrgrootx1.txt

    X509v3 extensions:
        X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Subject Key Identifier: 
            79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E
Signature Algorithm: sha256WithRSAEncryption
2 Likes

My understanding (and again, I am far from being an expert, I'm just an enthusiastic amateur), is that at least in the way Microsoft's trust platform (the Crypto APIs built into Windows and such) work, the answer is no: roots can't allow intermediates to do more than themselves. That is, in order for a specific EKU to be "allowed", it needs to be contained in not just the leaf, but also in the entire chain of intermediates up through to the root. And which EKUs are allowed for the root is determined by the trust store database, not something inherent to the self-signed root certificate itself.

That is, if you look at the "txt" format of the intermediates on the Chain of Trust page, they say "X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication". But the roots on that page, whether self-signed or cross-signed, don't list an "X509v3 Extended Key Usage" at all.

My understanding is that Microsoft's approach of needing the EKUs to be there up through the whole chain is not always what's done by everybody else, but isn't "wrong". This is one of the areas I'm really fuzzy on, though.

But I think all the root stores do something like this: Mozilla's trust store separately determines whether a root is trusted for TLS, S/MIME, or both. And Microsoft's trust store here is specifically saying that the root should be trusted for Server Authentication, but not for other usage like S/MIME or Code Signing. Which makes sense, because Let's Encrypt's root isn't "supposed" to be signing Code Signing certificates and isn't being audited for such, so it's safer to not allow that usage.

But, it seems like Let's Encrypt's root is "supposed" to be signing Client Authentication certificates (or at least, that's in the EKU of their intermediates and leafs), but it's not "trusted" for such in Microsoft's root store. So, if using Microsoft's APIs to validate certificates, if one wants to do a mutual TLS type thing of both the client and server sending their certificates, it doesn't work. One would need to use a different Crypto library with a separate trust store (like say, using Mozilla's libraries or OpenSSL, just for some examples), rather than the stuff built-into the OS. And if integrating with other Microsoft products (like IIS), might be tough-to-impossible to get working at all.

3 Likes

Confirming what has been said above, in fewer words:

  • In general, Root Certificates do not contain EKUs specifying their uses; EKUs are generally found only in Subordinate CA (Intermediate) and Subscriber (End-Entity) Certificates. Specifically, neither ISRG Root X1 nor DST Root CA X3 contain any EKUs in the certificate itself.
  • Root programs tag trust anchors with the usages that they allow that anchor to be trusted for. It appears that the Microsoft root program has DST Root CA X3 tagged with many uses, while it has ISRG Root X1 tagged with only the Server Auth usage.

It is not clear to me personally why ISRG Root X1 is not tagged as being trusted for Client Auth in the Microsoft Root Program, but I assume some of the other folks here know. I'll work with @josh to get a better understanding of why this is the case, and whether it can be changed.

8 Likes

But are we agreed that it must be changed in order for a subscriber to be able to use both (server and client auth via Microsoft Certificate Trust Store)?

1 Like

Yes, it would need to be listed as trusted for Client Auth in the Microsoft Root Store for a Windows Server to trust incoming client connections presenting a chain to ISRG Root X1 in their TLS handshake.

No comment yet on whether the current state is intentional or an oversight, nor on whether or when it could be changed.

7 Likes

Jumping back a bit for the problem, how did you determine the chain validation failure reason? Extended CAPI2 logging in event viewer maybe?

I'm assuming this is not specifically about client certificates (client machines authenticating themselves with a certificate) and is just about you trying to provide a normal https enabled web service to the public (or users who have no special client certificate)?

I'm trying to figure out how to recreate the same problem.

2 Likes

For the previous thread (Certificates signed by ISRG Root X1 aren't enabled for client authentication on Windows - #9 by peterb), we determined the cause of the issue by trying to use CryptoAPI (via the .NET certificate abstractions) to build a certificate chain for the application policy 1.3.6.1.5.5.7.3.2 (clientAuth). This fails if the certificate chain is built using an intermediate certificate that is signed by ISRG Root X1 (or ISRG Root X2), and works if using an intermediate certificate that is signed by DST Root CA X3. Building the certificate chain also works if manually adding "Client Authentication" as an Intended Purpose to the ISRG Root X1 in the trust store.

5 Likes

Ok, so it's specific to validation of client certificates (which is a niche use of LE certs which happens to work currently).

One potential workaround would be to just switch these scenarios to an alternative CA who's root has the required usage enabled already (e.g. BuyPass Go via their Class 2 root).

2 Likes

yes

well, I sort of disagree on the second part of this point. As I already pointed out in the other thread, and which @petercooperjr also commented on in this thread (

), the end certificates issued by Let's Encrypt do contain the clientAuth EKU. This does communicate the intent to support client authentication. It might be a niche, compared to the most typical use (a web server just authenticating itself to its clients, i.e. using serverAuth), but MTLS is still a widely used and incredibly useful concept.

4 Likes

If MS doesn't change their store restrictions in time...
[I'm pretty sure they will eventually]
What is the go to workaround plan (while we wait)?
Are there any other "FREE" roots included in older lists?
Like the one shown here:

1 Like

Yeah I see what you're saying, clearly people are now relying on this functionality to work. I just haven't seen anything anywhere saying Client Certificates it was an official part of the certificate service that Let's Encrypt provide/support.

1 Like

Yes, BuyPass for one (and also the only alternative that doesn't require EAB, so that doesn't potentially complicate migration).

1 Like

I didn't see their FREE root in the list provided above.

1 Like

As far as I know its Buypass Class 2 Root CA in https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT

1 Like

I don't see their Class 2 root - only the Class 3 root listed in the link provided above yours:

1 Like