Join GitHub today
openssl: fix CURLINFO_SSL_VERIFYRESULT #995
CURLINFO_SSL_VERIFYRESULT does not get the certificate verification result when SSL_connect fails because of a certificate verification error. This fix saves the result of SSL_get_verify_result so that it is returned by CURLINFO_SSL_VERIFYRESULT.
I don't see where it's documented that we can get X509_V_ERR stuff from SSL_connect. The only place I see it documented is SSL_get_verify_result which we use already but that early it's just going to return ok I suspect (untested). Can you give more detail and tell us what you see happening that led you to make this change?
I am trying to access a https uri with CURLOPT_SSL_VERIFYPEER set to 1. When this option is enabled, curl calls SSL_CTX_set_verify with mode set to SSL_VERIFY_PEER. SSL_VERIFY_PEER causes the SSL_connect call to fail if any certificate verification errors are encountered during the SSL/TLS handshake. The caller is expected to call SSL_get_verify_result to get more details about the verification failure. The various verification failure codes are documented at verify.
I'm simulating various scenarios in which the SSL handshake can fail.
In both of the above scenarios, with existing code, CURLINFO_SSL_VERIFYRESULT returns an incorrect value of 1. This is the default value
Additionally, the existing code where
Indeed you are correct and thank you for the thorough explanation. I had skimmed your changes and thought you were assigning the SSL_connect return code to ssl.certverifyresult, which I can see now is not what you're doing. I agree this is a bug.
Thank you for your fix. It has landed and you'll notice I modified it slightly because ssl.certverifyresult should not be set to X509_V_OK(0) in the case of SSL_R_CERTIFICATE_VERIFY_FAILED which apparently could happen. We initialize ssl.certverifyresult to 1 by default because that error code is not used and that is the way it should stay in that case.