On 5/17/25 7:56 PM, brent saner via NANOG wrote:
SMTPS/SMTP + STARTTLS for MTA MTA does not use id-kp-clientAuth EKU, which is what they're deprecating/removing.
I hope that's the case. But I have questions. Do MTAs actually check the presence of the id-kp-serverAuth and / or id-kp-clientAuth Extended Key Usage value? I don't know. If they do, will they continue to do so in the future? Or will the have a new option to treat id-kp-serverAuth akin to id-kp-clientAuth? I don't know. Time will tell.
Certs are used on MTAs for *identity verification of the server* and *integrity validation/encryption*, not authentication.
I question the veracity of that. What is the difference between "identity verification of the server" and "authentication (of the server's identity)"? -- I wonder if you were going for "authorization", not "authentication". N.B. the Extended Key Usage values "id-kp-serverAuth" and "id-kp-clientAuth" only differ in that one is "server" and the other is "client". So it really seems like it's the same process, just done to two different entities; "server" vs "client". Per the OID Repository, the "auth" is "authentication", not authorization. I have, and know multiple other people that also have, servers authenticate to other servers using the local server's Let's Encrypt certificate. This is particularly nice for servers at client offices that are on dynamic IPs. The server already has a local Let's Encrypt certificate for various web related things. So why not re-use that certificate for other things like authenticating to the corporate SMTP server and / or the corporate VPN server. Last time I checked, certificate based authentication was considerably stronger than username and password based authentication. What's more is that with certificates, each server only needs to keep it's own certificate private key safe. Other servers don't have to keep anything safe on it's behalf. The same can't be said for passwords. Once you have verified / authenticated identity, then you can start doing interesting things with authorization. -- After all, that's what's often done with the weaker username & password based authentication.
It is strictly only used for *authenticating clients*, hence the name, in mTLS (or *client*-driven one-way TLS, which I don't think I've ever actually seen in the wild to my knowledge).
I think what is a client vs server may be a bit surprising. The role of "server" and "client" can, and does, changes depending on who's initiating the connection. A system that was the server receiving an email becomes the client when sending it onward seconds later. It's the same system and has the same certificate to authenticate itself. Which end of the site-to-site VPN tunnel is the server and the client? Does your answer change if one end reboots? What about the other end? Darn cleaning crew and their evil vacuums. - local office SMTP relay is a client to the corporate SMTP relay - site-to-site VPN has both a server (responder) and a client (initiator) - sometimes the difference is which one rebooted / tried to initiate the connection most recently. I see TLS certificates from Let's Encrypt, et al., used for both of these roles.
The only case this would matter is if you are using an MUA/sender/client *authenticating* to an MTA with a certificate.
I see that exact thing happening. I see very similar things happening with VPNs. A quick search makes me think that VoIP a la. SIP-TLS / SRTP will also make use of TLS. It didn't take long at all to find the following phrase in a Cisco document "Support introduced for CN-SAN validation of client certificate." That sure sounds like it's in the mTLS ballpark to me.
99.999% of email is one-way server TLS, not mTLS. LE certs will continue to work fine for SMTP.
99.999% of 375 billion emails per day (found from a quick search) still leaves several million messages per day that use mutual TLS. I'm one of many on mailop mailing list having a lively discussion about this. I suspect that Google's actions and Let's Encrypt's et al. re-actions will either have zero impact because software won't care about / check the id-kp-serverAuth and / or id-kp-clientAuth -or- it will have a much larger impact than people realize. -- Grant. . . .