EKU of Root Certificate

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

I know I've seen it before... where LE specifically listed the OIDs covered by their DV cert.
But they have blocked by Google-FOO today and I can't seem to find anything with OID on any LE site.
Maybe someone can dig deeper/better...

2 Likes

That's the CA root list from a different discussion thread :slight_smile: Will the root ca certificate expiring affect my iot device connected to a server - #4 by rohith999 - I got them mixed up as well.

1 Like

I guess the chicken-egg problem is that they can't insert anything into the managed devices...
They can only work with what is already there (and now very outdated).
So how can anything be added into such an old system?
Only one FREE way that I can think of: Get cross-signed by any of the roots in the oldest list.
OR (until another solution is found)
Problematic clients must pay for certs from any of the roots listed in those old lists.
[it's not the end of the world (as we know it) - it's just the end of the FREE world... - LOL]

1 Like

Well, the CPS (which as I understand it is the "official" document describing what one can rely on a Let's Encrypt certificate to mean) says that subscriber certificates have extended key usage "TLS Client Authentication". (And of course, the certificates in fact do have it.) So it's not some accident that this EKU is enabled; it's an intentional choice on Let's Encrypt's part. (And I don't see a reason why one wouldn't want that EKU to be on the certificates.)

It's not explicitly mentioning client authentication, but that you can use them beyond just "web serving" is kinda mentioned in the FAQ, that "you can use them for any server that uses a domain name, like web servers, mail servers, FTP servers, and many more." I think usage of mutual TLS is more common with, say, mail servers than with web servers, but you can use it with any TLS and it can be pretty handy to ensure that your client is the system that you think it is.

I believe Client Auth works fine with like, the out-of-the-box Oracle Java trust store, if you were writing an application in Java. It's just that if you're writing an application on the Microsoft platform, their trust store doesn't say to trust ISRG's Roots for Client Auth, but it's not (yet) clear why. And since until relatively recently most people used a chain up to DST Root CA X3, which is trusted for Client Auth (among other things) by Microsoft, this is a change as part of the "standing on our own two feet" move to using Let's Encrypt's own roots that's causing trouble for at least a couple users.

3 Likes

It does seem like this usage makes good sense, is secure, and within the goals of ISRG. So I certainly hope that it's possible for Microsoft to change this in their systems.

If they choose not to, I'd also want to understand their reasoning, it may be that Microsoft sees "client certificate" as necessarily being about human identity, which Let's Encrypt is not equipped to verify, but as in this example and in systems I've built, it's common to need to identify machines which have DNS names and are thus ideally suited to ACME today.

3 Likes

When we were in touch with Microsoft support regarding this issue (see Certificates signed by ISRG Root X1 aren't enabled for client authentication on Windows - #9 by peterb), they made it sound like the submission for the root CA that was filed by Let's Encrypt simply did not include the clientAuth EKU (and it needs to be explicitly stated in the submission for it to be included in their trust store).

3 Likes

@aarongable, it seems clear that someone within the LE staff would be required to address this issue directly with Microsoft.

  • Has that person been identified?
  • Have they been informed of this need?

[I don't need to know whom it is, I just want to be sure that it is being, or will be, handled]

3 Likes

Hi @rg305,

Aaron is triaging this internally and will give an update when he has one.

Thanks so much for your thoughts on this thread!

Best,
JP

6 Likes

Update: we've taken some action, and hope to see a resolution to this issue within 30-60 days. We'll provide another update within the next 30 days. Apologies that we can't say more at this time.

10 Likes

While doing some testing regarding lazy loading of ISRG Root X2 in Windows, I realized that my local Windows trust store now has the Client Authentication EKU enabled for both roots.

Thank you for taking care of this!

6 Likes

Hmm. The report at https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT still only shows the ISRG Roots as being for Server Authentication, but maybe it's a cached copy that takes some time to update?
I can confirm that on the computer I'm on at least (running Windows 10 Home 21H1) the ISRG Root X1 that's in my Local Computer Trusted Root Certification Authorities says both Client Authentication and Server Authentication now, though. I don't see ISRG Root X2 in my list, even after visiting https://valid-isrgrootx2.letsencrypt.org/ in Edge, but it may just be caching the X2-signed-by-X1 cert from elsewhere and so never needed to look it up?

3 Likes

I have doubts that this is really always up to date (this might not even be machine generated, but maintained in some Excel file at Microsoft...). Anyway, the 'actual' source of truth (the authoritative root file hosted on Microsoft servers, here) contains the Client Auth EKU for both certificates (I used this to parse the trust store file).

I've written a likely explanation here: Microsoft Windows Root Certificate Lazy-Loading - #5 by Nummer378

5 Likes