Topic: Apache with CURL support for using Windows CA with OpenSSL

[tangent]

This topic should be read in conjuction with HOWTO "Building Apache and dependencies using CMake" - https://www.apachelounge.com/viewtopic.php?t=8609

This follow-up post covers some issues relating to building CURL, which may be of interest to Apache Lounge users, on the basis that support libraries and binaries built alongside Apache may be used for other purposes too, particularly CURL.

To deliver its various features, CURL supports a number of different SSL backends, but notably for Apache on Windows we currently need it to use Schannel (formerly WinSSL) rather than OpenSSL. This is primarily for correct operation of module mod_md.

However, features such as Proxy-HTTPS are not currently supported by Schannel, but rather depend on OpenSSL as confrmed by the CURL CMakeLists.txt file which contains the following entry:

_add_if("HTTPS-proxy" SSL_ENABLED AND (USE_OPENSSL OR USE_GNUTLS OR USE_NSS))

so it's tempting to build CURL supporting both SSL backends.

Unfortunately though, if both are present, when built with CMake, by default CURL (7.74.0 at least) appears to choose OpenSSL over Schannel, which is why initially the CMake options for building CURL (in topic "Building Apache and dependencies using CMake" ) had the CMAKE_USE_OPENSSL option set to OFF.

Delving deeper into this Schannel vs OpenSSL issue, the following CURL mailing list page is of interest - https://curl.se/mail/lib-2020-07/0017.html
This describes options to tell CURL which backend SSL function to use, either by setting an environment variable or by code calling libcurl function curl_global_sslset().

Compiling a version of CURL with both OpenSSL and Schannel functions present, the environment variable method of choice produces the following:

[tangent]

These comments relate to CURL V7.74. See https://github.com/curl/curl/pull/5657 for developer discussion over this specific issue.

Further to the above post over building CURL with CMake, I've been investigating why CURL built with OpenSSL doesn't support using the Windows Certificate Authority (CA) store when trying to resolve certificate chains, as confirmed in the above failed lookup to https://acme-v02.api.letsencrypt.org/directory

This affects CURL library functions (as much as command line CURL), since we know Apache module mod_md fails to contact the Let's Encrypt servers if CURL is built with OpenSSL support.

The above developer thread discusses using the CURLSSLOPT_NATIVE_CA option to resolve this, but to do this would mean patching and updating code which calls the CURL libraries, e.g. mod_md. Surprisingly there's no documented way of setting this option as a CURL default.

So rather than altering calling code, I've been looking into options to patch CURL to achieve this, and the following small change to lib\url.c does the trick.

[nono303]

Hi @tangent,
Many thanks for this usefull post!
- here is a another discussion on the curl ssl backend for windows mod_md https://github.com/icing/mod_md/issues/14
- my actual curl build batch https://github.com/nono303/win-build-scripts/blob/master/modules/curl-sub.bat for winssl (httpd) and openssl (php)
----
Just applied your lib\url.c patch, compile curl & test:
all works fine for a Let's Encrypt domain certificate renewing with mod_md
binaries used for testing available here https://github.com/nono303/mod_md/tree/master/vs16/x64-avx/curl-openssl
fyi had same logs as yours:

[tangent]

Thanks nono303 - I'm really pleased this patch works for you too.

Maybe we could offer this suggestion to the CURL developers (I have no connection with them though).

[admin]

In the past I used the mailing list https://curl.se/mail/list.cgi?list=curl-library

Good and fast response.

[Jan-E]

[tangent]

That's a worthy trick, accepting you have to build CURL twice, if you want both static and dynamic libraries.

My wish was to support OpenSSL as well as Schannel, with both library variants, whilst accepting that CURL favours OpenSSL if both SSL backends are specified in the build.

[nono303]

Hi @Jan-E