TLSA records not auto-created for additional subdomains and not all existing ones are updated when the Let's Encrypt SSL certificate is renewed

Hello!

Reporting 2 related bug reports:

  1. Not all TLSA records seem to be auto-updated with Let's Encrypt certificate updates:

This is an example of TLSA records in a domain managed by Virtualmin

_443._tcp   TLSA    3 0 1 7134057bded140bb7d80a373ff5a4beef23919d2d1e2eb9fbf6c6a2d52025a62
_443._tcp.www   TLSA    3 0 1 7134057bded140bb7d80a373ff5a4beef23919d2d1e2eb9fbf6c6a2d52025a62
_10000._tcp.admin   TLSA    3 0 1 0fed1619ac1a7a54bfe37705225b2c3390f2fe354c2ec614e2afd99eab2ede6f
_10000._tcp     TLSA    3 0 1 0fed1619ac1a7a54bfe37705225b2c3390f2fe354c2ec614e2afd99eab2ede6f
_20000._tcp.webmail     TLSA    3 0 1 0fed1619ac1a7a54bfe37705225b2c3390f2fe354c2ec614e2afd99eab2ede6f
_20000._tcp     TLSA    3 0 1 0fed1619ac1a7a54bfe37705225b2c3390f2fe354c2ec614e2afd99eab2ede6f
_993._tcp.mail  TLSA    3 0 1 7134057bded140bb7d80a373ff5a4beef23919d2d1e2eb9fbf6c6a2d52025a62
_993._tcp   TLSA    3 0 1 7134057bded140bb7d80a373ff5a4beef23919d2d1e2eb9fbf6c6a2d52025a62
_995._tcp.mail  TLSA    3 0 1 7134057bded140bb7d80a373ff5a4beef23919d2d1e2eb9fbf6c6a2d52025a62
_995._tcp   TLSA    3 0 1 7134057bded140bb7d80a373ff5a4beef23919d2d1e2eb9fbf6c6a2d52025a62
_587._tcp.mail  TLSA    3 0 1 0fed1619ac1a7a54bfe37705225b2c3390f2fe354c2ec614e2afd99eab2ede6f
_587._tcp   TLSA    3 0 1 0fed1619ac1a7a54bfe37705225b2c3390f2fe354c2ec614e2afd99eab2ede6f
_25._tcp.mail   TLSA    3 0 1 0fed1619ac1a7a54bfe37705225b2c3390f2fe354c2ec614e2afd99eab2ede6f
_25._tcp    TLSA    3 0 1 0fed1619ac1a7a54bfe37705225b2c3390f2fe354c2ec614e2afd99eab2ede6f

The 443, 993, 995 ports are up-to-date, the 25, 587, 10000 and 20000 ports are not.

  1. Additionally, other sub-domains created in Webmin/BIND do not automatically get a TLSA record and are missing it.
Status: 
Fixed (pending)

Comments

Ilia's picture
Submitted by Ilia on Sat, 05/30/2020 - 08:56

Assigned: Unassigned »

Hi,

Thanks for the heads up!

I will assign this to Jamie for review, as he's working on fixing this part right now.

Thanks, this looks like a bug. Was the Let's Encrypt cert updated automatically by Virtualmin, or did you do it using the UI?

For bug 1, it was automatic renewal Let's Encrypt renewal.

For bug 2, those subdomains were added in Webmin/BIND interface as A records, before DANE was activated, and even if re-saving the A record, no TLSA (and no RRSIG and NSEC for the TLSA missing record) records are automatically created for the additional subdomains. Wondering if this DANE should not be moved/replicated to the basic BIND of Webmin too ?

Virtualmin will only re-create or update TLSA records that knows about - so for subdomains created in Virtualmin.

For Problem 2: So how about A-records created in Webmin ? How to create A records so that they get a TLSA record (but without creating a sub-server each time on that server) ?

Bug 1 stays problematic (and results in mail.domain.com subdomain being invalid).

The next Virtualmin release will fix the issue of some TLSA certs for sub-domains like mail and admin not being updated, as part of a generate re-write of that code.

However, there is no facility yet for adding TLSA records for arbitrary A records.

Thank you Jamie!

2 more suggestions for a more complete featureset:

  1. Thinking of it, Let's Encrypt standard "Domains associated with this server" only adds www. as a subdomain to the SSL certificate request. Shouldn't it also add all the other "standard-configured" subdomains of the virtual server (such mail and admin) to the SSL certificate request by default ? (in addition of adding TLSA+RRSIG+NSIG records for them?). Not sure about this one, as the certificate would "leak" the admin and mail subdomains to website users, IF they are in the same certificate requested. Solution would be to have a separate Let's Encrypt certificate for mail and admin subdomains from the www./main domain SSL certificate.

  2. Reversly, logically, a TLSA DNS record should/could be created for each subdomain in the Let's Encrypt "Domain names listed here" non-default domains list for the SSL certificate requests ? Here it seems quite logic to complete the SSL protection by linking it to the DNS protection, having a complete signed trust-chain.

Virtualmin should already add other domains the the Let's Encrypt request, like mail and admin, as long as DNS records for them exist and Apache is configured to serve them. This is needed because of the way Let's Encrypt validation works. From that, the TLSA records also get created.

Hi Jamie,

That's wierd, I have many domains automatically configured by Virtualmin with in their Apache site config file:

ServerName domain.com
ServerAlias www.domain.com
ServerAlias webmail.domain.com
ServerAlias admin.domain.com

...

RewriteCond %{HTTP_HOST} =webmail.domain.com
RewriteRule ^(.*) https://domain.com:20000/ [R]
RewriteCond %{HTTP_HOST} =admin.domain.com
RewriteRule ^(.*) https://domain.com:10000/ [R]

And redirection working (under https, with certificate warning (using default SSL certificate of default domain of server)), but admin and webmail are not added to the Let's Encrypt certificate. As said, it would be slightly better that they would be 2 separate Let's Encrypt certificates, so that the webmail and admin sub-domain existence is not leaking through the certificate's domain list, but it's minor.

Nor is the mail.domain.com DNS entry, used for secure mail SMTP and IMAP services of the domain, automatically added to the Let's Encrypt certificates's default domains near the radio-button.

Unfortunately, the way those redirects work currently makes it impossible to request a Let's Encrypt cert for admin and webmail sub-domains. I'll look into fixing this ..

This will be fixed, for new domains, in the next Virtualmin release.