Preventing Handshake Termination Because of Unverifiable Client Certificates

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Preventing Handshake Termination Because of Unverifiable Client Certificates

Armen Babikyan
Hello,

I have a question regarding openssl and verification of client certificates.  Is there a way to have an openssl-enabled server ask for a client certificate, and when it receives one it can't verify, rather than immediately terminating the handshake, it would allow the connection, but pass some context about the failed verification to the calling application?

It appears that what I want is not possible from the SSL_VERIFY_* options presented here:


My use case is to opportunistically allow connections from VoIP devices, whether or not the clients have certificates I can verify.  Suppose I use the term "blue check" as an internal measure of client trustworthiness/provenance.

1) If the client presents a certificate that I can verify, I want to build some context that gives this client a "blue check".
2) If the client presents a certificate that I can't verify, I want to still allow it to connect, but not have a "blue check" associated with that client.
3) If the client doesn't present a certificate, I want to still allow it to connect, but, as in (2), not have a "blue check"

It seems that the openssl library and documented behavior is artificially limiting me to only allow (1) and (3).  I would like to support scenario (2) as well.

Is the existing behavior intentional, or am I out in left-field with this request?  If the latter, would you consider a patch to implement the behavior in (2), perhaps as an additional param, e.g. SSL_VERIFY_DONTFAIL?  Additionally, it would be great if I could still get some information about the cert presented by the unverifiable client from within my application as well.

Thanks!

Armen

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Preventing Handshake Termination Because of Unverifiable Client Certificates

Viktor Dukhovni


> On Sep 11, 2018, at 2:09 AM, Armen Babikyan <[hidden email]> wrote:
>
> I have a question regarding openssl and verification of client certificates.  Is there a way to have an openssl-enabled server ask for a client certificate, and when it receives one it can't verify, rather than immediately terminating the handshake, it would allow the connection, but pass some context about the failed verification to the calling application?

Yes.

> It appears that what I want is not possible from the SSL_VERIFY_* options presented here:

Actually, SSL_VERIFY_PEER is the right choice, but you also need a
non-null verification callback that continues (by returning 1)
despite failures to verify the client certificate.

You can check the verification status at the completion of the
handshake via SSL_get_verify_result(3).

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Preventing Handshake Termination Because of Unverifiable Client Certificates

Armen Babikyan
Hi Viktor,

I realized that something like this could be an option a few minutes after I hit "send".  Thanks for the confirmation - I'll give this a shot!

Many thanks!

Armen


On Mon, Sep 10, 2018 at 11:19 PM, Viktor Dukhovni <[hidden email]> wrote:


> On Sep 11, 2018, at 2:09 AM, Armen Babikyan <[hidden email]> wrote:
>
> I have a question regarding openssl and verification of client certificates.  Is there a way to have an openssl-enabled server ask for a client certificate, and when it receives one it can't verify, rather than immediately terminating the handshake, it would allow the connection, but pass some context about the failed verification to the calling application?

Yes.

> It appears that what I want is not possible from the SSL_VERIFY_* options presented here:

Actually, SSL_VERIFY_PEER is the right choice, but you also need a
non-null verification callback that continues (by returning 1)
despite failures to verify the client certificate.

You can check the verification status at the completion of the
handshake via SSL_get_verify_result(3).

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Preventing Handshake Termination Because of Unverifiable Client Certificates

Viktor Dukhovni


> On Sep 11, 2018, at 2:25 AM, Armen Babikyan <[hidden email]> wrote:
>
> I realized that something like this could be an option a few minutes after I hit "send".  Thanks for the confirmation - I'll give this a shot!

You should also consider what if anything you want to pass to

        SSL_CTX_set_client_CA_list(3)

See the docs.  Some clients (IIRC Java's TLS stack) don't send any
client certificates unless the server solicits a certificate from
a matching CA, and leaving the list empty may not work for such
clients.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users