[openssl-users] Preventing Handshake Termination Because of Unverifiable Client Certificates

Armen Babikyan armen.babikyan at gmail.com
Tue Sep 11 06:09:49 UTC 2018


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

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180910/4b33134e/attachment.html>

More information about the openssl-users mailing list