TLSv12 Client Certificate Selection Behavior !!

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Viktor Dukhovni
> Sent: Tuesday, June 11, 2019 10:39

> A client certificate that cannot do digital signatures is not much use.

There may be existing applications which use TLS entirely within an organization, where the server does not check KU, and the peers use certificates generated by an internal CA that doesn't set those extensions properly. In that use case, enforcing the KU requirement would break backward compatibility.

Maybe that's not worth worrying about; maybe the advantages of enforcing KU on the client certificate at the client end (better diagnostics for the client application, enforce the standard even if the server doesn't) outweigh it. But I don't think it's entirely accurate to say a client certificate with incorrect/missing KU (or EKU, or other extensions) is necessarily useless.

To be honest I don't have a strong feeling about this particular suggestion. If OpenSSL started requiring proper KU on client certificates, and that forced some people to fix their internal CA configurations, that's arguably a good thing; such people may well be using too-small keys and outdated algorithms too. Disruption can definitely be good in this area. Just wanted to point out that it might be possible to rely on the existing behavior.

And, of course, there are no doubt still people out there running internal CAs that generate X.509v1 certs, which won't have any extensions at all. No KU, no EKU, no SAN, no SKID/AKID ... Presumably a check for proper KU on the client certificate would be bypassed if the client cert is v1 - but then using a v1 certificate is another violation of RFC 5246 (7.4.2) that OpenSSL probably should not enforce.

--
Michael Wojcik
Distinguished Engineer, Micro Focus