logo
Apache Lounge
Webmasters

 

About Forum Index Downloads Search Register Log in RSS X


Keep Server Online

If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.

or

Bitcoin

A donation makes a contribution towards the costs, the time and effort that's going in this site and building.

Thank You! Steffen

Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
Post new topic   Forum Index -> How-to's & Documentation & Tips View previous topic :: View next topic
Reply to topic   Topic: Apache with CURL support for using Windows CA with OpenSSL
Author
tangent
Moderator


Joined: 16 Aug 2020
Posts: 305
Location: UK

PostPosted: Mon 08 Feb '21 19:19    Post subject: Apache with CURL support for using Windows CA with OpenSSL Reply with quote

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:
Code:
C:\Apache24\bin>set CURL_SSL_BACKEND=schannel
C:\Apache24\bin>curl -V
curl 7.74.0 (Windows) libcurl/7.74.0 (OpenSSL/1.1.1i) Schannel zlib/1.2.11 brotli/1.0.9 nghttp2/1.42.0
Release-Date: 2020-12-09
Protocols: dict file ftp ftps gopher http https imap imaps ldap mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS HTTP2 IPv6 Kerberos Largefile MultiSSL NTLM SPNEGO SSL SSPI Unicode alt-svc brotli libz

Note the HTTPS-proxy feature is missing with Schannel selected whilst Lets' Encrypt API endpoint lookups work as expected.
Code:
C:\Apache24\bin>curl https://acme-v02.api.letsencrypt.org/directory
{
  "Pll43M9mMos": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "website": "https://letsencrypt.org"
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
}

Changing the environment variable to select OpenSSL gives the following, which now details the HTTPS-Proxy feature:
Code:
C:\Apache24\bin>set CURL_SSL_BACKEND=openssl
C:\Apache24\bin>curl -V
curl 7.74.0 (Windows) libcurl/7.74.0 OpenSSL/1.1.1i (Schannel) zlib/1.2.11 brotli/1.0.9 nghttp2/1.42.0
Release-Date: 2020-12-09
Protocols: dict file ftp ftps gopher http https imap imaps ldap mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile MultiSSL NTLM SPNEGO SSL SSPI Unicode alt-svc brotli libz

However, the Lets' Encrypt API endpoint lookups no longer work (or equally any others), without allowing insecure connections (-k option):
Code:
C:\Apache24\bin>curl https://acme-v02.api.letsencrypt.org/directory
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Hence the initial decision to compile CURL without OpenSSL support on Windows.
Note in both of the above, the surrounding parentheses denote the secondary SSL backend.

One would have thought on Windows CURL would favour Schannel over OpenSSL if both are present, but the code in function curl_global_sslset() (file vtls.c) shows why this isn't the case. In the absence of any specific CURL_SSL_BACKEND environment variable, the struct for *available_backends[] selects OpenSSL before Schannel.

So if OpenSSL is the selected backend, what's the reason why the Let's Encrypt API endpoint and other HTTPS lookups fail?

In practice, what appears to happen here is the OpenSSL libraries don't use the Windows native Certificate Authority (CA) store by default, and consequently fail to resolve a trusted certificate chain. Indeed, OpenSSL doesn't trust anything by default.

Digging further, the CURL developers have evidently considered this issue, and recently introduced an SSL connect option called CURLSSLOPT_NATIVE_CA, to access the Windows CA store in conjunction with the OpenSLL libraries (the following threads are of interest: https://github.com/curl/curl/pull/5585 and https://github.com/curl/curl/pull/5657). This option is mentioned in the release CHANGES file, but states it may not be present going forward.

However, there's no obvious way to set this option as a default during the build process, and since it's subject to change, it doesn't make sense to patch the code to force this option with OpenSSL connections.

So should you wish to build CURL on Windows with OpenSSL support, short of contacting the CURL developers, what options are there for Apache users?

a) build the CURL source ensuring Schannel is the default SSL backend on Windows
b) patch and build mod_md code to call curl_global_sslset() selecting Schannel over the OpenSSL default that Curl currently adopts
c) patch and build CURL to ensure on Windows OpenSSL uses the native CA store by default
d) change nothing and use the CURL_SSL_BACKEND environment variable to determine the preferred SSL backend at run time

You can see why the current view is to omit OpenSSL when building CURL.

Should you wish to make change a), this can be done by defining macro CURL_DEFAULT_SSL_BACKEND="Schannel" as a compile option at build time. Due to problems with embedded double quotes, this is easier to do with a patch to the CMakeLists.txt file, rather than trying to pass command line parameters to CMake in the build batch file. The following change to the build CURL section covers this change:
Code:
rem ------------------------------------------------------------------------------
rem
rem CURL - have to build twice to get both shared and static libs.

rem Check for package and switch to source folder.
rem
call :check_package_source %CURL%

if !STATUS! == 0 (
  set CURL_CMAKE_OPTS=-DCMAKE_INSTALL_PREFIX=%PREFIX% -DCMAKE_BUILD_TYPE=%BUILD_TYPE% -DCMAKE_USE_OPENSSL=ON -DCMAKE_USE_SCHANNEL=ON -DCURL_WINDOWS_SSPI=ON -DCURL_BROTLI=ON -DUSE_NGHTTP2=ON -DENABLE_UNICODE=ON -DINSTALL_MSVC_PDB=%INSTALL_PDB% -DCURL_STATIC_CRT=OFF

  rem Patch CMakeLists.txt to add compiler defines we can't pass through the CMake command line,
  rem primarily due to Windows batch file limitations with embedded double quotes. Definitions are
  rem default SSL backend to SChannel, and set USE_TLS_SRP option.
  rem
  perl -pi.bak -e ^" ^
      s~(USE_OPENSSL ON\^)^)\n~${1} \n  add_definitions(-DCURL_DEFAULT_SSL_BACKEND=\x22schannel\x22^;-DUSE_TLS_SRP^)\n~m; ^
      ^" CMakeLists.txt

  call :build_package %CURL% "!CURL_CMAKE_OPTS! -DBUILD_SHARED_LIBS=OFF" & if not !STATUS! == 0 exit /b !STATUS!
  call :build_package %CURL% "!CURL_CMAKE_OPTS! -DBUILD_SHARED_LIBS=ON" & if not !STATUS! == 0 exit /b !STATUS!
)
Back to top
tangent
Moderator


Joined: 16 Aug 2020
Posts: 305
Location: UK

PostPosted: Mon 08 Feb '21 19:21    Post subject: Reply with quote

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.
Code:
--- a/lib/url.c Tue Dec 08 07:39:35 2020
+++ b/lib/url.c   Tue Jan 26 19:31:41 2021
@@ -577,6 +577,14 @@
     result = Curl_setstropt(&set->str[STRING_SSL_CAPATH_PROXY], CURL_CA_PATH);
     if(result)
       return result;
+#endif
+#if defined(USE_WIN32_CRYPTO)
+    /* Mandate Windows CA store to be used */
+    if(!set->ssl.primary.CAfile && !set->ssl.primary.CApath) {
+      /* User and environment did not specify any CA file or path.
+       */
+      set->ssl.native_ca_store = TRUE;
+    }
 #endif
   }

Note this code in url.c only applies when the selected CURL SSL backend is not Schannel, and a CA file or path hasn't been explicitly set.

The following revised CURL build section (with Perl patch) can be used in the above CMake build_all.bat, if you wish to try out this feature supporting both OpenSSL and Schannel.
Code:
rem ------------------------------------------------------------------------------
rem
rem CURL - have to build twice to get both shared and static libs.

rem Check for package and switch to source folder.
rem
call :check_package_source %CURL%

if !STATUS! == 0 (
  rem Patch lib\url.c to force use of native CA store on Windows.
  rem
  perl -0pi.bak -Mopen=OUT,:raw -e ^" ^
    s~(return result;\n#endif$^)\n  }~${1} \n#if defined(USE_WIN32_CRYPTO^)\n^
    /* Mandate Windows CA store to be used */\n^
    if(\x21set-\x3Essl.primary.CAfile \x26\x26 \x21set-\x3Essl.primary.CApath^) {\n^
      /* User and environment did not specify any CA file or path.\n^
       */\n^
      set-\x3Essl.native_ca_store = TRUE;\n^
    }\n#endif\n  }~smg; ^
    ^" lib\url.c

  set CURL_CMAKE_OPTS=-DCMAKE_INSTALL_PREFIX=%PREFIX% -DCMAKE_BUILD_TYPE=%BUILD_TYPE% -DCMAKE_USE_OPENSSL=ON -DCMAKE_USE_SCHANNEL=ON -DCURL_WINDOWS_SSPI=ON -DCURL_BROTLI=ON -DUSE_NGHTTP2=ON -DHAVE_LDAP_SSL=ON -DENABLE_UNICODE=ON -DINSTALL_MSVC_PDB=%INSTALL_PDB% -DCURL_STATIC_CRT=OFF

  call :build_package %CURL% "!CURL_CMAKE_OPTS! -DBUILD_SHARED_LIBS=ON" & if not !STATUS! == 0 exit /b !STATUS!
  call :build_package %CURL% "!CURL_CMAKE_OPTS! -DBUILD_SHARED_LIBS=OFF" & if not !STATUS! == 0 exit /b !STATUS!
)

Also note the addition of CMake option HAVE_LDAP_SSL, which persuades the build under CMake to add support for LDAPS connections.
Code:
C:\Apache24\bin>curl -V
curl 7.74.0 (Windows) libcurl/7.74.0 OpenSSL/1.1.1i (Schannel) zlib/1.2.11 brotli/1.0.9 nghttp2/1.42.0
Release-Date: 2020-12-09
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile MultiSSL NTLM SPNEGO SSL SSPI Unicode alt-svc brotli libz

Testing confirms this feature works (Schannel based).

I'm currently unable to check whether mod_md works fully with this revised OpenSSL support, since I don't have a working site with certificates registered through Let's Encrypt. But this extract from the Apache error log confirms we're able to connect and verify the Let's Encrypt certificate. Unlike before, the CURL command line level also connects with this patch in place.
    [Sun Jan 24 19:31:37.470182 2021] [md:debug] [pid 7556:tid 584] md_acme.c(769): get directory from https://acme-v02.api.letsencrypt.org/directory
    [Sun Jan 24 19:31:37.470461 2021] [md:trace3] [pid 7556:tid 584] md_curl.c(322): req[0]: GET https://acme-v02.api.letsencrypt.org/directory
    [Sun Jan 24 19:31:37.488465 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info Trying 172.65.32.248:443...\n
    [Sun Jan 24 19:31:37.494963 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)\n
    [Sun Jan 24 19:31:37.494963 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info ALPN, offering h2\n
    [Sun Jan 24 19:31:37.494963 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info ALPN, offering http/1.1\n
    [Sun Jan 24 19:31:37.496130 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info successfully imported windows ca store\n
    [Sun Jan 24 19:31:37.496130 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info TLSv1.3 (OUT), TLS handshake, Client hello (1):\n
    [Sun Jan 24 19:31:37.648176 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info TLSv1.3 (IN), TLS handshake, Server hello (2):\n
    [Sun Jan 24 19:31:37.648176 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info TLSv1.2 (IN), TLS handshake, Certificate (11):\n
    ...
    ...
    [Sun Jan 24 19:31:37.726763 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384\n
    [Sun Jan 24 19:31:37.726763 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info Server certificate:\n
    [Sun Jan 24 19:31:37.726763 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info subject: CN=acme-v01.api.letsencrypt.org\n
    [Sun Jan 24 19:31:37.726763 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info start date: Jan 7 18:23:16 2021 GMT\n
    [Sun Jan 24 19:31:37.726763 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info expire date: Apr 7 18:23:16 2021 GMT\n
    [Sun Jan 24 19:31:37.726763 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info subjectAltName: host "acme-v02.api.letsencrypt.org" matched cert's "acme-v02.api.letsencrypt.org"\n
    [Sun Jan 24 19:31:37.726763 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info issuer: C=US; O=Let's Encrypt; CN=R3\n
    [Sun Jan 24 19:31:37.726763 2021] [md:trace4] [pid 7556:tid 584] md_curl.c(199): req[0]: info SSL certificate verify ok.\n

If there are any Apache Lounge users out there prepared to try this OpenSSL based version of the CURL libraries with Let's Encrypt (mod_md), it would be very helpful.
Back to top
nono303



Joined: 20 Dec 2016
Posts: 191
Location: Lille, FR, EU

PostPosted: Mon 08 Feb '21 20:20    Post subject: Reply with quote

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:
Code:
2021-02-08 16:13:11.478379 - - - md:debug md_acme.c(752) pid:976 tid:1716 [get directory from https://acme-v02.api.letsencrypt.org/directory]
2021-02-08 16:13:11.478379 - - - md:trace3 md_curl.c(250) pid:976 tid:1716 [creating curl instance]
2021-02-08 16:13:11.480880 - - - md:trace3 md_curl.c(332) pid:976 tid:1716 [req[0]: GET https://acme-v02.api.letsencrypt.org/directory]
2021-02-08 16:13:11.493882 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info   Trying 2606:4700:60:0:f53d:5624:85c7:3a2c:443...\n]
2021-02-08 16:13:11.494382 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info connect to 2606:4700:60:0:f53d:5624:85c7:3a2c port 443 failed: Network unreachable\n]
2021-02-08 16:13:11.494382 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info   Trying 172.65.32.248:443...\n]
2021-02-08 16:13:11.500884 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)\n]
2021-02-08 16:13:11.500884 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info ALPN, offering h2\n]
2021-02-08 16:13:11.500884 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info ALPN, offering http/1.1\n]
2021-02-08 16:13:11.521388 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info successfully imported windows ca store\n]
2021-02-08 16:13:11.521888 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info TLSv1.3 (OUT), TLS handshake, Client hello (1):\n]
2021-02-08 16:13:11.746393 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info TLSv1.3 (IN), TLS handshake, Server hello (2):\n]
2021-02-08 16:13:11.746393 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info TLSv1.2 (IN), TLS handshake, Certificate (11):\n]
2021-02-08 16:13:11.746893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info TLSv1.2 (IN), TLS handshake, Server key exchange (12):\n]
2021-02-08 16:13:11.746893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info TLSv1.2 (IN), TLS handshake, Server finished (14):\n]
2021-02-08 16:13:11.747393 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info TLSv1.2 (OUT), TLS handshake, Client key exchange (16):\n]
2021-02-08 16:13:11.747393 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):\n]
2021-02-08 16:13:11.747393 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info TLSv1.2 (OUT), TLS handshake, Finished (20):\n]
2021-02-08 16:13:11.870393 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info TLSv1.2 (IN), TLS handshake, Finished (20):\n]
2021-02-08 16:13:11.870393 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384\n]
2021-02-08 16:13:11.870393 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info ALPN, server accepted to use h2\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info Server certificate:\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info  subject: CN=acme-v01.api.letsencrypt.org\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info  start date: Feb  3 10:12:43 2021 GMT\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info  expire date: May  4 10:12:43 2021 GMT\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info  subjectAltName: host "acme-v02.api.letsencrypt.org" matched cert's "acme-v02.api.letsencrypt.org"\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info  issuer: C=US; O=Let's Encrypt; CN=R3\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info  SSL certificate verify ok.\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info Using HTTP2, server supports multi-use\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info Connection state changed (HTTP/2 confirmed)\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info Using Stream ID: 1 (easy handle 0xb765d90)\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(203) pid:976 tid:1716 [req[0]: header --> GET /directory HTTP/2\r\nHost: acme-v02.api.letsencrypt.org\r\nuser-agent: Apache/2.4.46 mod_md/2.3.7-git\r\naccept: */*\r\n\r\n]
2021-02-08 16:13:11.870893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info Connection state changed (MAX_CONCURRENT_STREAMS == 128)!\n]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(207) pid:976 tid:1716 [req[0]: header <-- HTTP/2 200 \r\n]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(207) pid:976 tid:1716 [req[0]: header <-- server: nginx\r\n]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(207) pid:976 tid:1716 [req[0]: header <-- date: Mon, 08 Feb 2021 15:13:11 GMT\r\n]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(207) pid:976 tid:1716 [req[0]: header <-- content-type: application/json\r\n]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(207) pid:976 tid:1716 [req[0]: header <-- content-length: 658\r\n]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(207) pid:976 tid:1716 [req[0]: header <-- cache-control: public, max-age=0, no-cache\r\n]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(207) pid:976 tid:1716 [req[0]: header <-- x-frame-options: DENY\r\n]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(207) pid:976 tid:1716 [req[0]: header <-- strict-transport-security: max-age=604800\r\n]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(207) pid:976 tid:1716 [req[0]: header <-- \r\n]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(224) pid:976 tid:1716 [req[0]: data <-- 658 bytes]
2021-02-08 16:13:11.996893 - - - md:trace4 md_curl.c(199) pid:976 tid:1716 [req[0]: info Connection #0 to host acme-v02.api.letsencrypt.org left intact\n]
2021-02-08 16:13:11.996893 - - - md:trace1 md_curl.c(404) pid:976 tid:1716 [request <-- 200]
2021-02-08 16:13:11.996893 - - - md:trace1 md_acme.c(653) pid:976 tid:1716 [directory lookup response: 200]
Back to top
tangent
Moderator


Joined: 16 Aug 2020
Posts: 305
Location: UK

PostPosted: Mon 08 Feb '21 21:23    Post subject: Reply with quote

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).
Back to top
admin
Site Admin


Joined: 15 Oct 2005
Posts: 677

PostPosted: Mon 08 Feb '21 21:42    Post subject: Reply with quote

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

Good and fast response.
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Tue 09 Feb '21 23:50    Post subject: Reply with quote

Quote:
a) build the CURL source ensuring Schannel is the default SSL backend on Windows
b) patch and build mod_md code to call curl_global_sslset() selecting Schannel over the OpenSSL default that Curl currently adopts
c) patch and build CURL to ensure on Windows OpenSSL uses the native CA store by default
d) change nothing and use the CURL_SSL_BACKEND environment variable to determine the preferred SSL backend at run time

e) build curl twice: (1) static libcurl.lib with only Schannel and use that one when building Apache and (2) curl with OpenSSL to use everywhere else.

That is what I am doing. mod_md.so uses Schannel and does not depend on an external libcurl.dll
Back to top
tangent
Moderator


Joined: 16 Aug 2020
Posts: 305
Location: UK

PostPosted: Wed 10 Feb '21 14:08    Post subject: Reply with quote

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.
Back to top
nono303



Joined: 20 Dec 2016
Posts: 191
Location: Lille, FR, EU

PostPosted: Wed 10 Feb '21 14:12    Post subject: Reply with quote

Hi @Jan-E
Quote:
mod_md.so ... does not depend on an external libcurl.dll

In my build, without patching mod_md to call curl_global_sslset(), I have mod_md depending on libcurl.dll

Dependencies.exe -imports mod_md.so
Code:
Import from module libcurl.dll :
         Function curl_multi_add_handle
         Function curl_easy_perform
         Function curl_easy_getinfo
         Function curl_global_init
         Function curl_multi_info_read
         Function curl_multi_wait
         Function curl_easy_init
         Function curl_slist_append
         Function curl_multi_cleanup
         Function curl_multi_strerror
         Function curl_multi_init
         Function curl_easy_strerror
         Function curl_slist_free_all
         Function curl_easy_cleanup
         Function curl_easy_setopt
         Function curl_multi_perform
         Function curl_multi_remove_handle

I double checked that point on my build with runtime usage of:
- unpatched libcurl with openssl backend : mod_md failed
- patched libcurl with openssl backend : mod_md succeed
- libcurl with winssl (schannel) backend : mod_md succeed
Back to top


Reply to topic   Topic: Apache with CURL support for using Windows CA with OpenSSL View previous topic :: View next topic
Post new topic   Forum Index -> How-to's & Documentation & Tips