Git - The revocation function was unable to check revocation for the certificate

Question

I'm trying to clone from Github by using both Github Desktop and the git shell but keep on getting this error:

Cloning into 'C:\Users\John Doe\workspace\MyProject'...
fatal: unable to access 'https://github.com/JohnDoe/MyProject.git/': 
schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - 
The revocation function was unable to check revocation for the certificate.

Same problem when pulling an existing repository.

I've already tried to upload SSH keys found in ~/.ssh/github-ssh.pub to Github settings but it doesn't help anything.

EDIT: Just checked, it will happen even if I try to clone a non-existent repository.

Answer 1

This error is also commonly hit when you're on a corporate network that performs MITM on all traffic, and then blocks the revocation check. While, obviously, the ideal situation is to not block the checks (or at least, to a whitelist of urls), it may be required to work around this problem.

One option is, as in the first part of Mike's answer, using the OpenSSL bindings instead. While this works, it requires manual maintenance of the certificate lists, which may not be practical in extreme situations (say, new root certs issued every day, although this is unlikely).

The other option, akin to the second part of Mike's answer, is disabling revocation checking.
Recent versions, 2.19 and above, of git-for-windows provides an http.schannelCheckRevoke setting:

Used to enforce or disable certificate revocation checks in cURL when http.sslBackend is set to "schannel". Defaults to true if unset. Only necessary to disable this if Git consistently errors and the message is about checking the revocation status of a certificate. This option is ignored if cURL lacks support for setting the relevant SSL option at runtime.

... so you can simply disable checking for revocation in the first place:
git config --global http.schannelCheckRevoke false

Note that, unlike disabling SSL entirely, this is not inherently less secure than using Mike's answer for specific repositories: if you capture and configure an empty revocation list (the usual case), you have effectively disabled revocation checking. Disabling revocation checking only becomes a risk in the case of private-key compromise (at some point in the chain), which is rare and difficult.

Note, also, that in a corporate MITM setting, revocation checking is being performed for you: no proxy worth using would issue a cert for an invalid or (known) compromised certificate.

Answer 2

It's always a bad idea to disable certificate verification (setting http.sslVerify to false).

I think the problem here is that, when you installed git, you opted to use the Windows Secure Channel library instead of the OpenSSL library:

As pointed out by @CurtJ.Sampson (thanks, Curt!), you can switch to using the OpenSSL library instead, which will fix your issue. This can be done with the following command:

git config --global http.sslBackend openssl

Alternatively, you can re-install git, specifying the OpenSSL library in the process.

Don't forget to turn git SSL verification back on with:

git config --global http.sslVerify true

Update: If you're using self-signed or corporate certificates on your own git server, and you get an error when attempting to connect to it (such as self signed certificate in certificate chain, or SSL certificate problem: unable to get local issuer certificate), then the solution is to tell git where to find the CA that was used to sign that site's certificate. You can do this with the following configuration command:

git config --global http.{your site's URL here}.sslcainfo "{path to your cert file}"

For example, if you have a local git server at https://my.gitserver.com/ and the CA that signed the site's certificate is in C:\Certs\MyCACert.crt, then you'll need to enter:

git config --global http.https://my.gitserver.com/.sslcainfo "C:\Certs\MyCACert.crt"

This is a more robust solution compared to adding your CA certificate to git's bundled ca-bundle.crt file, since that file will be overwritten when you next update git.

Answer 3

i got this error while working with vagrant(Installed Version: 2.2.16) on windows 10, caused by kaspersky anti-virus and got resolved when i added the sites vagrantcloud.com and cloud-images.ubuntu.com in trusted addressed for the antivirus to allow the encryted connections to be scanned and allowed as a trusted site. more information about antivirus setting changes can be found at https://support.kaspersky.com/KIS/2019/en-US/157530.htm

Fyi, The anti-virus softwares are known to cause such errors, all you need to do is to identify the site from where the download is taking place and add this to the trusted addresses for the antivirus program. in my case it was kaspersky anti virus. may be running the command using --debug to get the adjact site would be a good idea.