On 2025/11/22 15:18, Viktor Dukhovni via Postfix-users wrote:
Hello Viktor,
Thank you for taking the time to reply and to point out the flaws in my
setup - it is very insightful!
> 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.
> 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.
Correct. My wording *and* my understanding were wrong.
Postfix exposes a single configuration parameter "smtp_tls_chain_files",
where one can list one, or several, key-certificate chains (either in
separate files following each other, or concatenated into one file). I
have been changing my configuration a couple of times in the last weeks
- see further below.
I understand that a TLS handshake can only use one such key-cert
combination.
I have not looked at the code, but I just guessed that `tlsproxy`
offered the first chain (say, mldsa65); and then the connecting client
might say: "I don't speak mldsa65, can you authenticate yourself with
another key-cert?". And then the server would go and present the second
chain (say: ecdsa), and then perhaps the third (rsa). All this presuming
that the key-cert combos match the SNI hostname.
This "negotiation" does perhaps not happen, as I take it from your email.
> 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:
The reason being, besides tinkering, the above (mis?)understanding of
falling back the next chain, if the first one is not acceptable to the
connecting client.
With 100year certs (`postfix-tls`), once it's set up, it should be good
for a while?
> 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
In the past weeks I have been changing the keys-certs and configuration
of Postfix a bit, as can be seen from this excerpt of postfix/main.cf
```
# Inbound SMTP connections (Postfix as receiver / server)
smtpd_tls_chain_files =
# /etc/letsencrypt/live/mail.proteamail.com/privkey.pem,
# /etc/letsencrypt/live/mail.proteamail.com/fullchain.pem,
# /etc/letsencrypt/live/mail.proteamail.com-rsa/privkey.pem,
# /etc/letsencrypt/live/mail.proteamail.com-rsa/fullchain.pem
# /etc/letsencrypt/staging/mail.proteamail.com/combo.pem,
# /etc/letsencrypt/staging/mail.proteamail.com-rsa/combo.pem
/etc/postfix/keys/pq.pem,
/etc/postfix/keys/ecdsa.pem,
# Only one of each key type is allowed
# Source: https://www.postfix.org/postconf.5.html#smtp_tls_chain_files
# I chose to keep the LE one in case a badly configure server does not
# accept my self-signed certs and falls back to cleartext.
# /etc/postfix/keys/rsa.pem
/etc/letsencrypt/staging/mail.proteamail.com-rsa/combo.pem
```
I went from
```
smtp_tls_cert_file = /etc/letsencrypt/live/mail.proteamail.com/fullchain.pem
smtp_tls_key_file = /etc/letsencrypt/live/mail.proteamail.com/privkey.pem
```
... to using the `smtpd_tls_chain_files` configuration with individual
files; then the combo files, and, yesterday, postfix-tls generated
self-signed certificates, including an mldsa65 cert as seen at your
server (just for fun, I did not see the harm in using a post-quantum
key-cert).
The leftover tlsa records are from those previous configurations in the
last days/weeks, and will be cleaned up still.
> 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!
Thank you. I hope to get a better grip on things and have it all in
order. As said, with long running certificates (whether they be 100
years, or just 1), this should not be too difficult.
What monitoring do you advice? I use `pflogsumm` which emails me
statistics every day, which I also scan for connection issues.
I check internet.nl every now and then to verify that all is working
well (now that I am poking at this lot).
I could create a script to automatically check that the tlsa records
match the keys. Is there anything else you would suggest?
>>> 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.
Thank you for the advice.
May I ask: If/when you don't use the ML-DSA-65 certificate, you don't
use a postfix-tls certificate either (I think I saw your name in the
man-page?), but a LE certificate? Would you say there is a particular
reason to use a LE or otherwise a CA certificate, over a self-signed
one? I am just trying to understand.
> 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
I have been trying danectl, and been in touch with the author as well! I
got in some murky water because of using (at the time) both an ECDSA and
an RSA certificate for the same server name.
> perhaps more polished IIRC than:
>
> - https://github.com/tlsaware/danebot
This I am currently using.
> 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.
See above for a soft request for suggestions on monitoring.
Thank you again - I can't say it enough - for sharing your expertise!
Kind regards,
Edmund
--
Edmund Lodewijks <[email protected]>
TZ: UCT+2 / GMT+2
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
