Introduction

When GitHub access fails over HTTPS behind a corporate firewall, the problem is often not GitHub's certificate at all. The usual cause is TLS interception by a proxy or firewall that substitutes its own certificate chain, which your machine does not trust.

That is why the same URL works on a home network and fails inside the office. The connection path changed, and so did the certificate chain presented to the client.

What Is Usually Happening

Many enterprise firewalls inspect outbound HTTPS. To do that, they terminate the TLS session, inspect the traffic, and create a new certificate for the destination on the fly. Your browser, Git client, or package manager will trust that only if the corporate root certificate is installed in the local trust store.

Typical symptoms include:

• certificate signed by unknown authority
• self-signed certificate in certificate chain
• unable to get local issuer certificate
• SSL certificate problem when running git clone or git fetch

The fix is almost always "trust the correct corporate root" rather than "disable SSL verification."

How To Inspect the Presented Certificate

Use openssl to see what certificate chain you are actually getting on the affected network:

openssl s_client -connect github.com:443 -servername github.com -showcerts

If the issuer looks like an internal security appliance instead of a public CA, TLS inspection is happening.

You can also inspect what Git itself is seeing:

GIT_CURL_VERBOSE=1 git ls-remote https://github.com/octocat/Hello-World.git

That often reveals whether the failure comes from certificate trust, proxy configuration, or a blocked outbound connection.

Fixing It Correctly

The correct fix depends on whether the environment is managed.

Corporate Machine

Ask the IT or security team for the root CA certificate used by the firewall or proxy. It should be installed into the operating system trust store or the Git trust store, depending on how Git is configured.

Git Using a Custom CA File

If Git is not using the system store, point it at the enterprise root certificate:

git config --global http.sslCAInfo /path/to/corporate-root.pem

If a proxy is required, configure that explicitly too:

git config --global http.proxy http://proxy.example.com:8080
git config --global https.proxy http://proxy.example.com:8080

Windows Environments

Git for Windows may use either the Windows certificate store or its own CA bundle depending on configuration. Check:

git config --global http.sslBackend schannel

Using schannel lets Git rely on the Windows trust store, which is often the cleanest option on managed desktops.

What Not To Do

Do not "solve" this with:

git config --global http.sslVerify false

That disables server identity verification and defeats the point of HTTPS. It may get a clone working temporarily, but it also makes the client vulnerable to real interception.

If you are in a corporate environment, security teams usually have an approved trust-chain procedure. Use it.

Additional Checks

If certificate trust still looks correct, inspect the basics:

• system clock is accurate
• proxy settings are correct
• GitHub is allowed on port 443
• no stale custom CA bundle is overriding the system store

A wrong system date alone can make a valid certificate look expired or not yet valid.

Common Pitfalls

• Blaming GitHub when the actual certificate is being replaced by a firewall.
• Disabling SSL verification instead of fixing the trust chain.
• Importing the proxy certificate into the browser only, while Git uses a different trust store.
• Forgetting to configure the required HTTP or HTTPS proxy.
• Ignoring the system clock and CA bundle age during troubleshooting.

Summary

• SSL rejection behind a firewall is often caused by corporate TLS inspection.
• Use openssl s_client and Git verbose output to inspect the presented chain.
• Trust the correct corporate root CA instead of disabling verification.
• On Windows, schannel often makes Git use the system trust store cleanly.
• Treat http.sslVerify false as a last-resort debugging step, not a real fix.