fatal: unable to access 'https://git.example.com/team/app.git/': SSL certificate problem: unable to get local issuer certificate

The URL is your remote. With libcurl 8.22 (and possibly other recent releases) the reason reads "SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)". Debian and Ubuntu builds of git use GnuTLS and print "server verification failed: certificate signer not trusted" instead.

What it means

git's HTTPS transport uses libcurl, and libcurl with OpenSSL could not find the CA that issued the last certificate the Git server sent. Either the server leaves out its intermediate, or the chain ends at a root (company CA, proxy CA) that is not in the bundle git uses. On Windows this is the classic symptom of Git for Windows checking against its own bundled CA file instead of the Windows certificate store.

Why it happens

• Git for Windows checks its own CA file, not the Windows store

  common

  With the default OpenSSL backend, Git for Windows verifies against the ca-bundle.crt it ships. Company roots and proxy roots that IT deploys into the Windows certificate store are not in that file, so clones fail while browsers work.

• A self-hosted Git server with a private CA

  common

  GitLab, Gitea, Bitbucket Data Center or Azure DevOps Server installations often use certificates from an internal CA that CI images and new machines do not trust.

• The server omits its intermediate certificate

  occasional

  If the quoted issuer is a public intermediate, the Git server or its reverse proxy is configured with the leaf certificate only.

• An http.sslCAInfo or GIT_SSL_CAINFO override replaces the bundle

  occasional

  A CA file set for one internal host but configured globally replaces the default bundle for every remote, so public hosts start failing (or the reverse, after the file was moved).

How to fix it

1. 1.

   Windows: switch git to the Windows certificate store

   With http.sslBackend schannel, Git for Windows verifies through Windows itself and accepts every root that Windows trusts, including those deployed by group policy. This is the clean fix for corporate networks.

   # Git for Windows: verify with the Windows certificate store, where IT deploys company roots
   git config --global http.sslBackend schannel
   git config --global --get http.sslBackend

2. 2.

   Trust the CA for one Git host

   A URL-scoped http.<url>.sslCAInfo adds the private CA for that host only; GIT_SSL_CAINFO applies to one command or job.

   git config --global http."https://git.example.com/".sslCAInfo /etc/ssl/private-ca/corp-root-ca.pem
   # one command or CI job only
   GIT_SSL_CAINFO=/etc/ssl/private-ca/corp-root-ca.pem git clone https://git.example.com/team/app.git

3. 3.

   Install the root into the system bundle

   On Linux the system bundle is what libcurl reads by default, so adding the root there fixes git together with curl and package managers.

   # Alpine / Debian / Ubuntu
   cp corp-root-ca.pem /usr/local/share/ca-certificates/corp-root-ca.crt && update-ca-certificates
   # RHEL / Fedora
   cp corp-root-ca.pem /etc/pki/ca-trust/source/anchors/ && update-ca-trust

4. 4.

   Look for an override that replaces the bundle

   --show-origin tells you which config file sets a CA path. Remove global overrides that should have been host-scoped.

   git config --show-origin --get-all http.sslCAInfo
   git config --show-origin --get-regexp 'http\..*\.sslcainfo'
   env | grep -E 'GIT_SSL_CAINFO|CURL_CA_BUNDLE|SSL_CERT_FILE'

5. 5.

   Temporary diagnostic: skip verification for one command

   Use -c http.sslVerify=false only to confirm the diagnosis, never in global config: it exposes credentials and lets anyone on the path modify the code you fetch.

   # Diagnostic only, for one command
   git -c http.sslVerify=false ls-remote https://git.example.com/team/app.git

← Browse the full signature error database