The Problem
It usually happens when you're in the middle of a routine git clone or push. Instead of a successful transfer, Git blocks the connection and throws a cryptic error about a "local issuer certificate."
fatal: unable to access 'https://github.com/user/repo.git/': SSL certificate problem: unable to get local issuer certificate
At its core, Git is being paranoid for your safety. It refuses to connect because it can't verify that the server you're talking to—whether it's GitHub, GitLab, or a private Bitbucket instance—is legitimate. The chain of trust back to a recognized Root Certificate Authority (CA) is broken.
TL;DR: The Quick Fixes
If you are on Windows, use this command to solve 90% of these issues instantly:
git config --global http.sslBackend schannel
For those in a temporary bind where security is not a concern (like a closed local lab), you can bypass the check entirely. Use this sparingly:
git config --global http.sslVerify false
Why Does This Happen?
When you establish an HTTPS connection, the server presents an SSL certificate. Git checks this against its local "address book" of trusted authorities. If the ID doesn't match or the signer is unknown, Git kills the connection.
Common culprits include:
- Corporate Firewalls: Systems like Zscaler or Fortinet often intercept traffic to scan for threats. They replace the real certificate with a corporate one that Git doesn't recognize.
- Stale Certificates: Your local Git installation might be using a CA bundle from two years ago that doesn't include newer authorities.
- System Mismatch: Git for Windows sometimes ignores the certificates your OS already trusts, looking instead for a specific
ca-bundle.crtfile that might be missing.
Fix Approaches
1. Switch to Windows Secure Channel (Best for Windows)
Standard Git installations use the OpenSSL library. OpenSSL is powerful but requires manual maintenance of certificate files. By switching to the "schannel" backend, you tell Git to use the native Windows Certificate Store.
git config --global http.sslBackend schannel
Since Windows already handles updates for Chrome and Edge, this fix usually makes corporate proxies and modern CAs work immediately without manual tweaking.
2. Refresh the CA Bundle Manually
Linux and macOS users often find success by updating the underlying certificate file. You can grab a fresh bundle containing over 100 trusted CAs directly from the curl project.
- Download the latest bundle: curl.se/ca/cacert.pem.
- Move it to a safe spot, like
~/.git-certs/cacert.pem. - Point Git to the new file:
git config --global http.sslcainfo "/home/user/.git-certs/cacert.pem"
3. Adding Your Company's Custom Certificate
If your IT department uses a "Man-in-the-Middle" proxy for security, you need to teach Git to trust that specific proxy. You'll need the .pem or .cer file from your network team.
- Locate your current bundle by running
git config --get http.sslcainfo. If empty, look inC:\Program Files\Git\mingw64\ssl\certs\ca-bundle.crt. - Open that file in a text editor with Administrator privileges.
- Append the entire text of your corporate certificate (including the
BEGINandENDtags) to the bottom.
4. Reinstalling with the Correct Settings
Sometimes a messy configuration is hard to untangle. If you reinstall Git for Windows, pay close attention to the "Choosing HTTPS transport backend" screen. Select "Use the native Windows Secure Channel library." This bakes the schannel fix into your installation from day one.
How to Verify the Fix
Don't waste time with a full 2GB clone just to test the connection. Use ls-remote to ping the server instead:
git ls-remote https://github.com/user/repo.git
If you see a list of commit hashes, you're back in business. If the error persists, check if a local project setting is overriding your global config by running git config --list --show-origin. Look for any http.sslverify entries tucked away in your .git/config file.