With "wrong" certificate I meant "invalid certificate".
So the idea was in a bigger environment with a lot of certificates, to make
the invalid certificate debugging easier by getting more information from
openssl to identify the invalid certificate easier.
My research is based on this reported issue
https://github.com/haproxy/haproxy/issues/693
_______
Robert Ionescu
*The information contained in this message is confidential and may be
legally privileged. The message is intended solely for the addressee(s). If
you are not the intended recipient, you are hereby notified that any use,
dissemination, or reproduction is strictly prohibited and may be unlawful.
If you are not the intended recipient, please contact the sender by return
e-mail and destroy all copies of the original message.*
On Thu, Mar 11, 2021 at 8:40 PM Michael Wojcik <
michael.woj...@microfocus.com> wrote:
> > From: openssl-users 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
>
