On September 5, 2012 16:32 , <John.E.Gregg@xxxxxxxxxxxxxx> wrote:
I’m starting to use SSLVerifyClient. I can’t find any documentation on exactly what it means to verify a client, however. By reading the source, I found that some of the work is delegated to OpenSSL and its behavior is somewhat documented here: _http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html_. When it says “signatures and issuer attributes are checked,” I assume it’s checking that the issuer is trusted and the cert is not expired. Do you know of anything else?
It might also check that the purpose for which the certificate is being used is one for which the signer of the certificate says that the certificate is allowed to be used. You might have better luck asking this question on one of the OpenSSL mailing lists.
Also, does Apache itself do anything besides this?
Not that I know of.
For example, is there anything that checks that the request is coming from the host identified in the cert? I assume there is but don’t see anything like that in the src.
No: client certificates are often signed for people (users), not for hosts. For example, the certificate I use has the subject
subject=/C=US/ST=Michigan/O=catseye dot org/CN=Mark Montague/emailAddress=mark@xxxxxxxxxxx/UID=markmont
...and when I authenticate to my web server using this certificate, I have httpd configured to populate the REMOTE_USER environment variable using the UID attribute of the validated certificate.
As you can see, the CN is not a hostname and does not get validated by httpd. You need to rely on the certificate authorities you trust in order to not sign certificates for "improper" CNs -- for example, the CN of a host that does not belong to the requester. And you need to trust the holder of the cert to keep their private key secure. If you cannot do these two things, you should not trust the CA in question, or you should not accept certificates at all.
Incidentally, you can't rely on the originating IP address of the request to validate the host identified in the certificate because the request may have passed through a firewall or network load balancer that implements NAT, or it may have been forwarded through a proxy. Also, determined attackers can spoof the originating IP address to make the request look legitimate even when it is not, so checking the IP address against the certificate host name doesn't provide strong security.
-- Mark Montague mark@xxxxxxxxxxx --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|