Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CERT_TRUST_REVOCATION_STATUS_UNKNOWN with Git 2.41.0.windows.1 #4467

Closed
1 task done
sburkard opened this issue Jun 15, 2023 · 26 comments
Closed
1 task done

CERT_TRUST_REVOCATION_STATUS_UNKNOWN with Git 2.41.0.windows.1 #4467

sburkard opened this issue Jun 15, 2023 · 26 comments

Comments

@sburkard
Copy link

  • I was not able to find an open or closed issue matching what I'm seeing

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options

git version 2.41.0.windows.1
cpu: x86_64
built from commit: ff94e79c4724635915dbb3d4ba38f6bb91528260
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
$ cmd.exe /c ver

Microsoft Windows [Version 10.0.19044.2965]
  • What options did you set as part of the installation? Or did you choose the
    defaults?
# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Probably none. Git was installed through Scoop
  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

Behind enterprise proxy that intercepts HTTPS connections and self-signed certificates are used.

Details

  • Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Powershell/Git Bash

$env:GIT_CURL_VERBOSE=1
git clone https://github.com/[whatever-repository].git
  • What did you expect to occur after running these commands?

Cloned repository on my disk

  • What actually happened instead?
Cloning into 'repository-name'...
16:56:02.905057 http.c:842              == Info: Couldn't find host github.com in the (nil) file; using defaults
16:56:02.910502 http.c:842              == Info:   Trying 192.168.229.22:8080...
16:56:02.922227 http.c:842              == Info: Connected to www-proxy.visana.ch (192.168.229.22) port 8080 (#0)
16:56:02.922227 http.c:842              == Info: CONNECT tunnel: HTTP/1.1 negotiated
16:56:02.922227 http.c:842              == Info: allocate connect buffer
16:56:02.922227 http.c:842              == Info: Establish HTTP proxy tunnel to github.com:443
16:56:02.922227 http.c:789              => Send header, 0000000121 bytes (0x00000079)
16:56:02.922227 http.c:801              => Send header: CONNECT github.com:443 HTTP/1.1
16:56:02.922227 http.c:801              => Send header: Host: github.com:443
16:56:02.922227 http.c:801              => Send header: User-Agent: git/2.41.0.windows.1
16:56:02.922227 http.c:801              => Send header: Proxy-Connection: Keep-Alive
16:56:02.922227 http.c:801              => Send header:
16:56:02.973986 http.c:789              <= Recv header, 0000000037 bytes (0x00000025)
16:56:02.973986 http.c:801              <= Recv header: HTTP/1.1 200 Connection established
16:56:02.973986 http.c:789              <= Recv header, 0000000002 bytes (0x00000002)
16:56:02.973986 http.c:801              <= Recv header:
16:56:02.973986 http.c:842              == Info: CONNECT phase completed
16:56:02.973986 http.c:842              == Info: CONNECT tunnel established, response 200
16:56:02.973986 http.c:842              == Info: schannel: disabled automatic use of client certificate
16:56:03.026716 http.c:842              == Info: schannel: added 134 certificate(s) from CA file 'C:\Users\UID20852\ca-trust\extracted\pem\tls-ca-bundle.pem'
16:56:03.037464 http.c:842              == Info: schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
16:56:03.038426 http.c:842              == Info: Closing connection 0
16:56:03.039405 http.c:842              == Info: schannel: shutting down SSL/TLS connection with github.com port 443
fatal: unable to access 'https://github.com/sburkard/cookie-factory.git/': schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
  • If the problem was occurring with a specific repository, can you provide the
    URL to that repository to help us with testing?

You can take any.

  • Other infos

When I downgrade to Git 2.40.1.windows.1, everything works fine.
@dscho
Copy link
Member

dscho commented Jun 15, 2023

Does it work when setting the config option http.schannelCheckRevoke to best-effort?

@sburkard
Copy link
Author

No, unfortunately not. I tried

git config --global http.schannelCheckRevoke best-effort

as well as

git config --global http.schannelCheckRevoke false

But the result was the same

@sburkard
Copy link
Author

Hey @dscho, your suggestion for this git option leaded me to the more relevant discussions for my case.

Git works again if I do

git config --global http.sslBackend openssl

Has the latest Git version switched from openssl to schannel? Are there any consequences when I continue to use openssl (like openssl is planned for deprecation as this is only a limited solution)?

Thanks

@dscho
Copy link
Member

dscho commented Jun 16, 2023

Has the latest Git version switched from openssl to schannel?

Indeed it has! I guess this release note entry did not talk about this explicitly, sorry...

Now, Secure Channel is the native Windows component to do TLS/SSL, so it is much preferred to using OpenSSL. For example, if you want to access hosts with self-signed SSL certificates, using OpenSSL you have to jump through hoops. With Secure Channel, because it is integrated well into the Windows ecosystem, you simply need to direct your web browser to that host, accept the certificate, and then git clone will implicitly trust that certificate, too.

That is the reason why I would love to figure out what is going wrong here, so that you, too, can use Secure Channel.

I see that there is a CA file in effect. Is http.sslCAInfo configured on your system? I do recall that there have been problems in the past with Secure Channel and that setting, as that setting overrides the default Certificate Store for some reason.

@sburkard
Copy link
Author

sburkard commented Jun 16, 2023 •
edited
Loading

That is the reason why I would love to figure out what is going wrong here, so that you, too, can use Secure Channel.

Great, thanks for your effort @dscho

I see that there is a CA file in effect. Is http.sslCAInfo configured on your system?

Yes indeed, we build a custom PEM file that contains the public certificates of Git as well as our company self-signed certificates. This PEM is used as trust store for Git and other tools.

So I tried the following

git config --global --unset http.sslBackend // switch back to schannel
git config --global --unset http.sslCAInfo // remove our custom trust store
git config --global http.schannelCheckRevoke false // ignore when trust-revoke does not work

Unfortunately I still get the same result.

$env:GIT_CURL_VERBOSE=1
git config --global --list

core.autocrlf=input
core.longpaths=true
push.default=simple
user.email=[my email]
user.name=[my Name]
pull.rebase=true
http.schannelcheckrevoke=false

git clone https://github.com/...git
Cloning into '...'...
10:03:19.371397 http.c:842              == Info: Couldn't find host github.com in the (nil) file; using defaults
10:03:19.376276 http.c:842              == Info:   Trying 192.168.229.22:8080...
10:03:19.377249 http.c:842              == Info: Connected to www-proxy.visana.ch (192.168.229.22) port 8080 (#0)
10:03:19.377249 http.c:842              == Info: CONNECT tunnel: HTTP/1.1 negotiated
10:03:19.377249 http.c:842              == Info: allocate connect buffer
10:03:19.377249 http.c:842              == Info: Establish HTTP proxy tunnel to github.com:443
10:03:19.377249 http.c:789              => Send header, 0000000121 bytes (0x00000079)
10:03:19.377249 http.c:801              => Send header: CONNECT github.com:443 HTTP/1.1
10:03:19.377249 http.c:801              => Send header: Host: github.com:443
10:03:19.377249 http.c:801              => Send header: User-Agent: git/2.41.0.windows.1
10:03:19.377249 http.c:801              => Send header: Proxy-Connection: Keep-Alive
10:03:19.377249 http.c:801              => Send header:
10:03:19.388967 http.c:789              <= Recv header, 0000000037 bytes (0x00000025)
10:03:19.388967 http.c:801              <= Recv header: HTTP/1.1 200 Connection established
10:03:19.388967 http.c:789              <= Recv header, 0000000002 bytes (0x00000002)
10:03:19.388967 http.c:801              <= Recv header:
10:03:19.388967 http.c:842              == Info: CONNECT phase completed
10:03:19.388967 http.c:842              == Info: CONNECT tunnel established, response 200
10:03:19.388967 http.c:842              == Info: schannel: disabled automatic use of client certificate
10:03:19.425105 http.c:842              == Info: schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
10:03:19.425105 http.c:842              == Info: Closing connection 0
10:03:19.425105 http.c:842              == Info: schannel: shutting down SSL/TLS connection with github.com port 443
fatal: unable to access 'https://github.com/sburkard/cookie-factory.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.

@dscho
Copy link
Member

dscho commented Jun 22, 2023

Hmm. So it seems that the proxy connection worked, but then the revocation check fails? Is there maybe a chance that you can try the same command but bypassing the proxy? (And yes, I am clutching at straws.)

@sburkard
Copy link
Author

Hi @dscho sorry for the delay, but I had to create a ticket to disable the SSL interception for my test URL

So, new test setting. Still with proxy but without SSL interception. And this is already quite different. The repository is successfully cloned, but the verbse output of curl contains a lot of failed to decrypt data, need more data messages (see below).

No idea if this is normal or a problem indicator.

Settings

> git config --global --list

core.autocrlf=input
core.longpaths=true
push.default=simple
user.email=[my email]
user.name=[my Name]
pull.rebase=true
http.schannelcheckrevoke=false

The result of the clone

> $env:GIT_CURL_VERBOSE=1
> git clone https://github.com/sburkard/cookie-factory.git

Cloning into 'cookie-factory'...
14:47:35.597342 http.c:842              == Info: Couldn't find host github.com in the (nil) file; using defaults
14:47:35.602222 http.c:842              == Info:   Trying 192.168.229.22:8080...
14:47:35.603207 http.c:842              == Info: Connected to www-proxy.visana.ch (192.168.229.22) port 8080 (#0)
14:47:35.603207 http.c:842              == Info: CONNECT tunnel: HTTP/1.1 negotiated
14:47:35.603207 http.c:842              == Info: allocate connect buffer
14:47:35.603207 http.c:842              == Info: Establish HTTP proxy tunnel to github.com:443
14:47:35.603207 http.c:789              => Send header, 0000000121 bytes (0x00000079)
14:47:35.603207 http.c:801              => Send header: CONNECT github.com:443 HTTP/1.1
14:47:35.603207 http.c:801              => Send header: Host: github.com:443
14:47:35.603207 http.c:801              => Send header: User-Agent: git/2.41.0.windows.1
14:47:35.603207 http.c:801              => Send header: Proxy-Connection: Keep-Alive
14:47:35.603207 http.c:801              => Send header:
14:47:35.621768 http.c:789              <= Recv header, 0000000037 bytes (0x00000025)
14:47:35.621768 http.c:801              <= Recv header: HTTP/1.1 200 Connection established
14:47:35.621768 http.c:789              <= Recv header, 0000000002 bytes (0x00000002)
14:47:35.621768 http.c:801              <= Recv header:
14:47:35.621768 http.c:842              == Info: CONNECT phase completed
14:47:35.621768 http.c:842              == Info: CONNECT tunnel established, response 200
14:47:35.621768 http.c:842              == Info: schannel: disabled automatic use of client certificate
14:47:35.750650 http.c:842              == Info: using HTTP/1.x
14:47:35.751629 http.c:789              => Send header, 0000000229 bytes (0x000000e5)
14:47:35.751629 http.c:801              => Send header: GET /sburkard/cookie-factory.git/info/refs?service=git-upload-pack HTTP/1.1
14:47:35.751629 http.c:801              => Send header: Host: github.com
14:47:35.751629 http.c:801              => Send header: User-Agent: git/2.41.0.windows.1
14:47:35.751629 http.c:801              => Send header: Accept: */*
14:47:35.751629 http.c:801              => Send header: Accept-Encoding: deflate, gzip, br, zstd
14:47:35.751629 http.c:801              => Send header: Pragma: no-cache
14:47:35.751629 http.c:801              => Send header: Git-Protocol: version=2
14:47:35.751629 http.c:801              => Send header:
14:47:35.896150 http.c:789              <= Recv header, 0000000017 bytes (0x00000011)
14:47:35.896150 http.c:801              <= Recv header: HTTP/1.1 200 OK
14:47:35.896150 http.c:789              <= Recv header, 0000000026 bytes (0x0000001a)
14:47:35.896150 http.c:801              <= Recv header: Server: GitHub-Babel/3.0
14:47:35.896150 http.c:789              <= Recv header, 0000000059 bytes (0x0000003b)
14:47:35.896150 http.c:801              <= Recv header: Content-Type: application/x-git-upload-pack-advertisement
14:47:35.896150 http.c:789              <= Recv header, 0000000054 bytes (0x00000036)
14:47:35.896150 http.c:801              <= Recv header: Content-Security-Policy: default-src 'none'; sandbox
14:47:35.896150 http.c:789              <= Recv header, 0000000040 bytes (0x00000028)
14:47:35.896150 http.c:801              <= Recv header: expires: Fri, 01 Jan 1980 00:00:00 GMT
14:47:35.896150 http.c:789              <= Recv header, 0000000018 bytes (0x00000012)
14:47:35.896150 http.c:801              <= Recv header: pragma: no-cache
14:47:35.896150 http.c:789              <= Recv header, 0000000053 bytes (0x00000035)
14:47:35.896150 http.c:801              <= Recv header: Cache-Control: no-cache, max-age=0, must-revalidate
14:47:35.896150 http.c:789              <= Recv header, 0000000023 bytes (0x00000017)
14:47:35.896150 http.c:801              <= Recv header: Vary: Accept-Encoding
14:47:35.896150 http.c:789              <= Recv header, 0000000028 bytes (0x0000001c)
14:47:35.896150 http.c:801              <= Recv header: Transfer-Encoding: chunked
14:47:35.896150 http.c:789              <= Recv header, 0000000037 bytes (0x00000025)
14:47:35.896150 http.c:801              <= Recv header: Date: Fri, 30 Jun 2023 12:47:35 GMT
14:47:35.896150 http.c:789              <= Recv header, 0000000023 bytes (0x00000017)
14:47:35.896150 http.c:801              <= Recv header: X-Frame-Options: DENY
14:47:35.896150 http.c:789              <= Recv header, 0000000057 bytes (0x00000039)
14:47:35.896150 http.c:801              <= Recv header: X-GitHub-Request-Id: 419D:56D7:57C639A:590202E:649ECEE7
14:47:35.896150 http.c:789              <= Recv header, 0000000002 bytes (0x00000002)
14:47:35.896150 http.c:801              <= Recv header:
14:47:35.896150 http.c:842              == Info: Connection #0 to host www-proxy.visana.ch left intact
14:47:35.898108 http.c:842              == Info: Couldn't find host github.com in the (nil) file; using defaults
14:47:35.898108 http.c:842              == Info: Found bundle for host: 0x1ff66e64800 [serially]
14:47:35.898108 http.c:842              == Info: Re-using existing connection #0 with proxy www-proxy.visana.ch
14:47:35.898108 http.c:789              => Send header, 0000000301 bytes (0x0000012d)
14:47:35.898108 http.c:801              => Send header: POST /sburkard/cookie-factory.git/git-upload-pack HTTP/1.1
14:47:35.898108 http.c:801              => Send header: Host: github.com
14:47:35.898108 http.c:801              => Send header: User-Agent: git/2.41.0.windows.1
14:47:35.898108 http.c:801              => Send header: Accept-Encoding: deflate, gzip, br, zstd
14:47:35.898108 http.c:801              => Send header: Content-Type: application/x-git-upload-pack-request
14:47:35.898108 http.c:801              => Send header: Accept: application/x-git-upload-pack-result
14:47:35.898108 http.c:801              => Send header: Git-Protocol: version=2
14:47:35.898108 http.c:801              => Send header: Content-Length: 185
14:47:35.898108 http.c:801              => Send header:
14:47:36.045553 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.045553 http.c:789              <= Recv header, 0000000017 bytes (0x00000011)
14:47:36.045553 http.c:801              <= Recv header: HTTP/1.1 200 OK
14:47:36.045553 http.c:789              <= Recv header, 0000000026 bytes (0x0000001a)
14:47:36.045553 http.c:801              <= Recv header: Server: GitHub-Babel/3.0
14:47:36.045553 http.c:789              <= Recv header, 0000000052 bytes (0x00000034)
14:47:36.045553 http.c:801              <= Recv header: Content-Type: application/x-git-upload-pack-result
14:47:36.045553 http.c:789              <= Recv header, 0000000054 bytes (0x00000036)
14:47:36.045553 http.c:801              <= Recv header: Content-Security-Policy: default-src 'none'; sandbox
14:47:36.045553 http.c:789              <= Recv header, 0000000040 bytes (0x00000028)
14:47:36.045553 http.c:801              <= Recv header: expires: Fri, 01 Jan 1980 00:00:00 GMT
14:47:36.045553 http.c:789              <= Recv header, 0000000018 bytes (0x00000012)
14:47:36.045553 http.c:801              <= Recv header: pragma: no-cache
14:47:36.045553 http.c:789              <= Recv header, 0000000053 bytes (0x00000035)
14:47:36.045553 http.c:801              <= Recv header: Cache-Control: no-cache, max-age=0, must-revalidate
14:47:36.045553 http.c:789              <= Recv header, 0000000023 bytes (0x00000017)
14:47:36.045553 http.c:801              <= Recv header: Vary: Accept-Encoding
14:47:36.045553 http.c:789              <= Recv header, 0000000028 bytes (0x0000001c)
14:47:36.045553 http.c:801              <= Recv header: Transfer-Encoding: chunked
14:47:36.045553 http.c:789              <= Recv header, 0000000037 bytes (0x00000025)
14:47:36.045553 http.c:801              <= Recv header: Date: Fri, 30 Jun 2023 12:47:35 GMT
14:47:36.045553 http.c:789              <= Recv header, 0000000023 bytes (0x00000017)
14:47:36.045553 http.c:801              <= Recv header: X-Frame-Options: DENY
14:47:36.045553 http.c:789              <= Recv header, 0000000057 bytes (0x00000039)
14:47:36.045553 http.c:801              <= Recv header: X-GitHub-Request-Id: 419D:56D7:57C646B:590212B:649ECEE7
14:47:36.045553 http.c:789              <= Recv header, 0000000002 bytes (0x00000002)
14:47:36.045553 http.c:801              <= Recv header:
14:47:36.045553 http.c:842              == Info: Connection #0 to host www-proxy.visana.ch left intact
14:47:36.058247 http.c:842              == Info: Couldn't find host github.com in the (nil) file; using defaults
14:47:36.058247 http.c:842              == Info: Found bundle for host: 0x1ff66e64800 [serially]
14:47:36.058247 http.c:842              == Info: Re-using existing connection #0 with proxy www-proxy.visana.ch
14:47:36.058247 http.c:789              => Send header, 0000000301 bytes (0x0000012d)
14:47:36.058247 http.c:801              => Send header: POST /sburkard/cookie-factory.git/git-upload-pack HTTP/1.1
14:47:36.058247 http.c:801              => Send header: Host: github.com
14:47:36.058247 http.c:801              => Send header: User-Agent: git/2.41.0.windows.1
14:47:36.058247 http.c:801              => Send header: Accept-Encoding: deflate, gzip, br, zstd
14:47:36.058247 http.c:801              => Send header: Content-Type: application/x-git-upload-pack-request
14:47:36.058247 http.c:801              => Send header: Accept: application/x-git-upload-pack-result
14:47:36.058247 http.c:801              => Send header: Git-Protocol: version=2
14:47:36.058247 http.c:801              => Send header: Content-Length: 762
14:47:36.058247 http.c:801              => Send header:
14:47:36.217421 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.217421 http.c:789              <= Recv header, 0000000017 bytes (0x00000011)
14:47:36.217421 http.c:801              <= Recv header: HTTP/1.1 200 OK
14:47:36.217421 http.c:789              <= Recv header, 0000000026 bytes (0x0000001a)
14:47:36.217421 http.c:801              <= Recv header: Server: GitHub-Babel/3.0
14:47:36.217421 http.c:789              <= Recv header, 0000000052 bytes (0x00000034)
14:47:36.217421 http.c:801              <= Recv header: Content-Type: application/x-git-upload-pack-result
14:47:36.217421 http.c:789              <= Recv header, 0000000054 bytes (0x00000036)
14:47:36.217421 http.c:801              <= Recv header: Content-Security-Policy: default-src 'none'; sandbox
14:47:36.217421 http.c:789              <= Recv header, 0000000040 bytes (0x00000028)
14:47:36.217421 http.c:801              <= Recv header: expires: Fri, 01 Jan 1980 00:00:00 GMT
14:47:36.217421 http.c:789              <= Recv header, 0000000018 bytes (0x00000012)
14:47:36.217421 http.c:801              <= Recv header: pragma: no-cache
14:47:36.217421 http.c:789              <= Recv header, 0000000053 bytes (0x00000035)
14:47:36.217421 http.c:801              <= Recv header: Cache-Control: no-cache, max-age=0, must-revalidate
14:47:36.217421 http.c:789              <= Recv header, 0000000023 bytes (0x00000017)
14:47:36.217421 http.c:801              <= Recv header: Vary: Accept-Encoding
14:47:36.217421 http.c:789              <= Recv header, 0000000028 bytes (0x0000001c)
14:47:36.217421 http.c:801              <= Recv header: Transfer-Encoding: chunked
14:47:36.217421 http.c:789              <= Recv header, 0000000037 bytes (0x00000025)
14:47:36.217421 http.c:801              <= Recv header: Date: Fri, 30 Jun 2023 12:47:36 GMT
14:47:36.217421 http.c:789              <= Recv header, 0000000023 bytes (0x00000017)
14:47:36.217421 http.c:801              <= Recv header: X-Frame-Options: DENY
14:47:36.217421 http.c:789              <= Recv header, 0000000057 bytes (0x00000039)
14:47:36.217421 http.c:801              <= Recv header: X-GitHub-Request-Id: 419D:56D7:57C657C:590223C:649ECEE7
14:47:36.217421 http.c:789              <= Recv header, 0000000002 bytes (0x00000002)
14:47:36.217421 http.c:801              <= Recv header:
14:47:36.218395 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.219378 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.220353 http.c:842              == Info: schannel: failed to decrypt data, need more data
remote: Enumerating objects: 253, done.
remote: Counting objects:   0% (1/118)
 need more data
remote: Counting objects:   4% (5/118)14:47:36.223278 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.223278 http.c:842              == Info: schannel: failed to decrypt data, need more data
remote: Counting objects:  27% (32/118)14:47:36.226214 http.c:842              == Info: schannel: failed to decrypt data, need more data
remote: Counting objects:  28% (34/118)
, need more data
remote: Counting objects:  35% (42/118)
, need more data
14:47:36.228159 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.228159 http.c:842              == Info: schannel: failed to decrypt data, need more data
remote: Counting objects: 100% (118/118), done.
remote: Compressing objects:   0% (1/105)
ta, need more data
remote: Compressing objects:  16% (17/105)
ata, need more data
14:47:36.243783 http.c:842              == Info: schannel: failed to decrypt data, need more data
remote: Compressing objects:  37% (39/105)14:47:36.246709 http.c:842              == Info: schannel: failed to decrypt data, need more data
remote: Compressing objects:  38% (40/105)
ata, need more data
14:47:36.246709 http.c:842              == Info: schannel: failed to decrypt data, need more data
remote: Compressing objects:  67% (71/105)
ata, need more data
14:47:36.251594 http.c:842              == Info: schannel: failed to decrypt data, need more data
remote: Compressing objects:  88% (93/105)
ata, need more data
14:47:36.254519 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.254519 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.254519 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.254519 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.254519 http.c:842              == Info: schannel: failed to decrypt data, need more data
remote: Compressing objects: 100% (105/105), done.
14:47:36.260385 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.262337 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.262337 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.263313 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.268200 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.271124 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.271124 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.271124 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.271124 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.276009 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.278936 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.278936 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.278936 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.278936 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.278936 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.278936 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.283820 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.283820 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.283820 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.283820 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.286755 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.286755 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.286755 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.286755 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.286755 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.286755 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.286755 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.286755 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.287724 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.291631 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.291631 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.294560 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.294560 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.295534 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.295534 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.295534 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.295534 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.299444 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.302376 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.303346 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.303346 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.303346 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.303346 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.303346 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.303346 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.303346 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.303346 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.308231 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.308231 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: schannel: failed to decrypt data, need more data
14:47:36.311157 http.c:842              == Info: Connection #0 to host www-proxy.visana.ch left intact
Receiving objects:  92% (233/253)sed 57 (delta 8), pack-reused 135Receiving objects:  50% (127/253)
Receiving objects: 100% (253/253), 213.73 KiB | 2.85 MiB/s, done.
Resolving deltas: 100% (78/78), done.

Let me know if I should do some other tests in this setting or another test with proxy bypass. For the moment I stick with this setting because every change has to be done by ticket request.

Thanks

@HaTiIn
Copy link

HaTiIn commented Jul 6, 2023

FYI: In our company, this change has caused CI pipelines using Gitlab Runner 16.1.0 to fail with the following error: "fatal: unable to access 'https://xxxx.git/': schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN."
The helper image used by Gitlab Runner 16.1.0 uses git version 2.41.0. Unfortunately, I don't know how to revert the default in the helper image. Therefore, we need to downgrade to version 16.0.2.

@dscho
Copy link
Member

dscho commented Jul 7, 2023

new test setting. Still with proxy but without SSL interception. And this is already quite different. The repository is successfully cloned,

@sburkard I guess this is a clear indication that the proxy's causing the problem. Now, my hunch is that libcurl might need some changes to allow for the CURLSSLOPT_REVOKE_BEST_EFFORT flag to be used for proxy connections, too.

However, when I look at curl/curl@5450428 I do not see any red flags: schannel_connect_step1() seems to run in the exact same way for proxies as it does for the actual connection... Having said that, the current version of this function looks different, quite different.

Oh, but I just saw this: the CURSSLOPT_REVOKE_BEST_EFFORT flag is mentioned also in the CURLOPT_PROXY_SSL_OPTIONS manual page, but Git only sets the CURLOPT_SSL_OPTIONS.

@sburkard do you think you could test whether setting the proxy options helps? I.e.

  1. install Git for Windows' SDK,

  2. sdk cd git,

  3. edit http.c, something like this:

    diff --git a/http.c b/http.c
index f8497b5c49e7..3f4b2f80720d 100644
--- a/http.c
+++ b/http.c
@@ -1029,8 +1029,10 @@ static CURL *get_curl_handle(void)
 #endif
 		}
 
-		if (ssl_options)
+		if (ssl_options) {
 			curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, ssl_options);
+			curl_easy_setopt(result, CURLOPT_PROXY_SSL_OPTIONS, ssl_options);
+		}
 	}
 
 	if (http_proactive_auth)

  4. build Git via make -j$(nproc)

  5. test in-place via ./bin-wrappers/git -C <directory> <command>?

  6. open a PR?

but the verbse output of curl contains a lot of failed to decrypt data, need more data messages (see below).

These are all prefixed with "Info:", therefore I assume that they are not even warnings, just informative messages indicating that data arrived in such small chunks that decryption had to wait until more data arrived.

dscho added a commit to dscho/git that referenced this issue Jul 7, 2023
@dscho
http: set the proxy SSL options, if compiling with a new-enough libcurl
9cbb247 
As of v7.52.0, libcurl allows to specify not only the SSL options for
the actual HTTPS connection, but also for the HTTPS proxy (if any).

Let's do that.

This _may_ address git-for-windows#4467.

Signed-off-by: Johannes Schindelin <[email protected]>
@dscho dscho mentioned this issue Jul 7, 2023
Draft
@dscho
Copy link
Member

dscho commented Jul 7, 2023

3. edit http.c, something like this:

diff --git a/http.c b/http.c
index f8497b5c49e7..3f4b2f80720d 100644
--- a/http.c
+++ b/http.c
@@ -1029,8 +1029,10 @@ static CURL *get_curl_handle(void)
 #endif
 		}
 
-		if (ssl_options)
+		if (ssl_options) {
 			curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, ssl_options);
+			curl_easy_setopt(result, CURLOPT_PROXY_SSL_OPTIONS, ssl_options);
+		}
 	}
 
 	if (http_proactive_auth)

FWIW I also opened a PR for that, you could therefore get going with a local test via these steps:

sdk cd git
git fetch https://github.com/git-for-windows/git/ refs/pull/4495/head
git checkout FETCH_HEAD
make -j$(nproc)

@sburkard
Copy link
Author

Hi @dscho

OK, I've built the Git binary locally, checked out your branch and gave it a try. Unfortunately still the same problem.

Official Git-Release + OpenSSL backend: works
Official Git-Release + schannel: NOT working
Local Git-Build from Branch + schannel: NOT working

I can now "switch" between interception and no-interception since my GitHub-Repo is no more intercepted and any public non-GitHub-Repo is intercepted.

export GIT_CURL_VERBOSE=1
> ./bin-wrappers/git -C ~/git/uid20852/ config --global --list

core.autocrlf=input
core.longpaths=true
push.default=simple
user.email=<my email>
user.name=<my name>
pull.rebase=true
http.schannelcheckrevoke=false

> ./bin-wrappers/git -C ~/git/uid20852/ clone https://gitlab.com/njouve/demo.git

Klone nach 'demo'...
15:54:27.686454 http.c:843              == Info: Couldn't find host gitlab.com in the (nil) file; using defaults
15:54:27.692319 http.c:843              == Info:   Trying 192.168.229.22:8080...
15:54:27.693287 http.c:843              == Info: Connected to www-proxy.visana.ch (192.168.229.22) port 8080 (#0)
15:54:27.693287 http.c:843              == Info: CONNECT tunnel: HTTP/1.1 negotiated
15:54:27.693287 http.c:843              == Info: allocate connect buffer
15:54:27.693287 http.c:843              == Info: Establish HTTP proxy tunnel to gitlab.com:443
15:54:27.693287 http.c:790              => Send header, 0000000111 bytes (0x0000006f)
15:54:27.693287 http.c:802              => Send header: CONNECT gitlab.com:443 HTTP/1.1
15:54:27.693287 http.c:802              => Send header: Host: gitlab.com:443
15:54:27.693287 http.c:802              => Send header: User-Agent: git/2.41.0
15:54:27.693287 http.c:802              => Send header: Proxy-Connection: Keep-Alive
15:54:27.693287 http.c:802              => Send header:
15:54:27.703061 http.c:790              <= Recv header, 0000000037 bytes (0x00000025)
15:54:27.703061 http.c:802              <= Recv header: HTTP/1.1 200 Connection established
15:54:27.703061 http.c:790              <= Recv header, 0000000002 bytes (0x00000002)
15:54:27.703061 http.c:802              <= Recv header:
15:54:27.703061 http.c:843              == Info: CONNECT phase completed
15:54:27.703061 http.c:843              == Info: CONNECT tunnel established, response 200
15:54:27.703061 http.c:843              == Info: schannel: disabled automatic use of client certificate
15:54:27.733323 http.c:843              == Info: schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check
revocation for the certificate.
15:54:27.733323 http.c:843              == Info: Closing connection 0
15:54:27.733323 http.c:843              == Info: schannel: shutting down SSL/TLS connection with gitlab.com port 443
Schwerwiegend: konnte nicht auf 'https://gitlab.com/njouve/demo.git/' zugreifen: schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocati
on function was unable to check revocation for the certificate.

Let me know if I can do other tests to find the problem.

Thanks

@dscho
Copy link
Member

dscho commented Jul 12, 2023

Thank you for testing this.

I fear the next steps might be a bit more involved: The most promising direction would be to build libcurl and instrument it with debug print statements. My suggestion to get there:

$ sdk cd mingw-w64-curl
$ sdk build

This will build the current mingw-w64-x86_64-curl package, and most crucially, give you a worktree with the source code at /usr/src/MINGW-packages/mingw-w64-curl/src/curl-8.1.2. If I were you, I would try to insert fprintf(stderr, "%s:%d: HERE!\n", __FILE__, __LINE__); statements in the most interesting parts of lib/vtls/schannel*.c (starting with the location where the error message is produced, and then adding more print statements as well as logging values of interest e.g. whether the BEST_EFFORT flag was handed to the code as expected, and if not, where the ball was dropped), then build and "install" with make -C /usr/src/MINGW-packages/mingw-w64-curl/src/build-MINGW64-shared && cp /usr/src/MINGW-packages/mingw-w64-curl/src/build-MINGW64-shared/lib/.libs/libcurl-4.dll /mingw64/bin/.

@sburkard
Copy link
Author

Hi @dscho
When I do sdk build I get SSL errors because of the selfsigned cert of our proxy

error: failed retrieving file 'mingw-w64-x86_64-autotools-2022.01.16-1-any.pkg.tar.zst' from mirror.msys2.org : SSL certificate problem: self-signed certificate in certificate chain
... the same for a buch of mirrors ...
...
==> ERROR: 'pacman' failed to install missing dependencies.

Can I disable this check somehow?

@dscho
Copy link
Member

dscho commented Jul 12, 2023

error: failed retrieving file 'mingw-w64-x86_64-autotools-2022.01.16-1-any.pkg.tar.zst' from mirror.msys2.org : SSL certificate problem: self-signed certificate in certificate chain

Hmm. That's strange, I never saw that before. That site's certificate is definitely verified by Let's Encrypt, so it is not really self-signed.

IIRC pacman uses the certificates installed via the ca-certificates bundle, i.e. /usr/ssl/certs/ca-bundle.crt. Maybe that file got corrupted in your setup? Curious. I'm clutching at straws here.

@dscho
Copy link
Member

dscho commented Jul 12, 2023

Oh, maybe msys2/MSYS2-packages#2529 (comment) explains it... you're still behind that proxy, right?

@dscho
Copy link
Member

dscho commented Jul 12, 2023

@sburkard https://www.msys2.org/docs/faq/#how-can-i-make-msys2pacman-trust-my-companys-custom-tls-ca-certificate should have a work-around for you.

@sburkard
Copy link
Author

Oh, maybe msys2/MSYS2-packages#2529 (comment) explains it... you're still behind that proxy, right?

Yes, the selfsigned cert is from our proxy

https://www.msys2.org/docs/faq/#how-can-i-make-msys2pacman-trust-my-companys-custom-tls-ca-certificate should have a work-around for you.

Ah, it behaves like a standard linux truststore. Sorry that I didn't realize that before!
It now downloads the missing files and tomorrow I can try to insert print-statements 🙈

@sburkard
Copy link
Author

Hi @dscho

Well, that is really unexpected.

  • I inserted a bunch of fprintf statements into lib/vtls/schannel.c and then compiled cURL as you suggested
  • Then I tried to clone the repo again in an msys2 shell that now uses my customized cURL version

To my surprise, I got an error about self-signed cert in the chain with a hint to the truststore at /mingw64/etc/ssl/certs/ca-bundle.crt

 > ./bin-wrappers/git -C ~/git/uid20852/ clone https://gitlab.com/njouve/demo.git
Klone nach 'demo'...

...
09:00:51.049518 http.c:843              == Info: CONNECT phase completed
09:00:51.049518 http.c:843              == Info: CONNECT tunnel established, response 200
09:00:51.050481 http.c:843              == Info: ALPN: offers h2,http/1.1
09:00:51.050481 http.c:843              == Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
09:00:51.250659 http.c:843              == Info:  CAfile: C:/dev/git-sdk-64/mingw64/etc/ssl/certs/ca-bundle.crt
09:00:51.250659 http.c:843              == Info:  CApath: none
09:00:51.250659 http.c:843              == Info: TLSv1.3 (IN), TLS handshake, Server hello (2):
09:00:51.251639 http.c:843              == Info: TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
09:00:51.251639 http.c:843              == Info: TLSv1.3 (IN), TLS handshake, Certificate (11):
09:00:51.251639 http.c:843              == Info: TLSv1.3 (OUT), TLS alert, unknown CA (560):
09:00:51.251639 http.c:843              == Info: SSL certificate problem: self-signed certificate in certificate chain
09:00:51.251639 http.c:843              == Info: Closing connection 0
Schwerwiegend: konnte nicht auf 'https://gitlab.com/njouve/demo.git/' zugreifen: SSL certificate problem: self-signed certificate in
certificate chain

Nothing about schannel, it seemed to use the openssl trust material. So I explicitly set schannel as SSL backend

> ./bin-wrappers/git -C ~/git/uid20852/ config --global http.sslBackend schannel

Then, to my even bigger surprise, I got a successful repo clone (with the output of my fprintf statements)

This made me think about the changed default in Git 2.41.0, so I did the same on my standard Git installation

> git config --global http.sslBackend schannel
> git config --global --list

core.autocrlf=input
core.longpaths=true
push.default=simple
pull.rebase=true
http.schannelcheckrevoke=false
http.sslbackend=schannel

And then I crossed fingers and gave it a try. And IT WORKED

git clone https://gitlab.com/njouve/demo.git
Cloning into 'demo'...
remote: Enumerating objects: 125, done.
remote: Counting objects: 100% (125/125), done.
remote: Compressing objects: 100% (90/90), done.
remote: Total 125 (delta 31), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (125/125), 23.88 KiB | 7.96 MiB/s, done.
Resolving deltas: 100% (31/31), done.

So long story short:

  • It seems to make a difference (at least behind our company proxy) if http.sslBackend is explicitly set to schannel or not set
  • Even though it should default to schannel since version 2.41.0.windows.1, shouldn't it?
  • When http.sslBackend is explicitly set to schannel, it works, even behind our company proxy

This conclusion is so damn simple that it's hard to believe. So I verified it on another machine to be sure that this is not a side effect of all my handicrafts around this issue 🙈

> git clone https://gitlab.com/njouve/demo.git
Cloning into 'demo'...
fatal: unable to access 'https://gitlab.com/njouve/demo.git/': SSL certificate problem: self signed certificate in certificate chain

> git config --global http.sslBackend schannel
> git clone https://gitlab.com/njouve/demo.git
Cloning into 'demo'...
remote: Enumerating objects: 125, done.
remote: Counting objects: 100% (125/125), done.
remote: Compressing objects: 100% (90/90), done.
remote: Total 125 (delta 31), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (125/125), 23.88 KiB | 7.96 MiB/s, done.
Resolving deltas: 100% (31/31), done.

I still can't believe it. And by the way: it even works without http.schannelcheckrevoke=false

@stanhu
Copy link

stanhu commented Jul 19, 2023

@dscho We ran into the CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN error with a self-signed certificate and replicated it with curl as well:

C:\builds\runners\windows.tmp>curl -v --cacert ./CI_SERVER_TLS_CA_FILE https://gitlab.redacteddomain/
*   Trying 18.170.16.138:443...
* Connected to gitlab.redacteddomain (18.170.16.138) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* schannel: added 2 certificate(s) from CA file './CI_SERVER_TLS_CA_FILE'
* schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
* Closing connection 0
* schannel: shutting down SSL/TLS connection with gitlab.redacteddomain port 443
curl: (60) schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
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.

Passing --ssl-revoke-best-effort appears to solve the problem for the reasons described in curl/curl@5450428.

Can we enable CURLSSLOPT_REVOKE_BEST_EFFORT by default now? I'm wondering:

  1. Should this change be made in Git for Windows or upstream git-core?
  2. Should this default be flipped on by default in curl?

gitlab-runner-bot pushed a commit to gitlabhq/gitlab-runner that referenced this issue Jul 21, 2023
@stanhu
Downgrade Git from v2.41.0 to v2.40.1
71d4b3d 
Git for Windows changed its SSL backend from OpenSSL to SChannel, but
this breaks cloning for SSL certs that don't have a certificate
revocation URL
(git-for-windows/git#4467). For now,
downgrade to v2.40.1 until that is resolved.

Relates to:

* https://gitlab.com/gitlab-org/gitlab-runner/-/issues/35848
* https://gitlab.com/gitlab-org/gitlab-runner/-/issues/35981
* https://gitlab.com/gitlab-org/gitlab-runner/-/issues/35994
@dscho
Copy link
Member

dscho commented Aug 10, 2023

So long story short:

  • It seems to make a difference (at least behind our company proxy) if http.sslBackend is explicitly set to schannel or not set
  • Even though it should default to schannel since version 2.41.0.windows.1, shouldn't it?
  • When http.sslBackend is explicitly set to schannel, it works, even behind our company proxy

@sburkard well, that is splendid news!

About the new default: This will only matter if you install Git for Windows afresh. If you upgrade, it will use the previous settings (and ignore the new default).

Can we enable CURLSSLOPT_REVOKE_BEST_EFFORT by default now?

@stanhu that's not a decision for Git for Windows to make, but for cURL. Please feel free to raise the issue in https://github.com/curl/curl/issues, preferably with the information you mentioned above to support this change.

And with this addressed, I guess it is time to close this ticket 😃

@dscho dscho closed this as not planned Won't fix, can't repro, duplicate, stale Aug 10, 2023
@mstrap
Copy link

mstrap commented Sep 16, 2023 •
edited
Loading

I encountered this (and several other issues) with our self-signed certificates. With Git 2.39, the following configuration was working for us:

[http]
	sslCAInfo = C:/path/to/ca.crt
	sslCert = C:/path/to/client.crt
	sslKey = C:/path/to/client.pem

With Git 2.41, we had to change this to:

[http]
	sslCAInfo = C:/path/to/ca.crt
	sslCert = C:/path/to/client.p12 # have no password configured
	sslbackend = schannel
	schannelUseSSLCAInfo = true

Without sslbackend I get:

fatal: unable to access 'https://...': schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN

Without schannelUseSSLCAInfo I get:

fatal: unable to access 'https://...': schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.

The presence of http.schannelCheckRevoke does not matter. Interestingly, it does for curl where I have to include --ssl-no-revoke:

curl https://... --cert C:/path/to/client.p12 --cacert C:/path/to/ca.crt --ssl-no-revoke

@dscho
Copy link
Member

dscho commented Sep 18, 2023

With Git 2.39, the following configuration was working for us:

[http]
	sslCAInfo = C:/path/to/ca.crt
	sslCert = C:/path/to/client.crt
	sslKey = C:/path/to/client.pem

With Git 2.41, we had to change this to:

[http]
	sslCAInfo = C:/path/to/ca.crt
	sslCert = C:/path/to/client.p12 # have no password configured
	sslbackend = schannel
	schannelUseSSLCAInfo = true

Without sslbackend [...]

I suspect that your implicit sslbackend setting was openssl with Git for Windows v2.39. Could you see whether it works when you specify sslbackend = openssl explicitly (without the sslCert and schannelUseSSLCAInfo, neither of which should be required for the openssl backend)?

@mstrap
Copy link

mstrap commented Sep 18, 2023 •
edited
Loading

Thanks @dscho , yes, it does usually work with sslbackend = openssl. We were actually using this option for a while but encountered other problems in combination with our GitLab server and clones:

$ git clone -v --progress --branch develop https://user:password@server/internal/repo.git D:/temp/repo
[2023-09-18 09:58:42] Cloning into 'D:/temp/repo'...
[2023-09-18 09:58:43] POST git-upload-pack (380 bytes)
[2023-09-18 09:58:43] POST git-upload-pack (gzip 182562 to 90465 bytes)
[2023-09-18 10:00:43] error: RPC failed; curl 56 HTTP/2 stream 7 was reset
[2023-09-18 10:00:43] fatal: expected 'packfile'

With Git 2.39, the same clone works, so it's not only about the sslbackend default. For Git 2.41 on Linux, the same clone works, too. Either way, with the new configuration, everything seems to work fine. I just wanted to summarize my experiences here, for it may be helpful for others.

@dscho
Copy link
Member

dscho commented Sep 18, 2023

@mstrap thank you for clarifying. FWIW I also usually recommend Secure Channel instead of OpenSSL because it is integrated better with the Windows operating system.

Speaking of which, why not go the common route and add the self-signed certificate(s) to the Windows Certificate Store? Like, if you direct your web browser to the host, add the certificate and trust it, using schannel should automatically inherit that trust. No need to configure sslCert nor schannelUseSSLCAInfo.

@mstrap
Copy link

mstrap commented Sep 18, 2023

@dscho I have imported C:/path/to/client.p12 into Certificates - Current User, Personal, Certificates and C:/path/to/ca.crt to Certificates - Current User, Trusted Root Certification Authorities, Certificates and removed all four lines from .gitconfig. A pull now fails with:

fatal: unable to access 'https://server/repo.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.

When not importing C:/path/to/ca.crt and keeping sslCAInfo configured, a pull fails with (as I would expect):

fatal: unable to access 'https://server/repo.git/': schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.

Maybe there is something wrong with our CA -- I'm not experienced with revocation lists. Either way, configuring everything in .gitconfig seems quite reasonable: it's quick and its consequences are limited to exactly Git operation (i.e. I don't have to spoil the Windows CA store).

@dscho
Copy link
Member

dscho commented Sep 18, 2023

I have imported C:/path/to/client.p12 into Certificates - Current User, Personal, Certificates and C:/path/to/ca.crt to Certificates - Current User, Trusted Root Certification Authorities, Certificates and removed all four lines from .gitconfig. A pull now fails with:

fatal: unable to access 'https://server/repo.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.

This is probably due to the fact that a self-signed certificate has no revocation URL (or at least no valid one). I had hoped that the default http.schannelCheckRevoke = best-effort would address this, but apparently not :-(

[...] Either way, configuring everything in .gitconfig seems quite reasonable: it's quick and its consequences are limited to exactly Git operation (i.e. I don't have to spoil the Windows CA store).

Fair enough!

qsliu2017 pushed a commit to qsliu2017/gitlab-runner that referenced this issue Nov 9, 2023
@stanhu
Downgrade Git from v2.41.0 to v2.40.1
77b8021 
Git for Windows changed its SSL backend from OpenSSL to SChannel, but
this breaks cloning for SSL certs that don't have a certificate
revocation URL
(git-for-windows/git#4467). For now,
downgrade to v2.40.1 until that is resolved.

Relates to:

* https://gitlab.com/gitlab-org/gitlab-runner/-/issues/35848
* https://gitlab.com/gitlab-org/gitlab-runner/-/issues/35981
* https://gitlab.com/gitlab-org/gitlab-runner/-/issues/35994
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dscho @stanhu @mstrap @sburkard @HaTiIn