Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 /
ProxyPassReverse /
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

<Location /clientauth>
    # These options force the client to authenticate with a client certificate.
    SSLVerifyClient require
    SSLVerifyDepth 1
  • 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?

share|improve this question
up vote 5 down vote accepted

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.

share|improve this answer
Turns out the server had OpenSSL 0.9.8l, the version in which they disabled renegotiation altogether. Updating should fix this, thanks. – DanielGibbs Jul 27 '12 at 22:56
@DanielGibbs, did upgrading OpenSSL fix your issue? To what version did you upgrade? – Kevin Meredith May 21 '13 at 16:19
Hi Kevin, I did end up fixing this issue by upgrading both Apache and OpenSSL to (I think) the latest versions as of when this question was asked. I'll have a look when I get to work and I'll get back to you. – DanielGibbs May 21 '13 at 20:03
Apache is version 2.4.2 and OpenSSL is 0.9.8r (Feb 2011, not that recent afterall). – DanielGibbs May 21 '13 at 21:14

The HTTP client only sends the HTTP request once the SSL session has been negotiated, which means that the server only knows the URL requested by the client once SSL has been setup. Since you are changing the value of SSLVerifyClient based on the URL, Apache cannot request the client certificate when the SSL session is first negotiated, and instead has to force a renegotiation of the session once it knows the URL. It seems that the problem lies with this renegotiation, and so I suggest that you test it without this by setting SSLVerifyClient require in the VirtualHost block and removing it from the Location block.

share|improve this answer
Ah, that makes sense. Then how would I configure it so that only a path actually requires the client to have a valid certificate? – DanielGibbs Jul 26 '12 at 1:02
@DanielGibbs The way you've done it is perfectly correct but it relies on the renegotiation being agreed to by the client: see my answer. – EJP Jul 26 '12 at 7:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.