Wildcard certificate and DANE/TLSA records

Viktor Dukhovni ietf-dane at dukhovni.org
Mon Dec 31 19:51:33 CET 2018


On Mon, Dec 31, 2018 at 12:52:38PM -0500, zorion wrote:

> I'm working with a wildcard certificate[0] for a domain that I'm trying
> to add dane/tlsa records.

[side comment]
    I don't recommend these.  They often lead to single-point of failure
    problems, as the certificate tends to be replaced at the same time
    across all MX hosts, and if there's a problem they all fail.

    If you have just one MX host, you don't need a wildcard certificate,
    if you have many, you gain a single point of failure.  Better to
    have a separate certificate for each MX host.
[/side comment]

> [...] but when I try to test
> that with one of the testers online, they fail to verify it, I think
> because there is no specific match to the name.

No.  That's not the problem.

> For example, I made these records using the certificate chain for the
> input to danetool:
> 
> danetool --tlsa-rr --host mx1.riseup.net --load-certificate
> ./wildcard_server_chain.pem --app-proto=smtp --ca --x509

You're using the *end-entity* certificate to compute a digest that
you then advertise as a digest of the *trust-anchor* issing CA.
Naturally, these fail to match.

Here's what "danecheck" has to report (the "-->>" arrows are added
by me):

    riseup.net. IN MX 10 mx1.riseup.net. ; AD=1 NoError
    mx1.riseup.net. IN A 198.252.153.129 ; AD=1 NoError
    mx1.riseup.net. IN AAAA ? ; AD=1 NODATA
    _25._tcp.mx1.riseup.net. IN CNAME tlsa._mxdane.riseup.net. ; AD=1 NoError
    tlsa._mxdane.riseup.net. IN TLSA 2 0 1 3814e3eaf91e30451790697a98b1b5594cdbdfef4a73ef5a47ed33c556816645 ; AD=1 NoError
      mx1.riseup.net[198.252.153.129]: tlsa-mismatch
        TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384
        name = *.riseup.net
        name = riseup.net
        depth = 0
          Issuer CommonName = COMODO RSA Domain Validation Secure Server CA
          Issuer Organization = COMODO CA Limited
          notBefore = 2018-10-15T00:00:00Z
          notAfter = 2019-10-15T23:59:59Z
          Subject CommonName = *.riseup.net
1-->>     cert sha256 [nomatch] <- 3 0 1 3814e3eaf91e30451790697a98b1b5594cdbdfef4a73ef5a47ed33c556816645
          pkey sha256 [nomatch] <- 3 1 1 ff62cc1ec0a038b0eeebc323924be6caed3b3d56edcc9bfb943c1f2d09cdfb77
        depth = 1
          Issuer CommonName = COMODO RSA Certification Authority
          Issuer Organization = COMODO CA Limited
          notBefore = 2014-02-12T00:00:00Z
          notAfter = 2029-02-11T23:59:59Z
          Subject CommonName = COMODO RSA Domain Validation Secure Server CA
          Subject Organization = COMODO CA Limited
2-->>     cert sha256 [nomatch] <- 2 0 1 02ab57e4e67a0cb48dd2ff34830e8ac40f4476fb08ca6be3f5cd846f646840f0
          pkey sha256 [nomatch] <- 2 1 1 9253b6de74f67a11435c27f1dde1d30d1112333ddab23d66b8efb86887638ae6
        depth = 2
          Issuer CommonName = AddTrust External CA Root
          Issuer Organization = AddTrust AB
          notBefore = 2000-05-30T10:48:38Z
          notAfter = 2020-05-30T10:48:38Z
          Subject CommonName = COMODO RSA Certification Authority
          Subject Organization = COMODO CA Limited
3-->>     cert sha256 [nomatch] <- 2 0 1 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
          pkey sha256 [nomatch] <- 2 1 1 82b5f84daf47a59c7ab521e4982aefa40a53406a3aec26039efa6b2e0e7244c1
        depth = 3
          Issuer CommonName = AddTrust External CA Root
          Issuer Organization = AddTrust AB
          notBefore = 2000-05-30T10:48:38Z
          notAfter = 2020-05-30T10:48:38Z
          Subject CommonName = AddTrust External CA Root
          Subject Organization = AddTrust AB
4-->>     cert sha256 [nomatch] <- 2 0 1 687fa451382278fff0c8b11f8d43d576671c6eb2bceab413fb83d965d06d2ff2
          pkey sha256 [nomatch] <- 2 1 1 942a6916a6e4ae527711c5450247a2a74fb8e156a8254ca66e739a11493bb445

In potential match 1 the digest matches, but the usage is "3 0 1",
and your TLSA record is "2 0 1", so no go.  In 2, 3 and 4, the
digests don't match.

> ..., or generate the hash over the wrong
> pieces?

Yes.

> 0. yes, I am aware of why wildcards are discouraged, but this is what I
> have to work with here.

Yes, with care they can be made to work.

-- 
	Viktor.


More information about the dane-users mailing list