Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Asynchronous certificate verification and curl_multi
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ondra via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 13 Aug 2025 09:22:34 +0200
Hello,
I am attempting to implement asynchronous certificate verification for
curl_multi running multiple curl_easy with CURLMOPT_SOCKETFUNCTION set to
use a custom event loop.
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.
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).
Please what is the proper way how to handle this issue? I would expect
clean solution within curl would be for multi to automatically unschedule
all the relevant sockets and only resume processing this handle when either
a dedicated function or at worst curl_multi_perform is invoked.
curl_easy_pause does nothing. According to documentation,
curl_multi_remove_handle can close the underlying connection so does not
look correct to use it. I could unschedule all sockets belonging to
curl_easy that are currently scheduled via CURLMOPT_SOCKETFUNCTION but
according to it’s documentation (
https://curl.se/libcurl/c/CURLMOPT_SOCKETFUNCTION.html) using easy to
identify the handle is not proper. Or is there any other possible approach?
Thanks,
Ondrej
Date: Wed, 13 Aug 2025 09:22:34 +0200
Hello,
I am attempting to implement asynchronous certificate verification for
curl_multi running multiple curl_easy with CURLMOPT_SOCKETFUNCTION set to
use a custom event loop.
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.
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).
Please what is the proper way how to handle this issue? I would expect
clean solution within curl would be for multi to automatically unschedule
all the relevant sockets and only resume processing this handle when either
a dedicated function or at worst curl_multi_perform is invoked.
curl_easy_pause does nothing. According to documentation,
curl_multi_remove_handle can close the underlying connection so does not
look correct to use it. I could unschedule all sockets belonging to
curl_easy that are currently scheduled via CURLMOPT_SOCKETFUNCTION but
according to it’s documentation (
https://curl.se/libcurl/c/CURLMOPT_SOCKETFUNCTION.html) using easy to
identify the handle is not proper. Or is there any other possible approach?
Thanks,
Ondrej
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-08-13