> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf > Of Charles Mills > Sent: Monday, December 03, 2018 10:55 > > Got it. Thanks. I would think the basic client case is "one certificate, one CA" I'm going to disagree somewhat with this assumption, but not necessarily with your decision. That assumption is probably safe for some use cases, but not all. For example, Windows-based clients that use Microsoft's TLS implementation (SChannel, via CAPI or CNG or any of the various wrapper APIs, including the .NET Framework) have access to all the "personal" certificates in the Windows per-machine and per-user certificate stores. In a Windows domain environment, certificates may be added to those stores by central administration, as well as being created or added locally. So such clients could have quite a few client certificates available to them. Some other TLS implementations can optionally use the Windows certificate stores. I believe Netscape's NSS can be configured to do so, for example. A suitable JSSE provider is included with the standard Windows JRE and JDK distributions. And OpenSSL itself has a CAPI engine that can (probably) be used to pull client certificates from the Windows stores. (I say "probably" because when we went to use the OpenSSL CAPI engine some years ago, we ran into some issues caused by Microsoft's awkward provider mechanism and how it interacts with private-key storage, and I ended up enhancing the OpenSSL CAPI module in various ways. So I don't recall what exactly works with it out of the box.) There are other environments which similarly provide centralized storage of certificates (and corresponding private keys) to all clients. zOS does, for example, at least if you're using the RACF security provider. Perhaps more importantly, as Viktor noted, some clients won't send a certificate at all unless they have one signed by a CA on the server's list, or at least only if the server sends a non-empty list. The list is also useful for clients that want to help the user select from among a set of certificates. > so I think I will roll with what we have (especially since the product has been > out there for years with no reported problems in this area -- although I think > client certificate usage is rare) but keep the issue in mind if a problem comes > up. Despite what I wrote above, the important thing, of course, is what your users need. If they haven't needed a server that sends a CA list, there's a good chance they won't need one any time soon. Often there are better things to address first. TLS configuration is important, but certainly for the software projects I work on there are any number of important areas for further work. You can't do everything at once. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
