On Thu, May 22, 2025 at 2:58 PM John Levine via NANOG <nanog@lists.nanog.org> wrote:
It is my impression that the normal way to manage client certs is for the organization that runs the servers to sign and distribute certs to the clients. This isn't new.
Small private CAs per organization are perfect when the same organization runs both client and server; such as client certificates for EAP-TLS with 802.1X wireless auth. Software designed for client auth scenarios does not trust random certificates from a public CA. The cert has to allow the appropriate EKUs, but also it must be manually mapped to the active directory user by an admin, or be signed by a specific CA which is configured on the server. This does not work for applications where the client authentication is between servers at different organizations. Such as the SMTP server or Web server which wishes to connect to another company's SMTP server or Web server using mutual TLS to verify the web server FQDN for authentication to send mail or access an API endpoint as that server's identiy. Companies are not going to add a million other companies' private CAs to their system trust roots list. For the SMTP to SMTP transport associations the two organizations may barely know each other. And the whole purpose of the public CAs is to help establish server authenticity for these kind of scenarios.
R's, John -JA