After some research I got the idea that I can't use SSLVerifyClient successfully anywhere except within a server context because of current CVE-2009-3555 mitigation efforts.
Specifically, because of CVE-2009-3555, various versions of OpenSSL, Apache/mod_ssl and some browsers stopped allowing SSL renegotiation. So SSLVerifyClient require in a Directory, Location or .htaccess context causes service to fail (e.g. various of these examples fail). Since CVE-2009-3555, RFC 5746 was published, which newer versions of OpenSSL, Apache/mod_ssl etc. support.
Q1: Is this summary approximately correct?
My problem immediate is with shared web hosting. I've no access to httpd.conf and no way to upgrade the software.
Q2: If I find a shared web hosting company running recent software that supports RFC 5746 TLS Renegotiation Indication (unlike GoDaddy) will I have any success putting into .htaccess:
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /path/to/my/ca.crt
where ca.crt is my bastard self-signed CA cert?
mod_ssl docs don't say SSLCACertificateFile can go in a .htaccess but I don't get the typical "Not allowed here" error when I put it there.
Best Answer
Q1: Yeah, correct.
Q2: No, I don't think it'll work.
Config-wise, is there any reason
SSLCACertificateFilecouldn't go in a broader config section like aVirtualHostblock?But, that aside, client certificates are probably a lost cause on this system, assuming that GoDaddy has actually patched to disable renegotiation (with them, I won't assume). I don't know of any way around the requirement that client certificate authentication requires a renegotiation.