> On Jun 11, 2019, at 12:15 PM, Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx> wrote: > >> There's an overarching OpenSSL policy that certificate checks are >> done exclusively by the relying end (for client certs, that's the >> server), except when certified end is trying to choose from >> multiple certificates. >> >> Thus with only one certificate available, the OpenSSL sends the >> (untrusted, and in this case inappropriate) certificate, just in >> case the server was somehow configured to make a special exception >> for this particular case. > > Yes. I for one would argue this existing behavior (i.e. not enforcing every mandate of every applicable standard, at every step of the way) is the Right Thing to do. While it's good that OpenSSL is increasingly providing functionality to make it easier for applications to follow the RFCs and other standards, it's also very important that applications have the flexibility to violate some aspects of those standards. That is critical for interoperability with non-standard peers, as Jakob wrote, and for testing, among other things. That said, the intention isn't to ignore all the requirements, just some of those that are not always a good idea to enforce, and perhaps should never have been mandated in the first place. Therefore, while we leave enforcing the certificate signature algorithms to the peer, enforcing keyUsage in client certificate selection is less obviously counterproductive, and in fact can (as reported) avoid interop issues. The OP did not specify which version of OpenSSL did not perform the expected check. I'd be open to adding such a check in master and perhaps even 1.1.1 (as a bug fix). A client certificate that cannot do digital signatures is not much use. On the other hand, applications should not configure such certificates as client certificates, there is not context in which they are valid. So another potential response is: "if it hurts, don't do that!" -- Viktor.
