curl / Mailing Lists / curl-library / Single Mail


RE: Fetching the detail of SSL Host verification failure

From: Basuke Suzuki via curl-library <>
Date: Mon, 29 Oct 2018 17:33:07 +0000

> > We have an internal review about this and the objection to this was
> > that a client expects OpenSSL error code and it is confusing to return
> > CURLcode into there. That is a reasonable point.
> I think neither of those are suitable for CURLINFO_SSL_VERIFYRESULT. I think
> there should be a new set of codes:
> - The CURLcode enum doesn't have the necessary values to return, plus it would
> be really weird
> - We don't want to make the codes to depend on OpenSSL since other backends
> might want to have more info as well
> - We don't want to risk that OpenSSL changes them in a future when OpenSSL 3.0
> comes
> ...
> Every time the choice of TLS backend shines through and forces the
> application to know about it or behave differently is a step in the wrong
> direction I think.
> [options cut out]
> I'm sorry, but I thought you were going to leave the return codes as-is and
> add values to CURLINFO_SSL_VERIFYRESULT for more detailed info - which
> wasn't even among these options. Now I'm deeply confused!

Oh my. I thought I need to return OpenSSL error code because current code base is doing so.
> lerr = *certverifyresult = SSL_get_verify_result(BACKEND->handle);

So I thought the field is backend dependent and I need to follow this by returning OpenSSL error code.

But what you told above was completely opposite. Now I understand I should return CURLcode by defining a new code.


Basuke Suzuki
Received on 2018-10-29