Re: [exim-dev] [exim] Next Exim release

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Viktor Dukhovni
Date:  
À: exim-dev
Sujet: Re: [exim-dev] [exim] Next Exim release
On Mon, Dec 14, 2015 at 07:37:54PM +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", the valid TLSA records for that
chain are:

    ; Depth 0, subject= CN = server1.example.com
    3 0 1 9f543e9337a8ef9d670d245e188bac9a9f75619a4b11307cb915677f2ec9fda9
    3 1 1 16f02c566f0154d8866cdfe62f71f8f596213f54d7759064c6800526d88b9c54
    3 0 2 e249af2dd469cddb7a56348502b5f217341c00b030ed6c7222fea22ca86ccdc4a5f3baef8b4882a0056ed4b09dbcbbc974fae041f6d9f57bd478c1f380a6eea7
    3 1 2 e8c8684c50360b661ea20fa66b4e1520f7469832f1d2e380a0e7320d0ba00efc0c5a37a9da08df8cf894c2473ff2ba907f785e3ac23665af073d616276a1b24a


    ; Depth 1, subject= O = example.com, CN = clica Signing Cert
    2 0 1 b844341b5f370b3c4d1d327d87266ed81c2a594e5cf777143406b62abe5161f4
    2 1 1 3276355715f866cda0ed33f5ff14147626bb1a361ba7b06f1b243df23575be40
    2 0 2 955f15e63bba155ca5997e72d61df8c839332d0b841559a943db29fcb8bdc4b9560c03d369a442c22c9d0b42f9a3b2bb1dd29b4f267af1a2ed94d9e7aeae1ed5
    2 1 2 037be3ca5698dd81fe21b08487e62e6be67a3332a4b17a2726a3dc58e1fc84d3242045e12594aa9999b887281d2e8317a35b425e71c4e3285a6d9604b1b4ed13


    ; Depth 2, subject= O = example.com, CN = clica CA
    2 0 1 72f0326cc46e7e49d002b44cfce53f0f4b54a765944f9fa6f4d8f2e510478829
    2 1 1 b2c6f27f2d16390b4f71cacc69742bf610d750534fab240516c0f2deb4042ad4
    2 0 2 738750d9b3a7c815cb9215b664f9010181d9c989ef67e107e069f42eee800d412e2593ed9a67ae8024aa09e7a17cca20a164d359190ae9a2d0739aa3bc8d8a5f
    2 1 2 eae361f1b6997b89a72229550f9b205a77de36b6c3cc335c502eff9f5e3bcd916619b782b3532370d4ac8d30144091ed09760f941bc7188b5eb6ebae1c439b55


And the digest in question is a "2 1 1" public key digest, not a
"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 1 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.

-- 
    Viktor.