On 6/29/2023 11:29 PM, Windl, Ulrich wrote:

I think there's something missing: When *creating* the certificate "It proves that the bearer owns the DN" (done by RA/CA), but when *using* the certificate (by a client) the server should still check whether the certificate matches the client. Otherwise any stolen certificate could be used to gain access from everywhere. MHO.

When you say "matches the client", what do you mean?  That the client's IP address maps to a name on the certificate?  Remember that in DNS the mapping from IP address to name is under the control of the person who owns the IP address, not the person who owns the name. Remember also that the client may be behind a NAT that hides their IP address.  Finally, remember that the client may legitimately change its IP address and DNS name (if any) from time to time as it is moved from one location to another (think phone, or laptop, or desktop moving from one office to another) or networks are reconfigured around it.

This is asymmetric from the more common server authentication.  For server authentication, the server has a stable name, and that name was supplied by the human and so can be trusted (more or less) and checked against the certificate.  In fact, that human-supplied name serves exactly the same purpose as an "authorized DN" list: it says which certificates are acceptable.

Net... you're absolutely right, if somebody steals your certificate - more precisely, your private key - they can use it to gain access.  It is exactly as for a password: a username and password authenticates the user, but if somebody steals your password, they can masquerade as you.  Depending on your particular scenario, it might be appropriate to have *additional* checks - acceptable networks, et cetera - or require multiple factors (e.g. certificate plus password).  Those additional checks are not part of the certificate-based authentication process.

Somebody stealing your private key may well be Game Over.  Don't let people steal it.