On Sat, Nov 22, 2025 at 05:11:08PM +0200, Edmund Lodewijks via Postfix-users wrote:
> > > 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. And still needs some elaboration :-) > 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). What you've misunderstood is that the relative order of these chains has no significance. It is ultimately a *set* of chains not a *sequence*. > I understand that a TLS handshake can only use one such key-cert > combination. Based on the intersection of the client and server's lists of supported signature algorithms (TLS library settings) which set the preference order and limit what's allowed in principle while the server's list of configured certificate chains which limit what's available. > 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?". No. The TLS Client Hello sends an up front ordered list of supported signature algorithms, the server knows its ordered list of supported signature algorithms. The server computes an ordered intersection based on either its own or the client's preference order, and then chooses the first algorithm for which a key+certificate is available. > 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. No multiple rounds. The server chooses a mutually supported cert in one go. The choice depends on the above ordered lists, not on the relative order of the consistuent key + certs chains in the Postfix "chain files". > This "negotiation" does perhaps not happen, as I take it from your email. TLS definitely negotiates supported algorithms. The details are noticeably different in TLS 1.3 vs. prior versions, but this is not important. > > 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. That's still an incorrect mental model. Yes, you'd need multiple chains if there weren't at least one algorithm that all clients can be expected to support. Fortunately, all clients that expect to communicate on today's Internet support both RSA and ECDSA, since a large fraction of servers have certificates for one of these and not the other. So in practice, for most users, your "chain files" should have just an RSA (2048-bit) or just an ECDSA (P-256) certificate. You don't need multiple chains, unless you're particularly sophisticated in your needs and understanding. > With 100year certs (`postfix-tls`), once it's set up, it should be good > for a while? So long as your key is not compromised, and the "quantum apocalypse" has not yet arrived. I am personally sceptical that CRQCs (cryptographically relevant quantum computers) are imminent, but time will tell... > # 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 > ``` That does not work, because so long as one of the configured algorithms has a self-signed cert, at least some clients will only see a self-signed cert. If you care about the mostly hypothetical clients that give up when the cert is self-signed, *all* your certs need to be from a CA trusted by all potential clients. > ``` > 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). Well, ML-DSA-65 is novel cryptography, that has not yet withstood decades of cryptanalysis, so a number of reputable experts in this space are recommending caution. That said, future or even current compromise of authentication-only keys is far from tragic, unlike the case with key-exchange keys that protect confidentiality of past traffic. If someone can break an ML-DSA-65 key, that's only useful for impersonating your server in the future, and they'd need to divert the traffic of interest to their own servers (man-in-the-middle attack) to take advantage of the compromise. So in practice, unless you're a very high priority target for nation-state security agencies, even if they break ML-DSA-65, they'd probably put the requisite multi-billion-dollar resources to use to attack something more important than your personal SMTP server. > What monitoring do you advice? I use `pflogsumm` which emails me > statistics every day, which I also scan for connection issues. That will not have anything relevant. You need to make frequent (at least hourly would be my advice) connections to each IP address of each MX host, testing in turn each supported signature algorithm making sure that the presented certs/keys match the TLSA records. You can use some variant of my "danesmtp" bash function, https://list.sys4.de/hyperkitty/list/[email protected]/message/6723WDBLPYWSXAORTAJR7EPAIOFAP5N4/ which is just a thin wrapper around openssl-s_client(1). Looping over MX hosts, IP addresses and signature types would be up to you, that function tests just one connection with one signature algorithm preference list. > I check internet.nl every now and then to verify that all is working > well (now that I am poking at this lot). With multiple cert chains, they're not quite as comprehensive as needed, and at the same time they set the bar too high in many cases. I am not a fan of their emphasis on mitigating entirely impractical attacks, while not paying enough attention to operational diligence. > I could create a script to automatically check that the tlsa records > match the keys. Is there anything else you would suggest? That's the thing to do, and make sure when something is wrong, you get notified in a timely manner, and that the notification mechanism works reliably even when the DANE TLSA records are broken. Some sites have DANE-validated internal relay hops, and when DANE breaks at least the email notices from the survey don't get through because DANE is broken downstream of the initial delivery from the survey's SMTP client, which tolerates broken DANE. > 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. With my LE "renewal.conf" having: [renewalparams] reuse_key = True ... And "3 1 1" records, and "danebot" making sure that matching TLSA records have been in place long enough before new LE certs move from "staging" to "live", there's no downside to an LE cert, and the LE cert is useful on ports 587/465, so I am also using the same one on port 25. None of the MUAs (thunderbird, Mail.app on iPhones, ...) currently support ML-DSA-65, so it can be preferred for now. If and when the MUAs support ML-DSA-65, I'll need to tweak the signature algorithm preference on those ports to use it only as a last resort or not at all. -- Viktor. 🇺🇦 Слава Україні! _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
