Buy commercial curl support from WolfSSL. 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
himself.
Re: Is CURLSSLOPT_NATIVE_CA still experimental?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ray Satiro via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 5 Jan 2023 22:18:06 -0500
On 1/5/2023 10:08 AM, Jeroen Ooms via curl-library wrote:
> I maintain the R bindings, which are used by a lot of Windows users
> inside corporate/academic networks.
>
> A few years ago, we switched the default-ssl-backend on Windows from
> openssl to schannel. The main motivation was that many corporate
> networks use custom SSL certificates which are stored in the windows
> cert store. By switching to schannel, curl would be able to use these
> certs and we would not have to ship a custom ca-bundle with the
> bindings which always was a pain.
>
> It has worked well, but now I am not considering switching back to
> openssl and enable CURLSSLOPT_NATIVE_CA by default. The reason this
> time is that users want to use nghttp2 and that openssl seems more
> robust than schannel for servers that behave unexpectedly (which sadly
> is common in our field).
>
> However the documentation says CURLSSLOPT_NATIVE_CA (introduced in
> 7.71.0) is experimental and subject to change. Is it safe to use at
> this point? I tried running our tests on a few machines (vista, win-7,
> win-10, and some GHA runners) and it all seems to work. Has anyone
> experienced issues with it, or is aware of edge-cases that I should be
> aware of?
Yes, it's experimental. I don't remember a lot about it. I looked into
it this afternoon and found a bug where CA bundle and path are not used
when CURLSSLOPT_NATIVE_CA is used. I left it undocumented what happens
in that scenario but two years ago I had changed it to function so that
if you use CURLSSLOPT_NATIVE_CA (ie import CAs from from MS "ROOT"
store) then OpenSSL could also verify via CURLOPT_CAINFO,
CURLOPT_CAINFO_BLOB etc. See https://github.com/curl/curl/pull/10244
If you have issues with Schannel we would like to hear about them in
issues. If you switch from Schannel to OpenSSL you will lose certificate
revocation checks. People seem to be split on whether they think
revocation checks are worth the time or necessary. There is an option
for OpenSSL OCSP check but if the certificate doesn't support it then
curl will error. See https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYSTATUS.html
The only other problem I remember is Microsoft allows for duplicate CA
certificates in an individual store and OpenSSL doesn't so when we
import the certificates if there's a duplicate OpenSSL will not take it
and we ignore it. We ignore pretty much anything OpenSSL won't take
rather than error. That may be of some consequence. I really don't know
what MS uses duplicate CA certificates for but I assume they may have
different end dates or something. I did add some code that checks to
make sure a CA certificate is not imported unless it's within its
validity period and properly scoped, so I would think either CA
certificate would work in that case? I just don't know enough about it.
Date: Thu, 5 Jan 2023 22:18:06 -0500
On 1/5/2023 10:08 AM, Jeroen Ooms via curl-library wrote:
> I maintain the R bindings, which are used by a lot of Windows users
> inside corporate/academic networks.
>
> A few years ago, we switched the default-ssl-backend on Windows from
> openssl to schannel. The main motivation was that many corporate
> networks use custom SSL certificates which are stored in the windows
> cert store. By switching to schannel, curl would be able to use these
> certs and we would not have to ship a custom ca-bundle with the
> bindings which always was a pain.
>
> It has worked well, but now I am not considering switching back to
> openssl and enable CURLSSLOPT_NATIVE_CA by default. The reason this
> time is that users want to use nghttp2 and that openssl seems more
> robust than schannel for servers that behave unexpectedly (which sadly
> is common in our field).
>
> However the documentation says CURLSSLOPT_NATIVE_CA (introduced in
> 7.71.0) is experimental and subject to change. Is it safe to use at
> this point? I tried running our tests on a few machines (vista, win-7,
> win-10, and some GHA runners) and it all seems to work. Has anyone
> experienced issues with it, or is aware of edge-cases that I should be
> aware of?
Yes, it's experimental. I don't remember a lot about it. I looked into
it this afternoon and found a bug where CA bundle and path are not used
when CURLSSLOPT_NATIVE_CA is used. I left it undocumented what happens
in that scenario but two years ago I had changed it to function so that
if you use CURLSSLOPT_NATIVE_CA (ie import CAs from from MS "ROOT"
store) then OpenSSL could also verify via CURLOPT_CAINFO,
CURLOPT_CAINFO_BLOB etc. See https://github.com/curl/curl/pull/10244
If you have issues with Schannel we would like to hear about them in
issues. If you switch from Schannel to OpenSSL you will lose certificate
revocation checks. People seem to be split on whether they think
revocation checks are worth the time or necessary. There is an option
for OpenSSL OCSP check but if the certificate doesn't support it then
curl will error. See https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYSTATUS.html
The only other problem I remember is Microsoft allows for duplicate CA
certificates in an individual store and OpenSSL doesn't so when we
import the certificates if there's a duplicate OpenSSL will not take it
and we ignore it. We ignore pretty much anything OpenSSL won't take
rather than error. That may be of some consequence. I really don't know
what MS uses duplicate CA certificates for but I assume they may have
different end dates or something. I did add some code that checks to
make sure a CA certificate is not imported unless it's within its
validity period and properly scoped, so I would think either CA
certificate would work in that case? I just don't know enough about it.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-01-06