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 DKIM, SPF, DMARC are already very fussy and can be fiddly as it is. 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. 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? 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? 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? -- Christian de Larrinaga