[openssl-users] 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:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_
verify_depth.html#NOTES

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