Re: Wildcard certificate and DANE/TLSA records
On 12/31/18 2:21 PM, Viktor Dukhovni wrote:
On Dec 31, 2018, at 2:01 PM, zorion zorion@autistici.org wrote:
Ok, I had a hard time finding out what exactly the *trust-anchor* was supposed to be. I took a guess that it was the combined cert chain, but obviously that is not it.
A trust-anchor is any issuing CA you designate as trusted, and it does not have to be a root CA, it can also be any intermediate CA.
Thank you for the explanation!
What exactly is the trust-anchor? Is it the top level cert from the CA in the chain (#4 in your danecheck below)?
It is any of 2, 3 or 4. The important constraint with DANE-TA(2), as explained in https://tools.ietf.org/html/rfc7671#section-5.2.2, is that if you do choose a root CA as your trust-anchor, unlike the case in non-DANE PKIX protocols, it MUST be sent to the client along with the intermediate issuer certificates.
Would that be the smtp_tls_CAfile option in postfix? I've got an intermediate bundle that I provide to that option in main.cf
To compute the digest of a CA certificate, create a PEM file containing just that certificate. Or use my "chaingen" script (attached), which can process a complete chain of certificates, but DO NOT then publish all the TLSA records it outputs. Publish no more than one TLSA record per certificate in the chain, typically just the "3 1 1" for the EE cert, and "2 1 1" for the TA certs. And no need to match at every level. At most two trust anchors (typically just one) are enough.
Thanks! Is there a benefit for also publishing the "2 1 1" TA certs if I'm already publishing the "3 1 1" EE cert?
ps. accidentally only sent this directly to Viktor, sending it to the list.
On Mon, Dec 31, 2018 at 05:33:16PM -0500, zorion wrote:
The important constraint with DANE-TA(2), as explained in https://tools.ietf.org/html/rfc7671#section-5.2.2, is that if you do choose a root CA as your trust-anchor, unlike the case in non-DANE PKIX protocols, it MUST be sent to the client along with the intermediate issuer certificates.
Would that be the smtp_tls_CAfile option in postfix? I've got an intermediate bundle that I provide to that option in main.cf
No, you just put all the requisite certificates along with the private key in a mode 0600, root-owned smtpd_tls_cert_file. The server certificate first, then its issuer CA, then any parent issuer CA, ... up to possibly the root CA, if that's the DANE trust-anchor matching the TLSA record. If the "2 1 1" TLSA record is for an intermediate CA, then the root CA can be left out, but still list any intermediates above that, for non-DANE clients.
Thanks! Is there a benefit for also publishing the "2 1 1" TA certs if I'm already publishing the "3 1 1" EE cert?
Yes, it can simplify rollover and make your deployment less likely to fail, provided you only make changes that affect one of the values at a time. See the slides from my various talks.
That said, I recommend the "3 1 1 + 3 1 1" approach as more secure. Whatever you do, have monitoring in place and avoid key rollover processes that temporarily leave your server with TLSA records that don't match its cert chain, keeping in mind remote DNS caches.
Also don't forget to bump the SOA when chaning DNS records, otherwise secondary servers may keep serving stale data. For example, the below domains only provide the right TLSA record 2/3 of the time:
mtexx.email. IN MX 10 mx1.mtexx.email. niklas.pro. IN MX 10 mx1.mtexx.email.
; Correct @ns1.totaldns.de.[212.224.81.8] @ns3.totaldns.be.[93.190.68.228] _25._tcp.mx1.mtexx.email. TLSA 3 1 2 1FDBE5993E99EFAB8B7DF0EF254AF72FA512697787EEA622591000141F8B9836154D600812B306C842524F6B5B747D024A3EBA8337C71538C158AAD4BCDDDCFA
; Stale @ns2.totaldns.eu.[78.47.63.220] _25._tcp.mx1.mtexx.email. TLSA 3 1 1 21DF011460CF75244534EC7E04F7EFB2A980106C7B44EE0997FC5F86A23D7DD1
Which can result in stochastic email delays. At least the TTL is only 5 minutes, so given enough retries the mail will likely get through...
participants (2)
-
Viktor Dukhovni
-
zorion