Configuring client certificate authentication in apache

apache-2.2authenticationcertificatecertificate-authorityssl-certificate

I am trying to set up part of a Virtualhost in apache to require client authentication. The VirtualHost in question also acts as a reverse proxy for the actual web server. Here's what I have done:

  • Created ca.crt, ca.csr, and ca.key on the server I am using as the CA.
  • Modified the config of the VirtualHost to look like this:

…

ProxyPass / http://xxx.xxx.xxx.xxx:80/
ProxyPassReverse / http://xxx.xxx.xxx.xxx:80/
ProxyPassReverseCookiePath / /

SSLEngine On
SSLCertificateFile "/private/etc/apache2/server.crt"
SSLCertificateKeyFile "/private/etc/apache2/server.key"
SSLCertificateChainFile "/private/etc/apache2/ca_bundle.crt"
SSLCACertificateFile "/private/etc/apache2/self_ca.crt"
SSLVerifyClient none
SSLOptions StrictRequire   
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Location /clientauth>
    # These options force the client to authenticate with a client certificate.
    SSLVerifyClient require
    SSLVerifyDepth 1
</Location>
  • Created a test client certificate using my custom CA.
  • Installed the client certificate in to the login keychain on Mac OS X Lion, and manually into Firefox.

But I am unable to browse to the /clientauth path.

  • Firefox says "SSL peer was unable to negotiate an acceptable set of security parameters."
  • Opera says "Secure connection: fatal error (40) from server."
  • Chrome and Safari say "HTTP 403 Forbidden".
  • cURL (using the .p12 file) for some reason cannot find the key…
  • cURL (using the .crt and .key files) does the handshake, sends the request and then says "Empty reply from server".
  • The apache error logs keep repeating the line Re-negotiation handshake failed: Not accepted by client!?

Is this a conflict between using client authentication and being a reverse proxy? Or have I done something else wrong?

Best Answer

The underlying problem here is the renegotiation refusal. This stems from activity over the last year or two to fix a TLS vulnerability, and there were various interim fixes of refusing to renegotiate until a new TLS extension was implemented. So one thing you need to do is ensure your SSL (OpenSSL) and possibly therefore your Apache HTTPD as well is/are as up to date as possible.

Related Topic