I'm migrating an application from httpd 2.2 to httpd 2.4, and the way client authentication is configured for httpd 2.2 will not work for httpd 2.4 . The application serves static files to thousands of different clients, each with their own self signed certificates.
For httpd 2.2, set up was done as described in this post:
where the SSLVerifyClient directive is 'require' and the SSLCADNRequestFile directive points to an empty file (or the SSLCADNRequestPath points to an empty directory). This works for httpd 2.2 provided the client certificates are in the directory pointed to SSLCACertificatePath directive.
When this same configuration is used for httpd 2.4, the service will not even start, but exits after the output of the following message to the log file:
AH01896: Unable to determine list of acceptable CA certificates for client authentication
The only way I could get httpd 2.4 client authentication to work is when all the self signed client certificates are also located in SSLCADNRequestPath . From what I've read this may send to the client a huge list of acceptable CAs in the TLS handshake, which is wasteful and unnecessary, especially since each of the thousands of client certs are self signed. If we have the client cert installed for httpd 2.4, then we want to accept it provided other checks pass (start and stop dates, etc). Moreover, installing huge numbers of client certificates in trust stores is probably not feasible, as noted in the first comment in this post:
I reviewed the different settings for SSLVerifyClient in the documentation, and none fit exactly what is needed, which is better described as require_no_ca, meaning a client cert is required and must be validated, but does not need to be signed by a separate CA.
For httpd 2.4, how can I get the equivalent of the httpd 2.2 configuration that does not need all the client certs also stored as CA certs, and thus avoiding a huge list of CA names in the TLS handshake?
