Secure DANE with TLSA Records in Virtualmin Using Let’s Encrypt (and Beyond)

Introduction

When running a mail or web server with DNSSEC enabled, adding TLSA records to your DNS zone allows clients to verify your SSL/TLS certificates via DNS—a protocol known as DANE (DNS-based Authentication of Named Entities). This adds a powerful layer of trust, especially for SMTP and HTTPS services.

However, TLSA records must match your certificate’s fingerprint. If they don’t, clients may reject connections or flag your domain as insecure. This mismatch can happen with any certificate authority—but it’s especially common with Let’s Encrypt due to its frequent renewals and automated deployment. Virtualmin users may unknowingly be generating fragile TLSA records that break this trust.

The Reason You Should Fix It

TLSA mismatches aren’t exclusive to Let’s Encrypt. Any certificate that changes without updating the corresponding TLSA record can break DANE validation. But Let’s Encrypt renews certificates every 60–90 days, making "3 0 1" records (which hash the full certificate) particularly vulnerable.

Virtualmin automates many tasks—including TLSA record generation—but its default behavior may not be optimal. If you don’t intervene, it may generate "3 0 1" records, which become invalid with each renewal. The better approach is to use "3 1 1", which hashes the public key and remains stable across renewals—even if the certificate itself changes.

Finding the root cause takes time. You’ll need to inspect Virtualmin’s server templates, DNS records, and SSL settings. But once you identify the automation source and adjust the configuration, the result is a robust, renewal-safe setup that protects your users and your reputation.

How to Fix It (for Virtualmin Users)

1. Audit Your TLSA Records Use dig to inspect your current TLSA entries:bashdig +dnssec TLSA _25._tcp.mail.yourdomain.com Look for:
   • 3 0 1 → full certificate (fragile)
   • 3 1 1 → public key (stable)
2. If you get 3 0 1 result Go to: Virtualmin > Dns Settings > Dns Options > Choose TLSA records enabled to “NO”
3. Check Virtualmin’s Server Template Go to: Virtualmin > System Settings > Server Templates > SSL website for domain Find the setting: “Create TLSA DNS records for SSL certificates” Change it to: “Yes, with just public key”
4. Since Virtualmin generating those record automatic, just save it after changing
5. Go back to Virtualmin > Dns Settings > Dns Options > Choose TLSA records enabled to “YES”
6. Reload BIND Apply changes via Webmin or run:bashsudo rndc reload
7. Verify with dig Again After reloading, confirm the new record is live:bashdig +dnssec TLSA _25._tcp.mail.yourdomain.com Ensure the output shows the updated "3 1 1" format and that DNSSEC validation (ad flag) is present.

Guide for Users Not Using Virtualmin

If you’re managing your server manually or using a different control panel (like cPanel, Plesk, DirectAdmin, or a bare-metal setup), you can still configure TLSA records for DANE. The key is to generate the correct fingerprint and insert it into your DNS zone file.

Step-by-Step TLSA Setup Without Virtualmin

1. Extract the Public Key from Your Certificate Use OpenSSL to extract the public key:bashopenssl x509 -in /path/to/cert.pem -pubkey -noout > pubkey.pem
2. Generate the TLSA Record Using hash-slinger or danetool Example with hash-slinger:bashtlsa --create --usage 3 --selector 1 --mtype 1 --port 25 --protocol tcp mail.yourdomain.com pubkey.pem This will output a TLSA record in "3 1 1" format.
3. Add the TLSA Record to Your DNS Zone If you’re using BIND, add it directly to your zone file:Code_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 <fingerprint> Replace <fingerprint> with the actual hash output.
4. Sign the Zone with DNSSEC If DNSSEC is enabled, make sure to re-sign the zone:bashdnssec-signzone -A -3 <salt> -N INCREMENT -o yourdomain.com db.yourdomain.com
5. Reload BIND Apply the changes:bashsudo rndc reload
6. Verify with dig Confirm the record is live and DNSSEC is working:bashdig +dnssec TLSA _25._tcp.mail.yourdomain.com

Tips for Other Control Panels

• cPanel: TLSA records must be added manually via the “Advanced DNS Zone Editor” (if available). DNSSEC support is limited.
• Plesk: Use the DNS settings panel to add TLSA records. DNSSEC is supported in newer versions.
• DirectAdmin: TLSA records can be added via the DNS Management interface. DNSSEC may require external configuration.

The Result

Once configured correctly, your TLSA records will:

• Stay valid across Let’s Encrypt and other certificate renewals
• Pass DANE authentication checks consistently
• Improve trust for SMTP, HTTPS, and other services
• Reduce downtime and eliminate fingerprint mismatch warnings

This setup is especially powerful when paired with DNSSEC. Clients that support DANE (like Postfix, Exim, or OpenSSH with SSHFP) will verify your identity automatically—no manual fingerprint confirmation needed.

By taking the time to trace and correct Virtualmin’s default behavior, you ensure your infrastructure is secure, compliant, and future-proof. It’s a small investment with a big payoff in reliability and trust.