We have a PR (#35) where the user is confused by the interpretation of the
SSLVerifyDepth argument. He wants to only accept a cert which has to be
directly signed by the to be known CA certificate, i.e. he wants to not allow
intermediate CA certs. He intuitively thought SSLVerifyDepth 0 or
SSLVerifyDepth 1 makes this happen. But he need SSLVerifyDepth 2.

The depth is counted as this:

| depth 0: the client certificate
| depth 1: the issuer certificate
| depth 2: the issuer's issuer certificate
|    :

And the depth check is done via

| if (depth >= SSLVerifyDepth) error...

So it's clear that SSLVerifyDepth 2 is needed, because only this way the
client and isser certs are accepted. This handling is the handling inherited
from Apache-SSL without change of semantics, of course.

But OTOH the user is right: 2 is totally intuitive. 0 or 1 can be acceptable
and intuitive when clearly documented. But 2 is unintuitive. So what's your
opinion?

My opinion is that the depth counting is ok startinbg from 0 and intuitive.
But the check should be

| if (depth > SSLVerifyDepth) error...

because this way 

  SSLVerifyDepth 0 ... a self-signed client cert only is allowed
  SSLVerifyDepth 1 ... client cert can be signed by a CA, 
                       but this has to be the root CA.
  SSLVerifyDepth 2 ... client cert can be signed by a CA which itself can be
                       signed by a second CA.
  etc.

This way the intuition is that the argument of SSLVerifyDepth specifies the
steps mod_ssl goes maximal down (to the CA certs) to verify a client cert.

BTW, what about the CA flag in X.509 V3 certs? Wouldn't it be useful
     to provide another SSLVerifyCA or whatever directive which can be used to
     make sure the CA certs are really marked as CA certs.  And additionally
     we could check the pathlen of X.509 V3 certs.  Opinions and ideas how we
     should allow this to be configured (directives, arguments, etc.)?

Votes for the ">=" to ">" change and to document the depth calculation this
way?
                                       Ralf S. Engelschall
                                       [EMAIL PROTECTED]
                                       www.engelschall.com
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl)   www.engelschall.com/sw/mod_ssl/
Official Support Mailing List               [EMAIL PROTECTED]
Automated List Manager                       [EMAIL PROTECTED]

Reply via email to