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.
Re: Asynchronous certificate verification and curl_multi
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 13 Aug 2025 11:57:39 +0200
> Am 13.08.2025 um 09:44 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
>
> 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
Date: Wed, 13 Aug 2025 11:57:39 +0200
> Am 13.08.2025 um 09:44 schrieb Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>:
>
> 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.htmlReceived on 2025-08-13