Fixing Git "fatal: unable to access …: SSL certificate problem"

What this error means

Git uses libcurl to connect over HTTPS. The error “fatal: unable to access …: SSL certificate problem” means TLS verification failed because Git could not build a chain of trust from the server’s certificate to a trusted Certificate Authority (CA). Common causes:

• Your CA store is outdated or missing
• A corporate proxy (TLS inspection/MITM) presents a custom CA
• The server uses a self-signed or privately-issued certificate
• System time is wrong, making certs appear expired/not yet valid

Avoid disabling verification globally; fix trust correctly instead.

Quickstart: the fastest safe fixes

Pick the scenario that matches your environment.

• Corporate proxy with custom CA

  • Obtain the proxy/inspection root CA (in PEM format) from your IT portal or browser export
  • Save as a file (e.g., ~/.config/git/proxy-ca.pem)
  • Configure Git to trust it:
    • Linux/macOS: git config --global http.sslCAInfo ~/.config/git/proxy-ca.pem
    • Windows (Git for Windows): prefer the OS store (see below) or set a file path

• Linux (public CAs, no proxy)

  • Update CA store, then ensure Git uses it:
    • Debian/Ubuntu: sudo apt-get update && sudo apt-get install -y ca-certificates and git config --system http.sslCAInfo /etc/ssl/certs/ca-certificates.crt
    • RHEL/CentOS/Fedora: sudo dnf install -y ca-certificates and git config --system http.sslCAInfo /etc/pki/tls/certs/ca-bundle.crt

• Windows (Git for Windows)

  • Use the Windows certificate store to avoid managing files:
    • git config --global http.sslBackend schannel
    • Import your corporate root CA into “Trusted Root Certification Authorities” via certmgr.msc

• macOS

  • If you have a custom CA, export it to PEM and point Git to it:
    • git config --global http.sslCAInfo ~/certs/custom-ca.pem
  • Alternatively, add the CA to System Keychain and use a Git build that trusts the keychain, or use the PEM file approach above for consistency.

• Alternative: use SSH instead of HTTPS

  • If allowed: git remote set-url origin [email protected]:org/repo.git and set up SSH keys. This bypasses HTTPS certificates entirely.

Minimal working example

This example shows verifying a Git host using a supplied CA and making a successful authenticated call.

# 1) Save the corporate/custom root CA to a PEM file
mkdir -p ~/.config/git
cp /path/from/it/CorpRootCA.pem ~/.config/git/proxy-ca.pem

# 2) Test HTTPS with curl using the CA (should succeed)
curl -v --cacert ~/.config/git/proxy-ca.pem https://github.com/

# 3) Try a Git operation with explicit verification and CA file
git -c http.sslVerify=true \
    -c http.sslCAInfo=~/.config/git/proxy-ca.pem \
    ls-remote https://github.com/git/git

# 4) Persist the configuration for all repos
git config --global http.sslCAInfo ~/.config/git/proxy-ca.pem

# 5) Verify normal operations work
git fetch

Windows (Git for Windows) using the OS store:

# Prefer Windows trust store via Schannel
git config --global http.sslBackend schannel

# Import the corporate CA into Trusted Root (run as a user with rights)
# Right-click the .cer/.crt file -> Install Certificate -> Local Machine ->
# Trusted Root Certification Authorities.

# Test
$env:GIT_CURL_VERBOSE = '1'
git ls-remote https://github.com/git/git

Step-by-step diagnosis

1. Check time and date

• Ensure system clock and timezone are correct. Certs outside validity windows fail.

1. Turn on verbose logs

• GIT_CURL_VERBOSE=1 GIT_TRACE=1 git ls-remote https://example.com/repo.git
• Look for messages about “SSL certificate problem” and which CA path is used.

1. Detect proxies

• env | grep -i proxy (Linux/macOS) or Get-ChildItem Env:*proxy* (Windows)
• If a proxy is set, you likely need the proxy’s root CA.

1. Inspect the server’s certificate chain

• openssl s_client -showcerts -servername example.com -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates
• Verify issuer aligns with a trusted CA (public or your corporate CA).

1. Check your Git SSL config

• git config --show-origin --get http.sslCAInfo
• git config --show-origin --get http.sslCAPath
• git config --show-origin --get http.sslBackend

1. Update CA certificates (Linux)

• Debian/Ubuntu: sudo apt-get install -y ca-certificates && sudo update-ca-certificates
• RHEL/CentOS/Fedora: sudo dnf install -y ca-certificates && sudo update-ca-trust

OS-specific references

• Linux default CA bundles

  • Debian/Ubuntu: /etc/ssl/certs/ca-certificates.crt
  • RHEL/CentOS/Fedora: /etc/pki/tls/certs/ca-bundle.crt
  • Alpine: /etc/ssl/certs/ca-certificates.crt (apk add ca-certificates)

• Windows (Git for Windows)

  • Prefer: git config --global http.sslBackend schannel to use the Windows store
  • Otherwise, set http.sslCAInfo to a PEM file you manage

• macOS

  • Add custom CA to System Keychain and trust it, or export PEM and use http.sslCAInfo

Common fixes by cause

• Outdated CA store

  • Update your CA packages (see above) and ensure Git points to the system bundle.

• Corporate TLS inspection

  • Obtain the proxy root CA, trust it (OS store or http.sslCAInfo), and retry.

• Self-signed server certs

  • Prefer issuing a server cert from an internal CA. If not possible, add the self-signed cert (PEM) to a trusted store and reference it with http.sslCAInfo.

• Incorrect intermediate chain on server

  • The remote may not serve intermediates. Work with the server admin to present a full chain. As a temporary workaround, import the required intermediate CA into your trust store.

Pitfalls to avoid

• Disabling verification permanently

  • git config --global http.sslVerify false is insecure. If you must test, use -c http.sslVerify=false once, never persist it.

• Wrong file format

  • Git expects PEM for http.sslCAInfo. Convert from DER: openssl x509 -inform der -in in.cer -out out.pem.

• Mixing SSL backends

  • On Windows, using schannel while also pointing to a custom bundle can confuse troubleshooting. Choose one approach.

• Storing CA files in volatile locations

  • Keep CA files in a stable, backed-up path with correct permissions.

Performance notes

• Certificate verification overhead is small (milliseconds). The main costs are network latency and authentication.
• Using the OS certificate store (Windows Schannel, macOS Keychain-backed builds) can reduce per-process file parsing compared to very large custom bundles.
• Avoid excessively large http.sslCAPath directories; prefer a single consolidated bundle when practical.
• Reuse connections by running fewer separate Git processes (e.g., fetch multiple refs in one fetch) and enable a credential helper to avoid repeated 401/NTLM handshakes.

Tiny FAQ

• What does this error mean?

  • Git could not verify the server’s certificate against a trusted CA.

• Is it safe to set http.sslVerify=false?

  • Only for a one-off diagnostic. Never persist it; it exposes you to MITM attacks.

• Why does it work in a browser but not Git?

  • Your browser trusts the corporate CA via the OS store; Git may be using a separate bundle. Align Git with the OS store or add the CA to Git’s bundle.

• How do I export the proxy’s root CA?

  • From the browser’s certificate viewer or via your IT portal. Save as PEM and configure Git to use it.

• Why do only some remotes fail?

  • Different hosts have different issuers or incomplete chains. Trust for one CA does not guarantee trust for another.

• Can switching to SSH help?

  • Yes. SSH avoids HTTPS and the TLS certificate chain entirely, if your organization allows SSH access.