On Thu, Apr 02, 2026 at 01:20:04PM +0000, Peter Gutmann wrote: > Nico Williams <[email protected]> writes: > >Typically applications that support client certificates will have a list of > >client _names_ that are allowed to access the service, or some other form of > >authorization ultimately keyed by the client's authenticated name. > > This is how rationally-written applications do things [*]. The problem is > that, particularly under Windows, it's very easy to get drawn into trusting > everything Windows trusts, which means in effect any cert issued by any public > CA anywhere. The example I like to give for this is a developer who > inadvertently got access to USG systems with a GoDaddy cert they'd bought for > testing, because what was at the other end trusted anything from a CA that > Windows trusted. I only know of the final end effect but I'm pretty sure the > systems weren't originally set up to allow this, they just ended up in that > state at some point.
Recall that we're talking about constraining client certificate use here to just dNSName SAN certificates. Since KB5014754 at least the mapping of those to machine accounts from Active Directory should not be trivial to spoof by WebPKI CAs anymore. However, as we know it takes the USG ages to upgrade and patch all their Windows installations, so... ok, thanks -- I buy this. I now support standardizing the survey's outcome, which is EKR's proposal. Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
