DANE Support | MDaemon Technologies Community Forum
  1. Forum
  2. MDaemon
  3. DANE Support

DANE Support

  • O

    Hello,

    While testing the current Let's Encrypt PowerShell script included with MDaemon (v2.0.16), I noticed that a new certificate key pair is generated during every renewal:

    if(Test-Path $CertKeyPath) {
    Log "Removing the existing $CertKeyPath file from disk."
    Remove-Item -Path $CertKeyPath -Force
}

if($ECDSA){
    $global:CertKey = New-ACMECertificateKey -Path $CertKeyPath -ECDsa
} else {
    $global:CertKey = New-ACMECertificateKey -Path $CertKeyPath -RSA
}

    This behavior works well for standard certificate renewals, but it creates a challenge for administrators who deploy DANE (DNS-based Authentication of Named Entities) with TLSA records based on the certificate's public key (for example, TLSA usage 3 selector 1 matching type 1).

    Because a new key pair is generated during every renewal, the TLSA record becomes invalid after each certificate renewal and must be updated manually. If the administrator forgets to update the TLSA record, DANE validation will fail.

    I tested a modified version of the script that reuses the existing certificate key when present:

    if (Test-Path $CertKeyPath) {
    Log "Reusing existing certificate key from $CertKeyPath"
    $global:CertKey = Import-ACMECertificateKey -Path $CertKeyPath
} else {
    Log "No existing key found → generating new certificate key"
    if($ECDSA){
        $global:CertKey = New-ACMECertificateKey -Path $CertKeyPath -ECDsa
    } else {
        $global:CertKey = New-ACMECertificateKey -Path $CertKeyPath -RSA
    }
}

    After testing, certificate renewals completed successfully, the public key remained unchanged, and existing TLSA records continued to validate correctly.

    Would it be possible to add an optional setting such as:

    "Reuse existing Let's Encrypt certificate key during renewal"

    or a similar GUI option?

    This would make DANE deployments much easier to maintain while preserving the current behavior as the default for administrators who prefer automatic key rotation.

    Thank you for considering the suggestion.

    0 likes
  • A

    I've made the changes for the next major version of MDaemon.

    I'm sure you already know this, but in general, it is reccomended that you use new keys.  There is nothing wrong with re-using keys if you need to, but if you don't have a reason to, using new keys every time is better.

    Thank you for the request and for providing the changes that you made. 

    --
    Arron Caruth

  • O

    Thanks dear Arron, Another quick report about the script:

    There is another issue about how $FQDN is defined and subsequently used to construct the $email variable in the script causing the email being sent to postmaster@mdaemon_host.maindomain.tld instead of postmaster@maindomain.tld

    • Line 667: $FQDN = (Get-PrivateProfileString $MDINIPath "Domain" "FQDN").ToLower()

    • Line 739: $email = "postmaster@"+$FQDN
    0 likes
  • A

    If I recall correctly, we used the FQDN to more easily identify the server if you had multiple servers hosting mail for the same domain.  

    --
    Arron Caruth

    0 likes
  • O

    Thank you for the context. I understand the goal is to make server identification easier in a multi-node environment.

    However, the issue with hardcoding the FQDN is that it assumes the server's hostname is fully routable for inbound mail. In many infrastructures, the FQDN (e.g., mdaemon_host.maindomain.tld ) lacks MX records or valid aliases, meaning those Let's Encrypt expiration notices simply bounce and are never seen by the administrator.

    Adding an optional parameter (e.g., -LetsEncryptEmail) would be the ideal compromise. It would preserve your current default behavior for users who rely on the FQDN, while allowing administrators with different routing topologies to specify a valid inbox—without having to manually patch the script after every MDaemon update.

    0 likes
  • A

     meaning those Let's Encrypt expiration notices simply bounce and are never seen by the administrator.

    LetsEncrypt no longer sends expiration notices. https://letsencrypt.org/2025/01/22/ending-expiration-emails

    MDaemon sends certificate expiration notices to global administrators and the postmaster at 14, 7, and 3 days until expiration.  We intentionally set the days less than 30 days to avoid administrators receiving notifications about certificates that will automatically renew.   

    --
    Arron Caruth

Please login to reply to this topic!

Participants