1

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]

Peter - Reinstate Monica
  • 15,048
  • 4
  • 37
  • 62

1 Answers1

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:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\
set GH=C:\path\to\git
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%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.1 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.2

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.


1I think it's for historical reasons that the variable exists in an upper-case and lower-case form.

2 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.

Peter - Reinstate Monica
  • 15,048
  • 4
  • 37
  • 62
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Good idea to narrow the fault source. I'll try that in two hours or so when I'll be at work. – Peter - Reinstate Monica Jan 25 '19 at 07:17
  • Wow, that works. What's your guess -- does the "regular" git use some dll in the rather elaborate default path instead of its own? In that case it should help to prepend the "regular" git bash path with all the installation directory equivalents (mingw64 etc) you used here. – Peter - Reinstate Monica Jan 25 '19 at 08:39
  • @PeterA.Schneider Either that, or your existing path brings other elements which interfers with the Git settings. – VonC Jan 25 '19 at 08:39
  • Yeah, agreed, but those other elements should be pre-empted with the installation directories coming first. – Peter - Reinstate Monica Jan 25 '19 at 08:41
  • @PeterA.Schneider Agreed. To tell the truth, I never use this days the msi setup. Only the portable archive, with my own path. – VonC Jan 25 '19 at 08:42
  • I use git for Windows from a generic MSYS2 shell (because it's faster than the generic MSYS2 git). I use the shell for general work as well, so I need an elaborate path. Yes, I could open a separate git shell but it would be nicer to keep an integrated work environment. – Peter - Reinstate Monica Jan 25 '19 at 09:02
  • @PeterA.Schneider Note, if you are with Windows 10 1709 or more recent, you could consider working in a WSL shell (https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux). Then you would use the actual Git (for Linux) – VonC Jan 25 '19 at 09:06
  • Errrr... Windows 7 here ;-). BTW, just prepending the git for Windows paths was not successful. I should make sure though that I don't have mis-configured system settings or env vars, because I tried instructing git to use a certain certificate etc. – Peter - Reinstate Monica Jan 25 '19 at 09:08
  • @PeterA.Schneider Windows 7? I was not aware it even existed still ;) (I only recently migrated from W7 to W10 at work actually) – VonC Jan 25 '19 at 09:10
  • Your suggestion identifies the core issue (pulling in something from the path or some other environment misconfiguration) so I just accepted the answer. I'll edit it if and when I find the exact reason. The important conclusion is that it's not a bug in the implementation. – Peter - Reinstate Monica Jan 25 '19 at 09:11
  • @PeterA.Schneider Thank you. I will look forward for those edits. – VonC Jan 25 '19 at 09:13
  • I posted a transcript of doing a git fetch with https_proxy set and empty which appears to make a difference. It's not an explanation so I didn't edit your answer (yet ;-) ). – Peter - Reinstate Monica Jan 25 '19 at 16:48
  • @PeterA.Schneider Thank you for your edit and feedback. – VonC Feb 21 '19 at 11:22