Nobody is making you buy certificates to authenticate to an API. You'd get a certificate file the same way you'd get an API key, from whatever portal you're gai

Nobody is making you buy certificates to authenticate to an API. You'd get a certificate file the same way you'd get an API key, from whatever portal you're gaining access from. Nobody is trusting random PKI certificates to access APIs. You also don't need any special certificates. The authentication certificates you hand out to API clients can be self-signed if that's what you want, but you probably want an internal CA of some kind to hand out/revoke certificates the same way you have some kind of API key storage. You're right that the browser UI is pretty terrible. Especially on Firefox, I should add, which decides to maintain its own key store. On all other platforms you just open the certificate and hit next a few times and you should be good. As for picking the identity to use, there are easy ways in the TLS protocol to signal what certificates qualify, and there's no way you're going to have multiple certificates signed by the same Acme Corp Ltd. with private key 0xffaabb... Websites that aren't set up correctly will prompt users for a certificate to use, but that's the other websites' fault, as well as the browser's to be honest. Client certificates work fine. They work so well, that they've been reinvented and stuffed into JWT, but now in weird JSON. Various Kubernetes overlay systems use auto-provisioned client certificates to ensure confidentiality and authentication between pods (the cloud world calls it mTLS though).