On Tue, Dec 15, 2015 at 05:28:46PM +0000, Jeremy Harris wrote:
> >> ; full MX, sha256, TA-mode
> >> DNSSEC mxdane256ta MX 1 dane256ta
> >> DNSSEC dane256ta A HOSTIPV4
> >> DNSSEC _1225._tcp.dane256ta TLSA 2 0 1 b2c6f27f2d16390b4f71cacc69742bf610d750534fab240516c0f2deb4042ad4
> >
> > Are you sure that's a "2 0 1",
>
> It'll take me a while to reverse-engineer how it was produced, I expect.
The form "2 0 1" (i.e. DANE-TA(2) Cert(0) SHA2-256(1)) is not
correct for the given SHA2-256 hash (digest), which is a hash of
the public key of the root CA, not the full certificate.
So either this is a typo, or a deliberate test case that's expected
to fail to verify. The actual matching record would be "2 1 1".
> "digest" being what, here? I get lost around all these blobs of crypto.
digest == hash == SHA2-256 cryptographic checksum (in this case)
> > "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
That says match the public key digest, and it works.
> > When I call it "2 1 1" I get:
Sorry, typo, that should have been "2 0 1".
> > 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
>
> What is the difference between "call it" and "designate this"?
A typo, sorry.
> Where do you get those "verify=" and "err=" values from,
> and what is the "state" argument for that callback?
Those are respectively the "ok" argument to the verify callback,
and the value X509_STORE_CTX_get_error(store_ctx).
As for "state", I don't know what you're referring to.
--
Viktor.
