DANE Rollover scheme

lawk · April 23, 2024, 9:15pm

SYSTEM INFORMATION
OS type and version	Almalinux 9.3
Webmin version	2.111
Virtualmin version	7.10.0

I am trying to figure out how to make DANE work properly.

I enabled DNSSEC and DANE (TLSA) records for my domain and added it to my registrar.

it works.

DANE TLSA, when issuing a new certificate, comes up as invalid on various testing sites.

When restarting BIND, the values tend to validate after a short while. I dont know if this is a propagation issue or BIND needs to be restarted for the new TLSA values.

Other issue:

for every letsencrypt cert request it generates new 301 type records, and the old ones become invalid.

if I test my domain on internet.nl I get a message saying that I dont have a DANE rollover scheme in place.

There are some sites that explain records with 311 and 211 records which have the new key as well and that 301 is wrong for letsencrypt? I really dont have the knowledge or understanding.

See for example:

Please avoid “3 0 1” and “3 0 2” DANE TLSA records with LE certificates - Server - Let’s Encrypt Community Support (letsencrypt.org)

But I also read that letsencrypt has this:

–reuse-key When renewing, use the same private key as the
existing certificate. (default: False)

maybe would help?

Steveperry · April 26, 2024, 11:03am

To resolve your DANE and DNSSEC issues, consider using the --reuse-key option with Let’s Encrypt to keep the same private key during renewals, which helps maintain valid TLSA records. Also, switch from “3 0 1” TLSA records to a configuration that reuses keys, as recommended for Let’s Encrypt. This approach should reduce TLSA record changes and improve validation results.
Also Check this : learnmore -community.cloudflare.com/t/support-for-tlsa-dane-proto/9881?page=2

lawk · April 26, 2024, 7:12pm

I don’t know where to edit the letsencrypt command, nor do I know if thats a good idea.

I was hoping that in future updates it is implemented with a rollover scheme.

if you change the TLSA records, they are overwritten at cert request currently.

johnhe · May 6, 2024, 2:39am

The TLSA DNS records can be regenerated for a temporary fix:

1)For your domain DNS Settings, DNS Options, ‘TLSA records enabled’, choose No.
2) Redo and choose Yes

johnhe · May 6, 2024, 3:41am

Below is what I received from an unsolicited survey email.

I am using it to restate core parts from the OP.

It is probably time to move this to an issue on github.

The first link below provides a good summary of what the issue is and how to solve it:

Use --reuse-key for both certificate generation and renewal with certbot
Publish the DNS TLSA record as 3 1 1 record, not a 3 0 1 or 3 0 2 record.

The second link below is a refinement for rollover for when a private key does actually change.

From the email:

The issues can be resolved by removing or updating the associated DNS
DANE TLSA records.

- "3 0 [12]" vs. Let's Encrypt:
  https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17

- Best practice "3 1 1" rollover methodology:
  https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html

- Monitoring code snippet:
  https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/thread/NKDBQABSTAAWLTHSZKC7P3HALF7VE5QY/

https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html

lawk · May 6, 2024, 11:59am

I think this is for virtualmin team because it is not simply about changing the dns records, at renewal it creates the 301 again.

I think the command has to be adjusted.

I am really no expert, all I know is that sometimes at renewal, immediately after it will report broken DANE.

I think it is imporant for mail delivery that it works when using DANE.

So we are not in a dead zone between nameserver updates/propagation.

johnhe · May 6, 2024, 12:14pm

Yes, it shoud be handled by the Virtualmin team.

The impression I get is that as long as the private key is not changed when a 90 day LE certificate is reissued then a 3 1 1 DNS TLSA record DOES NOT NEED to be recreated, but a 3 0 1 or 3 0 2 DNS TLSA record DOES NEED to recreated.

So if the private key is changed the DNS TLSA record must be recreated. If the private key is not changed the the DNS TLSA record does not need to be changed if it is a 3 1 1 type.

With certbot, --reuse-key reuses the private key. It is possible Virtualmin already does this.

I don’t know what the command and parameters are to generate a TLSA DNS record. I assume it simple.

johnhe · May 7, 2024, 12:47am

There have been lenghty discussions in Virtualmin Github issues. Reopening looks like a waste of time.

I checked LE settings for private key reuse (yes) and note --reuse-key is being entered in logs.

Someone needs to find specific lines in source code and request they be changed because changing them fixed the problem for them. I will have a look myself

johnhe · May 7, 2024, 4:06am

I have proposed a three line fix in a new Virtualmin Github issue at

github.com/virtualmin/virtualmin-gpl

Three line fix for DANE TLSA DNS records going out of date every 90 days with LE

opened 04:02AM - 07 May 24 UTC

johnheenan

Free LE certificates are commonly used with Virtualmin. They need to be renewed …every 90 days. DANE TLSA DNS records do not need to be updated provided: 1) The reissued LE certificates use `reuse-key` with certbot command so the key is not changed. 2) The selector key of the TLSA record (second digit) is 1 (for subject public key) and not 0 (for full certificate). So 3-0-1 and 3-0-2 DANE TLS records should be avoided. Information at https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 Virtualmin writes 3-0-1 records. Below is a fix to change to 3-1-1 records. I have confirmed this works by disabling domain TLSA DNS, reenabling it and testing from site https://dane.sys4.de/ (after a delay). These code changes have nothing to do with setting up an addiitonal TLSA DNS key for key rotation. If a key is changed then the TLSA DNS records need to be reissued (for example by disabling and enabling as above). There will be a small amount of time when records will be out of sync. Check `--resuse-key` is in use from Webmin, Webmin, Webmin Configuration, Cog (for module configuration), Next, Re-use existing LE keys?, Yes, Save Edit function `create_tlsa_dns_record` in file `webmin/virtual-server/feature-dns.pl`. **Change lines:** ``` "openssl x509 -in ".quotemeta($temp)." -outform DER 2>/dev/null | ". "openssl sha256 2>/dev/null"); ``` **to:** ``` "openssl x509 -in ".quotemeta($temp)." -pubkey -outform DER 2>/dev/null | ". "openssl rsa -pubin -outform DER 2> /dev/null | openssl sha256 2>/dev/null"); ``` **Change line:** ``` 'values' => [ 3, 0, 1, $1 ] }; ``` **to** ``` 'values' => [ 3, 1, 1, $1 ] }; ```

I have since added information to the issue which explains why LE (Let’s Encrypt) appears to involved in a protocol (TLSA DNS) that is supposed to be independent of LE. The record generation process can be made completely independent and I provide an example of this.

John Heenan

system · July 6, 2024, 4:06am

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.