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.
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:
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.
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...
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]
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.
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.
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.
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.
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?
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).