> From: openssl-users <openssl-users-boun...@openssl.org> On Behalf Of Viktor > Dukhovni > Sent: Thursday, 11 March, 2021 10:39 > To: openssl-users@openssl.org > Subject: Re: Client certificate authentication > > > On Mar 11, 2021, at 2:16 PM, Robert Ionescu <hightronicdes...@gmail.com> > wrote: > > > > I am searching for the functions in openssl used to verify the clients > > certificate when using mutual authentication. > > My intention is to find a way to log a wrong user certificate directly > inside > > the openssl source. > > What does "wrong" mean?
This is an important question. PKIX does not specify the interpretation of the client certificate. While chain construction and most of validity checks (signature, validity dates, basic constraints, KU and EKU, etc) apply, the association between the identity claimed by the certificate and the client is not determined by the standard. Even the form of that association and what is being identified are up to the application. Conventionally, I believe these options are most commonly used: 1. The client certificate identifies the peer system, i.e. the network node that the server is communicating with. This might look symmetric with the client's identification of the server, but it isn't, because a client specifies a server identity (e.g. by hostname) and then verifies that using the server certificate; but in the normal use case, the server has no prior notion of the client system's identity. So the server might get the peer IP address from the stack and then look for an IPADDR SAN in the client's certificate which matches that, for example. The server might also attempt reverse DNS (PTR record) resolution from the IP address to a hostname or FQDN and look for a corresponding DNS SAN or Subject CN, though that option is fraught with potential for abuse. 2. The client certificate identifies the user. Here the certificate is issued to, and identifies, a person or other actor (e.g. the peer application) rather than a network identity. What the server application does with this information is a further question. 3. The client certificate matches a preconfigured allow list: The server application just has some list of "permit any client identified by one of these certificates". 4. The client certificate is validated but beyond that is used as an opaque reference to some other database. This is a variation on #3. IBM's CICS Web Interface provides this mode, where clients can send arbitrary certificates as long as they're valid and belong to a chain that terminates in one of the configured trust anchors. The handshake is completed. Then the system will look that certificate up in the security database to see if it's known and associated with a user identity. If not, the application (or more properly the CWI subsystem) prompts for user credentials using HTTP Basic Authentication (over the TLS channel); if that's successful, the association between client certificate and user account is recorded and the conversation continues. 5. No further vetting of the certificate is done. Essentially the client authentication serves simply as a generic gatekeeper, so that only clients possessing an acceptable certificate are allowed to establish a TLS connection to the server. Any authentication beyond that is handled by the application using other means. So a client certificate can be "wrong" in the basic PKIX sense of "invalid certificate" or "can't build a path", but beyond that the interpretation is up to the server-side application. -- Michael Wojcik
