Submitted by beat on Fri, 05/29/2020 - 05:21
Hello!
Reporting 2 related bug reports:
- 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.
- Additionally, other sub-domains created in Webmin/BIND do not automatically get a TLSA record and are missing it.
Status:
Fixed (pending)
Comments
Hi,
Thanks for the heads up!
I will assign this to Jamie for review, as he's working on fixing this part right now.
Submitted by JamieCameron on Sat, 05/30/2020 - 10:59 Comment #2
Thanks, this looks like a bug. Was the Let's Encrypt cert updated automatically by Virtualmin, or did you do it using the UI?
Submitted by beat on Sat, 05/30/2020 - 15:28 Comment #3
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 ?
Submitted by JamieCameron on Sat, 05/30/2020 - 17:22 Comment #4
Virtualmin will only re-create or update TLSA records that knows about - so for subdomains created in Virtualmin.
Submitted by beat on Sat, 05/30/2020 - 17:57 Comment #5
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).
Submitted by JamieCameron on Sat, 05/30/2020 - 22:39 Comment #6
The next Virtualmin release will fix the issue of some TLSA certs for sub-domains like
mail
andadmin
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.
Submitted by beat on Sun, 05/31/2020 - 07:48 Comment #7
Thank you Jamie!
2 more suggestions for a more complete featureset:
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 (suchmail
andadmin
) 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.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.
Submitted by JamieCameron on Mon, 06/01/2020 - 00:01 Comment #8
Virtualmin should already add other domains the the Let's Encrypt request, like
mail
andadmin
, 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.Submitted by beat on Mon, 06/01/2020 - 15:38 Comment #9
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
andwebmail
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.Submitted by JamieCameron on Tue, 06/02/2020 - 00:39 Comment #10
Unfortunately, the way those redirects work currently makes it impossible to request a Let's Encrypt cert for
admin
andwebmail
sub-domains. I'll look into fixing this ..Submitted by JamieCameron on Mon, 06/08/2020 - 01:38 Comment #11
This will be fixed, for new domains, in the next Virtualmin release.