On Mon, May 19, 2025, 05:44 Christian de Larrinaga via NANOG < nanog@lists.nanog.org> wrote:
Chris Adams via NANOG <nanog@lists.nanog.org> writes:
Once upon a time, William Herrin <bill@herrin.us> said:
On Sat, May 17, 2025 at 4:23 PM Colin Constable via NANOG <nanog@lists.nanog.org> wrote:
Is anyone else worried about this? We use public certs for client auth in a number of cases.
https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/
Does seem like it might have an impact on SMTP...
Who is using Let's Encrypt web server certs for SMTP client authentication?
I am quite extensively - I should note that several hosting scripts that deploy web/email/mysql etc services LAMP stacks etc use the tls cert provided to the domain hosted on a "server" also for smtp servers with a dotted line to mailman where that is also installed. Those certs aren these days almost always going to be Lets Encrypt
Your users send mail with a Let's Encrypt *client certificate*? Meaning they log into the SMTP server to gain the ability to send *originating mail* with an LE cert? (MUA -> MTA) I'd recommend they not do that. Use a private CA for clients if you're doing mTLS auth. If they are simply using TLS to connect to the mail server and logging in with a username/password instead of/and don't need a *client certificate*, they *aren't* using LE certs for authentication and are wholly unaffected by this change. This is wholly different from delivering mail to other domains (MTA -> MTA). That doesn't use id-kp-clientAuth at all whatsoever either, and has been pointed out, most CAs never even issued certs with it set. You'll be fine.
DKIM, SPF, DMARC are already very fussy and can be fiddly as it is.
True, but a welcome change IMHO. They really do cut down on spam and rogue SMTP.
I don't see the benefit in having separate certs for each application on a domain/zone beyond having yet another "vital" thing to be broken and so having to keep an eye on with all the hassle and cost that can imply.
You don't need to, you can reuse certs for multiple services if you have multiple running within the same identity (typically FQDN). This change literally only affects *mTLS*, which very few implementations use. If you were using it, you'd know you were using it.
Also I am not entirely clear what the implications of this change means as it is not spelt out. Will we have to setup a private PKI for each smtp / domain instance once LE bows to the will of the great google thought policeman in its cloud?
Nope. You'll be fine using LE certs for SMTP. You're only affected if doing mTLS for SMTP, and if you are you'd know you are. If so are there any tooling / scripts / I can add to keep continuity?
e.g., acme equivalent to self generate a cert and will this be recognised as a valid cert rather than fall into the self signed ghetto that the web browser CA lists like to shove the rest of us into?
"Valid" and "verified" are kind of tricky in TLS/X.509. The reason LE certs are valid in browsers, mail client software, etc. is because their intermediate is signed as an issuer by the ISRG root. The ISRG root is recognized as a trusted authority by most/all devices' trust stores. (This is why you need to include the intermediate cert AND the leaf or "server" certificate -- so the remote end has a complete "chain" to verify.) In other words, device A has ISRG root certificate installed and trusted. ISRG signs LE's certificate and grants it issuer. LE's certificate then sign your server's certificate (the leaf). For a private CA to be trusted, you'd need to petition each and every trust store distributor to include your root as something called a trust anchor. Mozilla, Google, Apple, and Microsoft are generally the ones that'd get you the most coverage (Linux distros usually use Mozilla's, etc. for their system trust store). This is...a process. A long, arduous process and each trust store distributor has their own rigorous set of rules (like Google now requiring that issued leaf certs not have id-kp-clientAuth set). The alternative is to explicitly add your root as a trusted anchor to *each device*. This is easy in a corporate environment through config management, GPOs, etc. but good luck with the public at-large. (Sidenote, you should only install and trust roots you are confident are safe. Private CAs are what make transparent proxies able to decrypt HTTPS traffic to domains the org does not own, for instance.) So TL;DR: no. There's not just some script or tool you can run to get your private CA added as a "wide-trust"/"widely-trusted" anchor.
It also begs a question. If running one's own certs authority pki for email, apps, messaging, tunnels and so on are so great why not great for my websites and web apps as well?
It's great for *intranet*, which is where you'd typically find mTLS/mTLS auth. For public-facing, you want a cert from a wide-trust (or one of its intermediates- like Let's Encrypt) because you do not have the ability to install an anchor on foreign/general public devices. (For good reason.)