Hi. This post is related to:
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!
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!