openssl - git 2.20.1.windows.1 does not honor http.sslverify=false

Question

After the latest update (in fact, I did a new install) of git for Windows I cannot connect to a specific remote repository any longer via https. It's on an in-house server which uses a self-signed certificate which has also been expired for a while (don't ask).

It used to work with git for Windows 2.16.x (iirc) and continues to work with parallel installations in cygwin and mysys2 (which report version 2.17.0 and 2.20.1, respectively).

Here is what I tried (not all at the same time):

• I have set the configuration option http.sslverify=false in all locations reported by git config -l --show-origin and verified that sslverify is nowhere true. In particular in the local repo's .git/config which should override any default or explicit system or global settings it is false.

• I changed the http.sslbackend option to sChannel and then back to openssl; the error message changes, indicating that the setting was effective, but it is still an error message. There are posts out there indicating that the newer sChannel mechanism cannot completely be prevented from checking certificates, so I wanted to make sure I'm not accidentally still using it. (It's the default mechanism in a new installation, apparently.)

• I have also downloaded the certificate and directed openssl to use it by editing ~/.ssl/config; unfortunately this just leads git (or rather, openssl) to reject the certificate on the grounds that it is expired.

• I set the environment variable GIT_SSL_NO_VERIFY to "true" which should override all config settings.

• I used the environment variables GIT_TRACE_CURL=path, GIT_TRACE and GIT_CURL_VERBOSE to obtain debug output which didn't show anythng surprising beyond the fact that openssl tried to verify the certificate and failed, which is correct as long as it tries to verify it at all. E.g. the trace file would contain the line Info: SSL certificate problem: self signed certificate which is entireyl correct.

The other git (resp. openssl) installations appear to skip the entire certificate check though which is what we need under the circumstances.

Is this a bug? Any ideas?

---

Edit: The issue has to do with https proxy settings. In my environment I am behind a HTTPS proxy but the repo server must be accessed directly. I have https_proxy and no_proxy variables set for that. In order to exclude all other environment settings I used env -i (which starts a program without eny environment variable set) with two different settings. Note that I kept my original path which has the git installation directories first. The only difference is that in the failing calll, which comes first, https_proxy is set to a string starting with "https://" (the garbage part is literal to make clear it's not a valid host):

The ssl settings are

git config -l |grep -i ssl
http.sslverify=false
http.sslverify=false
http.sslverify=false
http.sslverify=false
http.sslbackend=openssl

env -i PATH="$PATH" GIT_CURL_VERBOSE=1 GIT_TRACE=2 no_proxy="[repo host FQDN]" https_proxy="https://garbage" git fetch 16:41:53.953829 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/bin 16:41:53.955829 git.c:418 trace: built-in: git fetch 16:41:53.980831 run-command.c:643 trace: run_command: GIT_DIR=.git git remote-https origin https://[FQDN/path-to-git] 16:41:54.001834 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core 16:41:54.003834 git.c:675 trace: exec: git-remote-https origin https://[FQDN/path-to-git] 16:41:54.003834 run-command.c:643 trace: run_command: git-remote-https origin https://[FQDN/path-to-git] 16:41:54.028836 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core * Couldn't find host [repo host FQDN] in the _netrc file; using defaults * Trying [repo host IP address]... * TCP_NODELAY set * Connected to [repo host FQDN] ([repo host IP address]) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crt CApath: none * SSL certificate problem: self signed certificate * Closing connection 0 fatal: unable to access 'https://[FQDN/path-to-git]': SSL certificate problem: self signed certificate

The command works if the https_proxy variable does not start with https://. The logs are almost identical up to the line CApath: none, except that there is a line where curl acknowledges the no_proxy setting.

env -i PATH="$PATH" GIT_CURL_VERBOSE=1 GIT_TRACE=2 no_proxy="[repo host FQDN]" https_proxy="" git fetch 17:04:56.884616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/bin 17:04:56.886616 git.c:418 trace: built-in: git fetch 17:04:56.911616 run-command.c:643 trace: run_command: GIT_DIR=.git git remote-https origin https://[FQDN/path-to-git] 17:04:56.931616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core 17:04:56.932616 git.c:675 trace: exec: git-remote-https origin https://[FQDN/path-to-git] 17:04:56.932616 run-command.c:643 trace: run_command: git-remote-https origin https://[FQDN/path-to-git] 17:04:56.957616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core * Uses proxy env variable no_proxy == '[repo host FQDN]' * Couldn't find host [repo host FQDN] in the _netrc file; using defaults * Trying [repo host IP address]... * TCP_NODELAY set * Connected to [repo host FQDN] ([repo host IP address]) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crt CApath: none * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: [... certificate details incl. past expiration date; successful communication]

Answer 1

Try first and access your repo in a CMD session where you set a simplified PATH, using a portable Git for Windows (PortableGit-2.20.1-64-bit.7z.exe), uncompressed in C:Git:

set PATH=C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbem;C:WINDOWSSystem32WindowsPowerShellv1.0
set GH=C:pathogit
set PATH=%GH%in;%GH%usrin;%GH%mingw64in;%PATH%

Then try to access your repo in that session.

---

Edit by the OP, Peter: The test with an uncluttered environment worked. The difference is with the environment variables https_proxy and HTTPS_PROXY which both must be unset.¹ This is true even though the server is listed in the no_proxy environment variable which normally instructs programs to not use a proxy for specific servers listed in the variable value. Luckily the repo server is in the local network.²

It's unclear to me whether git proper, cURL or openssl is the culprit here; the variables are, I believe, evaluated by git proper as well as the networking libraries.

---

_{¹I think it's for historical reasons that the variable exists in an upper-case and lower-case form. ² As far as I can tell the issue is not with the proxy server because the repo server certificate is obtained and correctly recognized as self-certified.}