Client certificate authentication

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Client certificate authentication

hight
Hi,

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.

Any help would be highly appreciated
_______________________________________________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Client certificate authentication

Viktor Dukhovni
> On Mar 11, 2021, at 2:16 PM, Robert Ionescu <[hidden email]> wrote:
>
> I am searching for the functions in openssl used to verify the clients
> certificate when using mutual authentication.

The same code verifies peer certificate chains, whether client or server.

> My intention is to find a way to log a wrong user certificate directly inside
> the openssl source.

What does "wrong" mean?  OpenSSL is a library, it has no business making
decisions like writing log entries, that's an application prerogative, and
any logging of diagnostic or audit trail events should in application code,
not in OpenSSL library code.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Client certificate authentication

Kyle Hamilton
If he's trying to muck with the library, he's probably struggling with a precompiled binary he doesn't have the source code to.

-Kyle H

On Thu, Mar 11, 2021, 11:48 Viktor Dukhovni <[hidden email]> wrote:
> On Mar 11, 2021, at 2:16 PM, Robert Ionescu <[hidden email]> wrote:
>
> I am searching for the functions in openssl used to verify the clients
> certificate when using mutual authentication.

The same code verifies peer certificate chains, whether client or server.

> My intention is to find a way to log a wrong user certificate directly inside
> the openssl source.

What does "wrong" mean?  OpenSSL is a library, it has no business making
decisions like writing log entries, that's an application prerogative, and
any logging of diagnostic or audit trail events should in application code,
not in OpenSSL library code.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

RE: Client certificate authentication

Michael Wojcik
In reply to this post by Viktor Dukhovni
> From: openssl-users <[hidden email]> On Behalf Of Viktor
> Dukhovni
> Sent: Thursday, 11 March, 2021 10:39
> To: [hidden email]
> Subject: Re: Client certificate authentication
>
> > On Mar 11, 2021, at 2:16 PM, Robert Ionescu <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Client certificate authentication

hight
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 <[hidden email]> wrote:
> From: openssl-users <[hidden email]> On Behalf Of Viktor
> Dukhovni
> Sent: Thursday, 11 March, 2021 10:39
> To: [hidden email]
> Subject: Re: Client certificate authentication
>
> > On Mar 11, 2021, at 2:16 PM, Robert Ionescu <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Client certificate authentication

Viktor Dukhovni
On Fri, Mar 12, 2021 at 09:06:57AM +0100, Robert Ionescu wrote:

> 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.

Informal words like "wrong" or "invalid" still don't convey the actual
meaning you have in mind, but in any case, the OpenSSL library provides
callbacks that you can use to track the progress of and report errors
in the certificate verification process.

    SSL_CTX_set_verify(3)
    SSL_set_verify(3)

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Client certificate authentication

hight
I already found the callbacks for the verification process and I am still trying to figure it out if it is possible to change them in a way that they will print some certificate information to determine which certificate was used?
_______________________________________________________________________________
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 Fri, Mar 12, 2021 at 3:39 PM Viktor Dukhovni <[hidden email]> wrote:
On Fri, Mar 12, 2021 at 09:06:57AM +0100, Robert Ionescu wrote:

> 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.

Informal words like "wrong" or "invalid" still don't convey the actual
meaning you have in mind, but in any case, the OpenSSL library provides
callbacks that you can use to track the progress of and report errors
in the certificate verification process.

    SSL_CTX_set_verify(3)
    SSL_set_verify(3)

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Client certificate authentication

Viktor Dukhovni
On Mon, Mar 15, 2021 at 12:23:54PM +0100, Robert Ionescu wrote:

> I already found the callbacks for the verification process and I am
> still trying to figure it out if it is possible to change them in a
> way that they will print some certificate information to determine
> which certificate was used?

What do you mean "change them"?  These are callbacks, you register the
callback function in the application, and then do whatever you want in
that function, including print certificate information, if that's your
goal.  There's nothing to "change".

The verification Postfix uses for optional certificate verification
verbosity is at:

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L139-L185

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Client certificate authentication

hight
Hmm ok I get it.
So, to be able to get the fingerprint for the used certificates during a TLS handshake is possible by using the SSL_set_verify callbacks in the application or is the mentioned postfix useful for this purpose?
_______________________________________________________________________________
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 Mon, Mar 15, 2021 at 12:46 PM Viktor Dukhovni <[hidden email]> wrote:
On Mon, Mar 15, 2021 at 12:23:54PM +0100, Robert Ionescu wrote:

> I already found the callbacks for the verification process and I am
> still trying to figure it out if it is possible to change them in a
> way that they will print some certificate information to determine
> which certificate was used?

What do you mean "change them"?  These are callbacks, you register the
callback function in the application, and then do whatever you want in
that function, including print certificate information, if that's your
goal.  There's nothing to "change".

The verification Postfix uses for optional certificate verification
verbosity is at:

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_verify.c#L139-L185

--
    Viktor.