fedmest
fedmest

Reputation: 719

Apache 2, SSL, and Client Certificates

I have set up a number of Virtual Hosts all using SSL. Everything worked fine. Then I needed to add SSL Client Authentication to one of them (let's call it the SVN host). After enabling client certificates for the SVN host, the host stopped working, instead the default virtual host would be used instead (which means that an un-matching server certificate would be provided, so that neither access to the secure host, nor client authentication would work).

Here's the virtual host configuration I'm using:

<VirtualHost *:443>

ServerName  svn.anydomain.com

SSLEngine on
SSLOptions +StrictRequire
SSLProtocol -all +TLSv1
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!SSLv3:RC4+RSA:+HIGH:+MEDIUM

SSLCertificateFile /etc/certs/svn.crt
SSLCertificateKeyFile /etc/certs/svn.key
SSLCertificateChainFile /etc/certs/starcom/sub.class1.server.ca.pem
SSLCACertificateFile /etc/certs/cacert.crt
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

SSLVerifyClient require
SSLVerifyDepth 2
SSLUserName SSL_CLIENT_S_DN_CN

<Location /path0>
    DAV svn
    SSLRequireSSL
    SVNPath /var/svn/path0
    #Require valid-user
</Location>

<Location /path1>
    DAV svn
    SSLRequireSSL
    SVNPath /var/svn/path1
    #Require valid-user
</Location>

</VirtualHost>

Also, I seem to have this problem on Mac OS X only. I am able to access the host from Windows 8 with no sweat. Basically, on my Mac I can get it to work only with these options in curl (sometimes, not consistently)

curl -v -v -v -1 -k --cacert Documents/Certs/CACert.pem --cert Documents/Certs/ClientCert.pem  https://svn.anydomain.com/path1

This instead fails (note the -3 instead of -1 for SSLv3 instead of TLSv1)

curl -v -v -v -3 -k --cacert Documents/Certs/CACert.pem --cert Documents/Certs/ClientCert.pem  https://svn.anydomain.com/path1

and returns the certificate of the default virtual host. This behaviour (wrong virtual host) is what I get for any access to that domain on my Mac (Safari, Eclipse+Subversive, Cornerstone, etc).

Any ideas?

Upvotes: 2

Views: 2079

Answers (2)

bcarroll
bcarroll

Reputation: 1818

Have you turned up the log level in httpd.conf? Try running with debug messages enabled and tail -f the error_log to see if anything interesting shows up.

A common problem with SSL client authentication is the SSLVerifyDepth parameter. The SSLVerifyDepth number needs to be at least as big as the number of certificates in the client certificate's chain.
Example: SSLVerifyDepth 10

The depth actually is the maximum number of intermediate certificate issuers, i.e. the number of CA certificates which are max allowed to be followed while verifying the client certificate. A depth of 0 means that self-signed client certificates are accepted only, the default depth of 1 means the client certificate can be self-signed or has to be signed by a CA which is directly known to the server (i.e. the CA's certificate is under SSLCACertificatePath), etc.

http://www.modssl.org/docs/2.6/ssl_reference.html

Upvotes: 1

nickrak
nickrak

Reputation: 1635

In your apache config file make sure you've added:

NameVirtualHost *:443

See http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Make sure that NameVirtualHost goes before any <VirtualHost ...> that uses that ip and port. If you forget/misplace the NameVirtualHost line or the browser does not support SNI, Apache will choose the first available vHost.

Upvotes: 1

Related Questions