Re: Asynchronous certificate verification and curl_multi

Hello,
Since I do not really know the code it is hard for me to say whether simply
running curl_multi_socket_action with CURL_SOCKET_TIMEOUT would work and be
an acceptable solution for you, or whether adding something new
(CURL_SOCKET_RETRY_CONNECT similar to CURL_SOCKET_TIMEOUT?) would be the
correct approach. Additionally both of these solutions only work for
curl_multi, although I think that for curl_easy_perform most people will
just block within the callback...
Ondrej

On Wed, Aug 13, 2025 at 11:58 AM Stefan Eissing via curl-library <
[email protected]> wrote:

>
>
> > Am 13.08.2025 um 09:44 schrieb Daniel Stenberg via curl-library <
> [email protected]>:
> >
> > 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.
>
> We have the detection of a SSL_ERROR_WANT_RETRY_VERIFY and can in that
> case suppress the connection socket for polling. The question is how would
> the application tell libcurl that it is read to give it another try? That
> seems to be mostly missing.
>
> - Stefan
>
> >
> > --
> >
> > / daniel.haxx.se || https://rock-solid.curl.dev--
> > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> > Etiquette:   https://curl.se/mail/etiquette.html
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette:   https://curl.se/mail/etiquette.html
>

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