We noticed that we can't use new Letsencrypt certificates signed by ISRG Root X1 CA for client authentication on Windows. This is due to the fact that Windows allows only server authentication EKU OID for ISRG Root X1 CA (via authroot.stl/authroot.tsv at master · robstradling/authroot.stl · GitHub).
What is the process of deciding which EKU will be allowed in Windows? Previously Letsencrypt certificates were signed with DST Root CA X3 and Windows allowed client authentication OID for these(authroot.stl/authroot.tsv at master · robstradling/authroot.stl · GitHub). Is it expected that client authentication OID could/will be enabled in the future?
The child certificates contain both Server/Client authentication OIDs, but the chain does not validate because of missing Client auth OID for ISRG Root X1. (Same for ISRG Root X2)
You would generally issue Client Certificates from your own in-house Certificate Authority (such as Active Directory Certificate Services, or another self-hosted CA like smallstep-ca).
@webprofusion when you say "intended purpose", do you refer to the concept in Windows, which reflects the valid Extended Key Usages of the certificate, or a general notion of what Let's Encrypt certificates are supposed to be used for?
Let's Encrypt end-entity certificates do contain the clientAuth Extended Key Usage, and as suggested by the post you referred to, it should be technically possible to use a Let's Encrypt certificate as a client certificate, using a dNSName from the certificate's SAN as the authenticating identity (which is incredibly useful in MTLS scenarios).
In this case, however, the problem is that if you try and validate a certificate chain for client authentication on Windows, the validation fails if the chain is rooted in the ISRG Root X1 certificate, whereas it succeeds for a chain rooted in the DST Root CA X3 certificate. This is because the Certificate Trust List (CTL) in Windows imposes a policy on the ISRG Root X1 certificate that limits EKU to serverAuth only, and this applies transitively down the certificate chain. This results in a disconnect between the EKUs specified in a Let's Encrypt end-entity certificate (serverAuth and clientAuth), and the EKUs that apply effectively on Windows (serverAuth only). This, I see as a definite problem!
This decision is ultimately Microsoft's. I don't know (and perhaps Let's Encrypt staff could clarify) whether the application process for Microsoft's trust store involved a step where they had to explicitly decide whether they wanted this, and whether they'd be open to going back to Microsoft to ask that it be altered.
It can probably be argued either way as to whether it's just always appropriate to allow Client Authentication knowing these clients have identities only in the form of a DnsName SAN (and so they must be machines and not people) or whether instead this is not something you want to allow. Personally I favour it, but I used a lot of mutual TLS in a past job so maybe it's just me.
If it wasn't something Let's Encrypt explicitly decided to do, it could also make sense to reach out to Microsoft to encourage them to set this flag for ISRG Root X1. It might (but I do not know how) also be possible to just tell the relevant code in Windows that you intend it to check the certificates (which you actually want for client authentication) as if they were for server authentication (if you are checking DnsName SANs then I expect that server authentication will always be set)
Hmm. I do actually use a Let's Encrypt certificate as a client certificate, in order to authenticate my mail server to Microsoft Exchange Online Protection. (That is, in order to prove that my system is allowed to relay outgoing mail through their protection service, my mail server connects to theirs and is authenticated with a client certificate, though it's the same certificate that's used for my mail server to act as a server as well.)
For the next few months you ought to be able to use the "long" chain with ISRG-Root-X1-signed-by-DST-Root-X3 added, though I don't know how easy it is to add to the chain when using client certificates.
If you look at their current list
Which links to an export from CCADB, it does only show ISRG Root X1 as being allowed for Server Authentication. I'm guessing that in order to be added to Microsoft's Roots as a Client Authentication source as well that Let's Encrypt would need to specifically apply to their root to be added for it.
If you're only client-authenticating to servers you control, you might be able to manually add the root as a Client Authentication usage to your own servers trust stores somehow.
I'm not sure I understand the problem you are having...
LE certs can be used for client & server authentication:
[both are tied to the same chain (same cert) - so if one works, so should the other]
I think it's that Microsoft's trust platform (using their APIs and such) requires the entire chain to be trusted for the usage involved, and the ISRG Root X1 root is only trusted in their trust store for Server Authentication, even though the leaf certs also say they can be used for Client Authentication. It's like even if Let's Encrypt started offering S/MIME or Code Signing or whatever (not that I expect them to add those at any point, just using as an example), those usages wouldn't work on the Microsoft platforms because the root isn't trusted for them.
I am surprised that the Microsoft root program includes Client authentication. I always thought the authentication requirements for client certificates were an application specific concept, so it would not make sense to use in a public root program. Unfortunately Program Requirements - Microsoft Trusted Root Program | Microsoft Docs only lists the EKUs but does not explain what requirements they have for each.
Thanks a lot for all the answers. I was in a contact with MS support and they pointed out that.
According to above details either team who is managing ISRG Root X1 CA provide certificate which only include Server Authentication only without including Client Authentication or same team didn’t fulfill program requirement for example EKU Requirements.
It seems like that including client auth requirement in the request is solely in Letsencrypt hands. I saw that @josh was responsible for filing this at Mozilla, so maybe he was involved in filing the CA inclusion request at Microsoft also. Who can I talk to if we would like to allow ISRG Root X1 to be enabled for client authentication at Microsoft? We need this to be able to use Letsencrypt certificates for mutual TLS.
