On Sat, 31 Oct 1998 16:25:34 +0100, you wrote:
>
>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?
I'm for, I've encountered the exact same problem, it's just not
logical.
> 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]
>
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
