On 15/12/15 17:38, Viktor Dukhovni wrote:
> 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".
I think it's likely it was supposed to be a "2 0 1" and the hash
was wrongly produced. Using
openssl x509 -in aux-fixed/exim-ca/example.com/CA/CA.pem \
-fingerprint -sha256 -noout \
| awk -F= '{print $2}' | tr -d : | tr '[A-F]' '[a-f]'
I get
72f0326cc46e7e49d002b44cfce53f0f4b54a765944f9fa6f4d8f2e510478829
Is this correct for a "2 0 1" for this chain?
Is there some neater way to produce it?
With it I get one callback per chain element (though the
ordering is odd: 0, 2, 1. I'll need to check that for
ordering assumptions carried over from the non-dane coding).
>> 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,
Can't find that in code, sorry. Are we somewhere near here?
static int
verify_cert(X509_STORE_CTX *ctx, void *unused_ctx)
> and the value X509_STORE_CTX_get_error(store_ctx).
>
> As for "state", I don't know what you're referring to.
Sorry. First argument of my callback routine, which your layer calls.
--
Thanks,
Jeremy
