Since nowdays by default LE keys are also renewed, besides certificates, there should realy be an automated function in ISPC for selfhosted DNS zones that updates the TLSA records on renewal of the certificate and key. If I'm not mistaking the next key is pre-made so the next TLSA record can be made in advance. When renewing the certificate and key delete the TLSA record for the old key and create a new record for the future key. That way there will always be 2 records, current and future. For multi-domain certificates (including www) use the master domain for TLSA records and CNAME records to that TLSA record for the other domains. That way there's less that needs updating on renewal (only the TLSA records). Also less records since other domains only need 1 CNAME record instead of 2 TLSA records. The port that is needed in the TLSA (or CNAME) record's name is known in ISPC. And build in a check to do so for selfhosted DNS zones only. For ISPC server certificates create TLSA records for every TLSA applicable service port (web, smtp, submit, pop, imap etc). Or create TLSA records for 1 of those services and CNAME records for the other ports (again less records and less that needs updating on renewal).
Are DANE and TLSA records really important? I still remember HTTP Public Key Pinning. Like TLSA, creating it isn't particularly complicated - but ensuring the values remain correct during continuous operation is somewhat complex. And if the values aren't correct => PITA. Public Key Pinning was therefore finally removed from all browsers in 2018. Now we have TLSA. It can be used for all ports - but for browser HSTS is sufficient enough. Main focus of TLSA is server-to-server email exchange on port 25. But what if no TLSA record exists at all? Then there are no problems receiving emails. On average 1.7% of domains with an MTA have a TLSA record. Only with TLD .NL it is significantly over 10%. The Dutch program with its portal Internet.NL seems to be having a noticeable effect. Even though we all know it's self-deception, we all want to get into the "Hall of Fame". Unfortunately, ISPConfig unnecessarily increases the effort required to maintain TLSA records: With each certificate renewal, also a new private key is automatically generated. This results in a new public key, and therefore the TLSA record must also be renewed each time. Nobody wants to do this manually, especially since Let's Encrypt recently announced that it will reduce the certificate validity period from 90 to 45 days. However, generating a new private key with every renewal is unnecessary and also contradicts Let's Encrypt's recommendation. Or am I missing something? What do I need to do to prevent the key renewal with ISPConfig? 1.) Is it sufficient to remove the following line from the file: /root/.acme.sh/mail.example.com/mail.example.com.conf Le_ForceNewDomainKey='1' 2.) I'm also deleting the file:: /root/.acme.sh/mail.example.com/mail.example.com.key.next 3.) Do I also need to remove the parameter in file: /usr/local/ispconfig/server/lib/classes/letsencrypt.inc.php --always-force-new-domain-key ?
Yes for existing certificates Yes to cleanup but it shouldn't hurt anything if left behind Yes if you want to skip step 1 and 2 for new certificates And remember to redo that after an ispconfig update!
Dane doesn't count in the percentage on internet.nl And to satisfy internet.nl you can also use intermediate certificates for dane (2 1 1 xxxxx). So you can create tlsa records for all LE Rx and Ex certificates in one of your dns zones and CNAME it in your other dns zones.
Thanks for your input! I'd also considered 2-1-1. The intermediate key is rarely changed, but I still need to monitor it closely to avoid missing any changes. On the other hand, with 3-1-1, and after deleting Le_ForceNewDomainKey='1', even an ISPConfig update doesn't change the existing keys, right? Nevertheless, I'll perform any ISPConfig updates under my own control, and in that context, I can also run my script to update the TLSA records on my external nameserver. And not to forget: I need two TLSA records, one for RSA and one for ECC.
