You might be interested in this question. However, this is very likely to introduce a security vulnerability unless you really understand what you're doing.
There are two problems with this:
SSLVerifyCLient optional_no_ca
will let any client certificate through. The only thing you'll know for sure is that the client has the private key matching the public key in the certificate they present (the certificate might also need to be currently valid in date and have the TLS client key usage, I can't remember).Pointing
SSLCADNRequestFile
to an empty (or just a line-return) file will also make the server advertise an empty list of CAs to its clients. Note that this is undocumented behaviour up to TLS 1.0 (but works in general) and authorised from TLS 1.1 onwards, but as "unspecified" behaviour.
The first point is a problem because you're not verifying the certificate at all within Apache Httpd. It can be OK if the application behind (which relies on authentication) does something as part of its authentication layer (to which you'd forward the client certificate chain in a trusted manner). It's definitely not OK for anything within the Apache Httpd layer itself: any restrictions within Httpd that would use expressions like SSL_CLIENT_S_DN
for example, or FakeBasicAuth
, simply cannot be relied on.
The second point can be a problem in terms of usability, since it may confuse a number of clients, in particular clients that have multiple certificate available and that normally perform an automatic choice depending on the CA advertised by the server.
More generally, a situation "tens of thousands of end-users" with such a variety of intermediate CAs seems unusual. In a traditional PKI model, the CAs you configure are you trust anchors: they're there for a reason, and you trust them. It should really be up to the client to present the required intermediate certificate (or up to the server to trust them and advertise them explicitly). While what you're trying to do may be technically possible, you'll need to take great care in the implementation. It's also not clear how well this would fit with various administrative standards and policies.