DNSSEC, TLSA and DANE

L

lordlex

Verified User
Joined
Aug 17, 2008
Messages
58
Location
Romania
Hi. This post is related to:

Version 1.50.1 | Directadmin Docs

DirectAdmin Knowledge Base
www.directadmin.com

The solution on this pages, opens a better way to have TLSA and DANE fully functional. Maybe someone at DA could update the help page, if they think my post here have enough arguments for that.

As many of you know, https://internet.nl/ provides a way to test a mail server (and also web server) and it's capabilities in regard to security and functionaliity. Two of the requirements are DNSSEC and DANE. As DA support all this, and DNSSEC is quite simple to implement, DANE support could be improved. For example, one optional, but highly recommended thing, is to have a rollover scheme for DANE. That means, you can provide an additional TLSA record to validate the connection when the main SSL certificate renew but DNS is not yet fully propagated. Also, the certificates at https://letsencrypt.org/certs/ will change over time as they expire (the X1 and X2 will expire on October 20 this year, and X3 and X4 will expire on March 17 of 2021) so, IMHO, it's not quite reliable to use them. Instead, the DA user data folder will contain an always up to date CA certificate, even when the user uses something else than Let's Encrypt (using ssl_save_post.sh file).

So, I modified the scripts on the help page to achieve and better implementation. It will setup TLSA for main domain certificate with rollover to the CA certificate, and will use the recommended scheme (3 1 1 for domain certificate and 2 1 1 for the CA). The letsencrypt_post.sh will also provide the DA account name (user) to the set_tlsa.sh script, so it can find the location of the certificates. The set_tlsa.sh can be also be manually used for existing domains with already valid SSL certificates not due for renew:

$ /usr/local/directadmin/scripts/custom/set_tlsa.sh DOMAIN.TLD USERNAME

Now, it would be really useful if DA could store in the user.conf file, or better the domain.tld.conf file, if the domain have DNSSEC active, as setting TLSA records without DNSSEC is quite useless from what I understand... With a dnssec=on on that file, we could make the script check for it and activate TLSA only for domains with DNSSEC active. Also, maybe a switch in DA interface into DNSSEC page for TLSA would also be nice.

Hope all this makes sense and help anyone... Good luck!
 

Attachments

  • letsencrypt_post.sh.txt
    86 bytes · Views: 112
  • set_tlsa.sh.txt
    3.2 KB · Views: 144
Love it, great work :love: ! Hopefully @DirectAdmin Support will continue to work on it and take note of your comments.

Two notes/comments:
- With TLSA for port 25 shouldn't it only be enabled if the certificate contains a matching SAN (so mail.domain.tld or *.domain.tld) that is in the certificate and also in the DNS and resolves to current IPv4 and IPv6 ip to know if it actually matches the local mailserver? So only if the default mail.domain.tld or exists in MX record with LE or any other Commercial SSL provider?
- A little typo in: "You need to provide a valid DirectAdmimn username"
 
Last edited:
Thanks lmtek. I have updated the script for additional checks and added TLSA for www too. Reuploaded the file on first post.

So, we have DNSSEC check, mail_sni and also if the certificate contains the mail SAN. Hope this solved part of the problem you asked about... Users can have custom MX name, not just mail.domain.tld... maybe a check in the DNS zone and check that SAN in the SSL could solve that too, but not sure what to do if they have many MX...
Fixed the typo too... and home didn't made new ones :p
 
lordlex said:
Thanks lmtek. I have updated the script for additional checks and added TLSA for www too. Reuploaded the file on first post.

So, we have DNSSEC check, mail_sni and also if the certificate contains the mail SAN. Hope this solved part of the problem you asked about... Users can have custom MX name, not just mail.domain.tld... maybe a check in the DNS zone and check that SAN in the SSL could solve that too, but not sure what to do if they have many MX...
Fixed the typo too... and home didn't made new ones :p
Click to expand...
Nice, but signing cert and having a TLSA/DANE will not work for those external mail servers. If DANE might get more strict on receiving servers it might fail. That was what i was afraid of.
 
Imtek said:
Nice, but signing cert and having a TLSA/DANE will not work for those external mail servers. If DANE might get more strict on receiving servers it might fail. That was what i was afraid of.
Click to expand...

Well, if the certificate of the external mail server is signed by same CA, e.g. Let's Encrypt, the rollover TLSA entry will apply if the main entry doesn't match. Right?
Also, the delete of TLSA for 25 should be moved after the SAN check, because just now I realized one could have custom TLSA for port 25 that shouldn't be deleted if it's manually managed...

And reauploaded the file... had the cat set_tlsa.sh command in it 🤦‍♂️
 
Last edited:
lordlex said:
Well, if the certificate of the external mail server is signed by same CA, e.g. Let's Encrypt, the rollover TLSA entry will apply if the main entry doesn't match. Right?
Also, the delete of TLSA for 25 should be moved after the SAN check, because just now I realized one could have custom TLSA for port 25 that shouldn't be deleted if it's manually managed...

And reauploaded the file... had the cat set_tlsa.sh command in it 🤦‍♂️
Click to expand...
I don't know exactly but i am considering some dependancies that might affect a correct situation.
 
today I get a error email, I have updated the TLSA script as described on the top of this topic!

The TLSA RRsets of some of your email servers do not match their actual certificate chains. This impedes email delivery to your domain. Please

The TLSA RRsets of some of your email servers do not match their actual certificate chains. This impedes email delivery to your domain. Please
*monitor* your systems and adopt a better key rotation approach, what you're doing now is fragile and does not work reliably. It is better to have no TLSA records than to have incorrect TLSA records.

Suggested more robust TLSA record management approaches can be found via:

https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
https://community.letsencrypt.org/t...ane-tlsa-records-with-le-certificates/7022/17
https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources

The relevant DNS records are:

; DANE TLSA fail
; None of the TLSA records match the certificate chain
;
; The MX hostname is not one of the names listed in the certificate!
; Consequently DANE-TA(2) chain verification fails. You might
; consider chaning the MX hostname to: "mail.lode****.nl"
;
_25._tcp.mail.buurt****.nl. IN CNAME le-ca.buurt****.nl.
le-ca.buurt****.nl. IN TLSA 2 0 1 25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d

Affected domains:

buurt****.nl. IN MX 10 mail.buurt****.nl.

The chain verification details are:

* mail.buurt****.nl[5.178.67.122]: name-mismatch
mail.buurt****.nl[2a00:1ca8:5f:5a9a::122]: name-mismatch
TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA
name = lode****.nl
name = mail.lode****.nl
depth = 0
Issuer CommonName = Let's Encrypt Authority X3
Issuer Organization = Let's Encrypt
notBefore = 2019-12-10T15:17:53Z
notAfter = 2020-03-09T15:17:53Z
Subject CommonName = mail.lode****.nl
cert sha256 [nomatch] <- 3 0 1 a0d256ed0c264700e5ac94a34d04fde581b0b3f7c9d934b89189006767164094
pkey sha256 [nomatch] <- 3 1 1 30bfc12123f34fa1e3eb413beb1d66b106ae9773d1de71c754c7e889e1169301
depth = 1
Issuer CommonName = DST Root CA X3
Issuer Organization = Digital Signature Trust Co.
notBefore = 2016-03-17T16:40:46Z
notAfter = 2021-03-17T16:40:46Z
Subject CommonName = Let's Encrypt Authority X3
Subject Organization = Let's Encrypt
cert sha256 [matched] <- 2 0 1 25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d
pkey sha256 [nomatch] <- 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

mail.buurt****.nl[5.178.67.122]: name-mismatch
mail.buurt****.nl[2a00:1ca8:5f:5a9a::122]: name-mismatch
TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA
name = lode****.nl
name = mail.lode****.nl
depth = 0
Issuer CommonName = Let's Encrypt Authority X3
Issuer Organization = Let's Encrypt
notBefore = 2019-12-10T15:17:53Z
notAfter = 2020-03-09T15:17:53Z
Subject CommonName = mail.lode****.nl
cert sha256 [nomatch] <- 3 0 1 a0d256ed0c264700e5ac94a34d04fde581b0b3f7c9d934b89189006767164094
pkey sha256 [nomatch] <- 3 1 1 30bfc12123f34fa1e3eb413beb1d66b106ae9773d1de71c754c7e889e1169301
depth = 1
Issuer CommonName = DST Root CA X3
Issuer Organization = Digital Signature Trust Co.
notBefore = 2016-03-17T16:40:46Z
notAfter = 2021-03-17T16:40:46Z
Subject CommonName = Let's Encrypt Authority X3
Subject Organization = Let's Encrypt
cert sha256 [matched] <- 2 0 1 25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d
pkey sha256 [nomatch] <- 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

3 1 1 30bfc12123f34fa1e3eb413beb1d66b106ae9773d1de71c754c7e889e1169301
2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

3 1 1 30bfc12123f34fa1e3eb413beb1d66b106ae9773d1de71c754c7e889e1169301
2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

* Potential matching TLSA records, please publish and monitor (two):

You can test your SMTP server DANE support at:

https://dane.sys4.de

--
Viktor.
 
after updated the files letsencrypt_post.sh and set_tlsa.sh is it correct I get only 2 values and not 4?

TLSA _443._tcp.www 3600
2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
TLSA _443._tcp.www 3600
3 1 1 0e5ec4ae4b41246fabbd6e0a0d7da50ecb9052c2e154840cf4d073f079984248
 
Also put this into a feature request to automate it:

TLSA/DANE automation with Let's Encrypt - Feature requests - DirectAdmin Feedback

I would love to see TLSA/DANE automation for DNSSEC signed domains, and for automation of renewal of the TLSA record. It would be preferred/required a DNSSEC signed domain to make use of DANE, i would suggest checking the DNSSEC signing validation exte
feedback.directadmin.com feedback.directadmin.com
 
The script does not work for me.
I get an error:

[root@web custom]# ./set_tlsa.sh domain.nl user
This domain does not have DNSSEC active. Skipping TLSA.

But DNSSEC is active! Tested with internet.nl. I also tested it with https://dnssec-analyzer.verisignlabs.com/domain and this gives all green flags.

What is going wrong?
 
Disabling the exit 0: line with the DNSCHECK had effect. TLSA records are made now.

Internet.nl test is now 100% and DANE is twice green checked. So the rest of the script works. The DNSCHECK test in the script seems not correct.
 
It looks like it locally checks if it is signed, not externally. So if you use external zone signing that may be the cause.
 
It seems that two tests are needed. Test if internal signbed, if not, test external signed, if not then no valid DNSSEC
So I think it should look something like:

if ! grep -q "$DOMAIN.db.signed" $NCONF; then # not local signed

if [ $(dig DS $DOMAIN +short | wc -l) = "0" ]; then # externaly signed

else
echo "This domain does not have DNSSEC active. Skipping TLSA.";
exit 0;
fi
fi
 
This works for me, but the subdomains do not get a TLSA. I have multiple cloud.domain.nl that are missed.
I think there has to be a loop that reads the actual subdomains, certificate (yes/no) and then something like the www construction has to be added. With or without www for the subdomain. The base should be the certificate I think.
I'm missing the technical knowledge to build this routine.
 
Existing older www TLSA is not removed. I added below the two lines:

echo "action=dns&do=delete&domain=${DOMAIN}&type=TLSA&name=_443._tcp.www&value=*" >> ${TQ}.cb;

So also the routine to remove older/earlier TLSA records should be edited. I'd suggest some wildcard to remove all TLSA. New ones will (should) be created only for valid certificate domains and subdomains.
 
Great script, didn't noticed it before, just a minor update, found out that wildcard certs are not supported.
made a small change to to code

Change following code:
Code: 
    MAILSAN="DNS:mail.$DOMAIN";
    if ! `openssl x509 -noout -text -in $CRT | grep -q $MAILSAN`; then
        echo "The certificate for this domain doesn't have the mail.$DOMAIN SAN. Skipping TLSA for the mail server (port 25).";
    else
        echo "This domain have the mail.$DOMAIN SAN. Seting up TLSA for mail server.";
        echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_25._tcp.mail&value=$VCA" >> ${TQ};
        echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_25._tcp.mail&value=$VCRT" >> ${TQ};
    fi

with

Code: 
    MAILSAN="DNS:mail.$DOMAIN";
    if ! `openssl x509 -noout -text -in $CRT | grep -q $MAILSAN`; then
        echo "The certificate for this domain doesn't have the mail.$DOMAIN SAN. Skipping TLSA for the mail server (port 25).";
    else
        echo "This domain have the mail.$DOMAIN SAN. Seting up TLSA for mail server.";
        echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_25._tcp.mail&value=$VCA" >> ${TQ};
        echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_25._tcp.mail&value=$VCRT" >> ${TQ};
    fi

    MAILWILDCARD="DNS:\*.$DOMAIN";
    if ! `openssl x509 -noout -text -in $CRT | grep -q $MAILWILDCARD`; then
        echo "The certificate for this domain doesn't have the *.$DOMAIN Wildcard. skipping TLSA for the mail server (port 25).";
    else
        echo "This domain have the *.$DOMAIN Wildcard. Seting up TLSA for mail server.";
        echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_25._tcp.mail&value=$VCA" >> ${TQ};
        echo "action=dns&do=add&domain=${DOMAIN}&type=TLSA&name=_25._tcp.mail&value=$VCRT" >> ${TQ};
    fi
 
You must log in or register to reply here.
Back
Top