On Mon, Dec 14, 2015 at 09:33:02PM +0000, Viktor Dukhovni wrote:
> "2 0 1" certificate digest. When I designate this as "2 1 1" the
> callbacks are:
>
> depth=2 verify=1 err=0 subject=/O=example.com/CN=clica CA
> depth=1 verify=1 err=0 subject=/O=example.com/CN=clica Signing Cert
> depth=0 verify=1 err=0 subject=/CN=server1.example.com
>
> When I call it "2 0 1" I get:
>
> depth=2 verify=0 err=19 subject=/O=example.com/CN=clica CA
> depth=0 verify=0 err=27 subject=/CN=server1.example.com
> depth=2 verify=1 err=27 subject=/O=example.com/CN=clica CA
> depth=1 verify=1 err=27 subject=/O=example.com/CN=clica Signing Cert
> depth=0 verify=1 err=27 subject=/CN=server1.example.com
>
> # define X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN 19
> # define X509_V_ERR_CERT_UNTRUSTED 27
>
> So this is a failure case, not a success case. The first two calls
> report early errors uncovered before walking the links in the chain,
> and the last three walk the chain looking for errors with signatures
> or expiration times. That's why you see depth=0 twice.
>
> What's not yet obvious is why there's a new error report at depth
> 0, before the chain walk begins. I'll see whether that's "my
> fault", or OpenSSL's.
I see what happens, the fisrt callback is from OpenSSL's own chain
building code that fails to find a WebPKI trust anchor and reports
the root CA as an unknown self-signed object in the chain.
The second callback is from my code, which finds that further more
there are no DANE trust anchors to validate the chain. Since the
first callback allowed the handshake to continue, and I don't have
any information about the earlier callback having taken place, I
signal that the certificate lacks any DANE-based trust. Otherwise,
it might pass based on WebPKI trust alone, but we're doing DANE.
So the callback is needed for now. Once DANE support is in OpenSSL
itself, it should be possible to avoid the duplication of bad news.
--
Viktor.
