On Tue, Dec 15, 2015 at 07:04:49PM +0000, Jeremy Harris wrote:
> > 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]'
When I want non-leaf TLSA records, I use the attached chaingen
script, which produces all sensible (no full certs or keys) TLSA
records for a given chain.
;; subject= CN = server1.example.com
;; issuer= O = example.com, CN = clica Signing Cert
;; notBefore=Nov 1 12:34:05 2012 GMT
;; notAfter=Jan 1 12:34:05 2038 GMT
;;
_25._tcp.server1.example.com. IN TLSA 3 0 1 9F543E9337A8EF9D670D245E188BAC9A9F75619A4B11307CB915677F2EC9FDA9
_25._tcp.server1.example.com. IN TLSA 3 1 1 16F02C566F0154D8866CDFE62F71F8F596213F54D7759064C6800526D88B9C54
_25._tcp.server1.example.com. IN TLSA 3 0 2
E249AF2DD469CDDB7A56348502B5F217341C00B030ED6C7222FEA22CA86CCDC4A5F3BAEF8B4882A0056ED4B09DBCBBC974FAE041F6D9F57BD478C1F380A6EEA7
_25._tcp.server1.example.com. IN TLSA 3 1 2
E8C8684C50360B661EA20FA66B4E1520F7469832F1D2E380A0E7320D0BA00EFC0C5A37A9DA08DF8CF894C2473FF2BA907F785E3AC23665AF073D616276A1B24A
;; subject= O = example.com, CN = clica Signing Cert
;; issuer= O = example.com, CN = clica CA
;; notBefore=Nov 1 12:34:05 2012 GMT
;; notAfter=Jan 1 12:34:05 2038 GMT
;;
_25._tcp.server1.example.com. IN TLSA 2 0 1 B844341B5F370B3C4D1D327D87266ED81C2A594E5CF777143406B62ABE5161F4
_25._tcp.server1.example.com. IN TLSA 2 1 1 3276355715F866CDA0ED33F5FF14147626BB1A361BA7B06F1B243DF23575BE40
_25._tcp.server1.example.com. IN TLSA 2 0 2
955F15E63BBA155CA5997E72D61DF8C839332D0B841559A943DB29FCB8BDC4B9560C03D369A442C22C9D0B42F9A3B2BB1DD29B4F267AF1A2ED94D9E7AEAE1ED5
_25._tcp.server1.example.com. IN TLSA 2 1 2
037BE3CA5698DD81FE21B08487E62E6BE67A3332A4B17A2726A3DC58E1FC84D3242045E12594AA9999B887281D2E8317A35B425E71C4E3285A6D9604B1B4ED13
;; subject= O = example.com, CN = clica CA
;; issuer= O = example.com, CN = clica CA
;; notBefore=Nov 1 12:34:04 2012 GMT
;; notAfter=Jan 1 12:34:04 2038 GMT
;;
_25._tcp.server1.example.com. IN TLSA 2 0 1 72F0326CC46E7E49D002B44CFCE53F0F4B54A765944F9FA6F4D8F2E510478829
_25._tcp.server1.example.com. IN TLSA 2 1 1 B2C6F27F2D16390B4F71CACC69742BF610D750534FAB240516C0F2DEB4042AD4
_25._tcp.server1.example.com. IN TLSA 2 0 2
738750D9B3A7C815CB9215B664F9010181D9C989EF67E107E069F42EEE800D412E2593ED9A67AE8024AA09E7A17CCA20A164D359190AE9A2D0739AA3BC8D8A5F
_25._tcp.server1.example.com. IN TLSA 2 1 2
EAE361F1B6997B89A72229550F9B205A77DE36B6C3CC335C502EFF9F5E3BCD916619B782B3532370D4AC8D30144091ED09760F941BC7188B5EB6EBAE1C439B55
> Is this correct for a "2 0 1" for this chain?
> Is there some neater way to produce it?
See the attached "chaingen" script.
> 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).
That should not happen. When the "2 0 1" TLSA record matches the
root-CA, I get (in order):
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
> >> 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?
The code in question is the verify callback in "offline.c", which
I use to test DANE verification without having to connect to live
servers:
./offline 2 0 sha256 click.pem "" chain.pem server1.example.com
where "click.pem" is the (final) root CA cert, and chain.pem is
the full chain file.
> > 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.
Would that be the "ok" value?? The signature of verify callbacks is:
int verify_callback(int ok, X509_STORE_CTX *ctx)
{
}
You can call that formal parameter anything you want, including
"state". If that's not it, it may be best to send me a link to
the git blob and line number you want me to look at.
My output reports "ok" via "verify=", and X509_STORE_CTX_get_error()
via "err=" along with the depth and subject DN.
--
Viktor.
