The Error ScenarioYou're mid-workflow, ready to push a critical update, when Git suddenly stops you cold. Instead of the usual progress bar, you get a wall of text ending in a frustrating error:
fatal: unable to access 'https://github.com/...': SSL certificate problem: self signed certificate in certificate chain
This usually happens when Git can't verify the identity of the server. While it looks like GitHub or GitLab is down, the culprit is almost always sitting right on your local machine or within your office network.
Why is Git blocking your connection?Git relies on the cURL library for network communication. When you connect via HTTPS, Git expects a certificate signed by a globally trusted Certificate Authority (CA). The "self signed certificate" error usually triggers for one of three reasons:
- Corporate Proxies and Inspection: Security tools like Zscaler, Fortinet, or Blue Coat often intercept traffic to scan for threats. They replace the real GitHub certificate with a company-issued one that Git doesn't recognize.- Local Antivirus Interference: Suites like Kaspersky or Bitdefender sometimes inject themselves into the SSL chain to monitor web traffic, effectively acting as a 'friendly' man-in-the-middle.- Outdated CA Bundles: Your Git installation might be looking for certificates in an old
ca-bundle.crtfile that hasn't been updated in years.## Solution 1: The Quick (and Insecure) WorkaroundIf you're on a tight deadline and working on a private, trusted network, you can bypass the check. Use this with caution: disabling SSL verification makes you vulnerable to Man-in-the-Middle (MitM) attacks. It's like leaving your front door unlocked because the key is stuck. To disable verification globally:
git config --global http.sslVerify false
If you only want to skip the check for a single command:
git -c http.sslVerify=false clone https://github.com/username/repo.git
Solution 2: Use the Windows Secure Channel (Recommended for Windows)If you are on a Windows machine, this is the most elegant fix. By default, Git uses the OpenSSL library, which maintains its own separate list of trusted certificates. You can tell Git to use the Windows Certificate Store instead.
git config --global http.sslBackend schannel
This allows Git to automatically trust any certificate your IT department has already approved via Group Policy. It's a 'set it and forget it' solution that maintains high security.
Solution 3: Adding the Corporate CA CertificateWhen you must use OpenSSL (common on Linux and macOS), you need to manually teach Git to trust your company’s root certificate.
Step 1: Get the CertificateOn Windows, open the repository URL in Chrome. Click the Lock icon > Connection is secure > Certificate is valid. In the Details tab, find the top-level certificate in the hierarchy and export it as a Base-64 encoded X.509 (.CER) file.
On macOS or Linux, you can pull the certificate chain directly using this command:
openssl s_client -showcerts -connect github.com:443 </dev/null
Step 2: Point Git to the FileOnce you have the file (e.g., company-root.pem), tell Git where to find it:
git config --global http.sslcainfo "C:/Users/YourName/certs/company-root.pem"
VerificationTest your connection without modifying any code by running ls-remote. This command asks the server for a list of branches and tags.
git ls-remote https://github.com/your-org/your-repo.git
If you see a list of hashes and refs, you've successfully cleared the hurdle.
Navigating Corporate NetworksDebugging connectivity in an enterprise environment often feels like detective work. If you suspect your IP is being routed strangely, tools like the IP Subnet Calculator can help you verify if you're hitting an internal gateway or a public-facing proxy. I often use it to define NO_PROXY ranges for internal GitLab instances.
Finally, check your environment variables. Run env | grep -i proxy in your terminal. If you see a proxy defined, ensure your HTTP_PROXY and HTTPS_PROXY settings are consistent. A mismatch here is a common source of SSL handshake failures.