Fix Git HTTPS certificate errors safely

Updated October 24, 2026.

Security correction: An earlier version of this post recommended disabling Git's HTTPS certificate verification globally. That advice has been replaced. Keep verification enabled and repair the certificate, hostname or trust configuration responsible for the failure.

A certificate error is a reason to investigate before sending credentials or code. Disabling verification removes an important check on who receives the connection. The curl certificate-verification guide explains the distinction between trusting the issuer and matching the server name.

1. Restore verification

If you previously disabled verification globally, restore it:

git config --global http.sslVerify true

Run the following inspection inside the affected repository:

git config --show-origin --show-scope --get-regexp '^http\..*(sslverify|sslcainfo|sslbackend|schannelusesslcainfo)$'
git config --get-urlmatch http.sslVerify https://git.example.com/team/repo.git

Replace the illustrative URL with your remote. Origins and scopes identify conflicting settings; URL matching finds host-specific configuration. Repository, worktree, command-line and URL-specific settings can still defeat a global correction. Review the reported source, then remove or correct the unsafe entry. An unset query is not itself evidence of failure: verification defaults to enabled. See Git's configuration reference.

Also inspect the environment of the actual Git process, including IDE launchers and CI jobs. Remove GIT_SSL_NO_VERIFY rather than assigning it a reassuring-looking value. Git documents this variable as disabling verification when set. Check wrappers for command-line overrides and injected GIT_CONFIG_COUNT/GIT_CONFIG_KEY_*/GIT_CONFIG_VALUE_* settings. See the Git environment documentation and configuration environment reference.

2. Repair the underlying cause

Write down the exact error and remote hostname. A missing intermediate belongs in the server's certificate deployment. An expired certificate needs replacement. A hostname mismatch needs a corrected URL or a certificate covering the intended hostname. Adding a CA cannot fix those identity mistakes.

For an approved private CA, obtain the CA bundle through your organization's authenticated administrator or PKI channel. Verify its provenance independently. Never promote a certificate downloaded from the failing connection into a trusted authority merely to clear the error.

For a file-based TLS backend, this illustrative configuration limits a CA file to one HTTPS host:

git config --global http.https://git.example.com/.sslCAInfo /approved/path/company-ca-bundle.pem

http.sslCAInfo selects a verification certificate file; GIT_SSL_CAINFO can override it. With Windows Schannel, prefer the managed Windows certificate store. Git normally avoids using this bundle when Schannel is explicitly selected; http.schannelUseSSLCAInfo changes that behavior and can replace native-store trust. Check the official Schannel guidance before mixing approaches.

3. Retest without pushing changes

After reviewing configuration and environment, use git ls-remote origin against your authorized remote. This checks connectivity without updating remote branches, though authentication may still be required. Keep certificate and revocation checks enabled. Record the successful result from the same machine and process context that failed.

For the detailed diagnostic workflow, read TLS certificate chain vs hostname errors: a practical troubleshooting checklist.