> zOS does, for example, at least if you're using the RACF security provider. Ha! Spoken like a Micro Focus guy! One of the most likely clients for this server is in fact implemented on z/OS. Just FYI, the key variable is not so much RACF: (a.) RACF is just (in this case) a certificate store, not a TLS implementation; and (b.) I think the other two ESM's (CA TSS and ACF2) are 99% equivalent in their certificate facilities. The TLS implementation is named System SSL (sometimes known as GSK). That is the TLS library, roughly parallel to OpenSSL. (In fact I don't know of any other TLS implementation on z/OS other than the OpenSSL port -- but there could be some.) GSK also implements its own certificate store, but I don't think it is widely used in production. Yes, there would be lots of certificates in the certificate store, but at least in the case of the client I wrote, you configure it in advance to use a particular named certificate, so the server application itself does not have any choice at run time. It is "one certificate, take it or leave it." Thanks for the heads-up on Windows. I develop for both platforms, but I am much less familiar with all of the ins and outs of Windows. OCSP and OCSP stapling are currently higher on my wish list than this. Charles -----Original Message----- From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of Michael Wojcik Sent: Monday, December 3, 2018 10:58 AM To: openssl-users@xxxxxxxxxxx Subject: Re: Question on necessity of SSL_CTX_set_client_CA_list > 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
