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.
- 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.