github - 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:UsersJohn DoeworkspaceMyProject'...
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.