Apache + mod_ssl intermediate CA auto discovery for X.509 client auth

Question

Is it possible (...patch, module, anything...) to configure an apache/mod_ssl webserver (any version) to automatically discover/download intermediate issuing CA certificates back to a pre-defined trust root CA?

We need to be able to provide TLS client authentication for tens of thousands of end-users with the potential for hundreds of intermediate issuing CA's to need to be trusted by the web server. We have access to Axway/Tumbleweed Server Validator to handle SCVP/OCSP/CRL validation of the certificates in the chain (revocation, OID policies, etc..), but in order for the Axway Server Validator plugin to be passed the client certificate, apache/mod_ssl must first authenticate/validate the client certificate and it's issuing chain against a pre-configured apache CA certificate database (text file with a concatenated list of PEM encoded CA certs or a directory containing the individual certificate files.

I would be fine with accepting any certificate regardless of whether apache knows about the issuing CA chain (because SCVP will validate the chain for me), but I can't find any information that indicates that is even possible.

I can manually (or via a script) create the CA cert bundle text file, but I am sure this would quickly become a very large file and would need to be scanned regularly to remove expired CA certificates and add newly issued certificates. Of course the issue with this approach is the webserver will need to be restarted when new CA certs are added to the bundle file/directory, and I the resultant file will potentially be several megabytes in size which can't be good for the webserver's performance.

Any help and/or ideas is much appreciated.

Answer 1

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:

1. 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).

2. 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.