Re: Asynchronous certificate verification and curl_multi

Here is a proof of concept which currently only works with
curl_multi_socket_action() API so far:
https://github.com/curl/curl/pull/18284

-after asynchronous cert verification is detected, the easy prevents fds
from being scheduled
-when cert verification finishes, the user needs to first call
 curl_easy_setopt(easy CURLOPT_ASYNC_CERT_VERIFY_FINISHED, 1L);
and subsequently call
curl_multi_socket_action(multi, CURL_SOCKET_RETRY_CERT);

It works, but it is pretty crude and ugly; I would be grateful for guidance
regarding which directions to take. The interface changes seem far from
ideal, and in the implementation, especially use
of data->conn->bits.cert_verification_* from cf-socket.c looks like a hack,
and keeping the easy in multi->process during this time seems unclean...

On Wed, Aug 13, 2025 at 9:44 AM Daniel Stenberg <[email protected]> wrote:

> On Wed, 13 Aug 2025, Ondra via curl-library wrote:
>
> > According to https://curl.se/libcurl/c/CURLOPT_SSL_CTX_FUNCTION.html,
> “For
> > OpenSSL, asynchronous certificate verification via
> *SSL_set_retry_verify* is
> > supported. (Added in 8.3.0 <https://curl.se/ch/8.3.0.html>)”, so I have
> > attempted to use this approach; but I have found out, that although when
> I
> > register my callback via SSL_CTX_set_cert_verify_callback and then
> > successfully call SSL_set_retry_verify from it before returning from it
> > indeed ensures that next time the easy handle is processed by
> curl_multi,
> > the verification callback is called again, curl does not seem to do
> anything
> > more.
>
> I think this is simply because this is not widely used nor understood
> functionality. Looking at it now, I think it was unfortunate that we
> accepted
> the change like that. Underdocumented and no test case that verifies it.
>
> Maybe it is broken? Maybe it needs something else to work.
>
> > The issue is that while the asynchronous verification is pending, we
> need
> > for the easy handle to be inert, and when verification finishes, we need
> to
> > resume processing of that handle. Currently it seems that the easy
> handle
> > stays in previous state with regards of sockets scheduled on it’s behalf
> by
> > multi into the eventloop; since this socket can be (and in some cases
> > actually is) triggered (eg. readable) for the whole time, this will lead
> to
> > busy looping (as the cert verify callback is invoked again and again and
> we
> > have to use SSL_set_retry_verify every time).
>
> The question is really what else curl should do. I mean, if it doesn't do
> that
> then when should it call the callback again? I'm afraid I don't know how
> this
> asynch cert thing works in OpenSSL so I can't really tell.
>
> > Please what is the proper way how to handle this issue?
>
> I think it is pretty clear that this is unknown (to most of us). I think
> you
> need to figure that out and possibly provide a patch that makes curl work
> better with this. A test case and an example code would be excellent and
> bring
> bonus points.
>
> --
>
>   / daniel.haxx.se || https://rock-solid.curl.dev

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html