On Sat, Nov 22, 2025 at 01:33:44PM +0200, Edmund Lodewijks via Postfix-users
wrote:
> On 2025/11/22 12:38, Viktor Dukhovni via Postfix-users wrote:
> > There are many DANE-enabled MX hosts with just a self-signed EE certificate.
> > Here's an example:
>
> My server presents 2 self-signed certs now, and finally an LE cert. The
> last one is because of your comment in a previous email that some
> misguided mail servers might use cleartext if they don't like
> self-signed certificates.
The above seems muddled, It is not possible to instantiate multiple
end-entity certificates in a single TLS handshake. Any given chain has
exactly one end-entity (leaf) certificate for a single public key
algorithm, and then zero or more issuer CA certificates forming a linear
chain of subject/issuer pairs.
It is possible to *configure* a separate chain for each of multiple
(possibly after SNI hostname driven selection), but only one is
used with any given client.
You MX host appears to have at least 3 separate chains, which is an
advanced configuration, not recommended for most users, because you now
have to deal with DNS updates and careful certificate rollovers for at
least three separate "chains" and corresponding TLSA records:
$ danesmtp -s rsa mail.proteamail.com
Connecting to 2a01:4f8:1c0c:81c0::1
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=mail.proteamail.com
Hash used: SHA256
Signature type: rsa_pss_rsae_sha256
Verification: OK
DANE TLSA 3 1 1 ...9fdf44f70902c6ed5b6d4714 matched the EE certificate
at depth 0
Negotiated TLS1.3 group: X25519MLKEM768
250 CHUNKING
DONE
$ danesmtp -s ecdsa mail.proteamail.com
Connecting to 49.12.119.27
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=mail.proteamail.com
Hash used: SHA256
Signature type: ecdsa_secp256r1_sha256
Verification: OK
DANE TLSA 3 1 1 ...302e4efd2d74069b8a2f399f matched the EE certificate
at depth 0
Negotiated TLS1.3 group: X25519MLKEM768
250 CHUNKING
DONE
$ danesmtp mail.proteamail.com -sigalgs mldsa65
Connecting to 49.12.119.27
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=mail.proteamail.com
Hash used: UNDEF
Signature type: mldsa65
Verification: OK
DANE TLSA 3 1 1 ...fc39bdf763489a14c6fce0d3 matched the EE certificate at
depth 0
Negotiated TLS1.3 group: X25519MLKEM768
250 CHUNKING
DONE
So it isn't that the server presents 2 self-signed cert *and* an EE
certs. Rather, depending on the signature algorithm choices common
to client and server just one of the three chains is presented to
the client. And in two of those cases it is self-signed, and just
one (either RSA or ECDSA) is from Let's Encrypt.
I am not sure what the last two of your five "3 1 1" records are for:
$ dig +short +nosplit -t tlsa _25._tcp.mail.proteamail.com | tr A-F a-f
3 1 1 392a469573e8b39855ec1905424258d11179c0449fdf44f70902c6ed5b6d4714
3 1 1 2b15d53fe597ea54424c47d0c614a635571dd02d302e4efd2d74069b8a2f399f
3 1 1 b907713aeb69da1dd0ddb16a4d69a836639e1297fc39bdf763489a14c6fce0d3
3 1 1 20c38c81d72c224aa7a7d4554d6531528a883275909a8c07b5e8305dbbcf8408
3 1 1 cf1204c04dbf17d03272ee3fa19bf5b2e556d9d12fc7d8f08ed5b663e3bb13b0
Though the fourth is an ECDSA public key digest seen recently by the
DANE survey for your MX host, but now superseded by the second. It
was first seen on 2025-10-24, but the matching TLSA record appeared
later, on 2025-10-28, so for ~4 days your ECDSA chain had no matching
TLSA records. Simplifying your configuration to just the ECDSA or just
the RSA certificate is strongly advised, plus monitoring!
> > Not sure what you mean by "first certificate", and which one you find
> > interesting. The one from Let's Encrypt or the self-signed one with
> > ML-DSA-65?
>
> The ML-SDA-65 one. I figured that your server prefers its own ciphers,
> and the one I was presented with was the mldsa65; hence my conclusion
> that that one is the first in your chain.
No, it is not "the first one in the chain", rather I have two chains
configured, and my servers's signature algorithm preference list puts
ML-DSA-65 first, and it is used whenever also supported by the client.
And in that case, only that certificate is seen by the client, and the
others are not in scope.
ML-DSA-65 is much too bleeding edge, and I'm only using using it because
I am partly responsible for the underlying code in OpenSSL, so morally
bound to test it (eat own dog food as it were).
My advice is for your server to be configured with a single ECDSA or RSA
certificate. And, with DANE, make it self-signed, the risk of cleartext
fallback for that reason is very low, you'll probably never see it
happen.
Combining Let's Encrypt with DANE can be tricky, because by default your
private key changes automatically with every renewal and it is not
obvious how to make sure that TLSA record updates happen a few TTLs in
advance of new key deployment (initially matching both the current and
next key, with those matching the current key later removed once the
new key is made "current").
But see:
- https://github.com/raforg/danectl
perhaps more polished IIRC than:
- https://github.com/tlsaware/danebot
And also:
https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html
With a self-signed certificate not managed by ACME, you decide when it
is time to do or not a key rollover, and if you are doing it right, plan
it properly, with appropriate DNS updates before and after. Also if
you're deploying DANE without timely monitoring on your end, you're
doing it wrong.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
