[openssl-users] Question on necessity of SSL_CTX_set_client_CA_list

[Charles Mills]

> 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 at openssl.org] On Behalf Of
Michael Wojcik
Sent: Monday, December 3, 2018 10:58 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Question on necessity of
SSL_CTX_set_client_CA_list

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] 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