Reputation: 719
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
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
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