How to fix fatal: unable to access 'https://github.com/': SSL certificate problem: unable to get local issuer certificate in Git

GitINTERMEDIATEMEDIUMUpdated May 28, 2026· 795 views

Git can't verify the remote's SSL/TLS certificate because the signing Certificate Authority isn't in your trust store. Common in corporate proxy networks, with self-signed certs, or outdated CA bundles.

Quick fix

Fixes fatal: unable to access 'https://github.com/': SSL certificate problem: unable to get local issuer certificate

# Configure Git to use Windows Secure Channel (SChannel)
git config --global http.sslBackend schannel
  1. Configure Git to use Windows certificate store (Windows users)
  2. Update system CA certificates
  3. Configure Git to use a specific CA bundle
  4. Add the missing CA certificate to the system trust store
git — error
# Configure Git to use Windows Secure Channel (SChannel)
git config --global http.sslBackend schannel
fatal: unable to access 'https://github.com/': SSL certificate problem: unable to get local issuer certificate

What this error means

The "SSL certificate problem: unable to get local issuer certificate" error occurs when Git's SSL/TLS layer cannot complete the certificate verification chain. Every SSL certificate is signed by a Certificate Authority (CA), and your system maintains a list of trusted CAs. When Git connects to a remote server over HTTPS, it checks whether the server's certificate chains up to a CA in this trust store. This error indicates that the issuing CA certificate is missing from your system's trust store. This commonly happens in several scenarios: - **Corporate proxy environments** where security appliances intercept HTTPS traffic and re-sign certificates with a corporate CA - **Outdated system CA certificates** that don't include newer Certificate Authorities - **Self-signed certificates** used by private Git servers that aren't trusted by default - **Windows Git installations** that default to using a bundled certificate store instead of the Windows certificate store - **Network configurations** where intermediate certificates are not properly served by the remote server The underlying issue is that Git uses OpenSSL or the native TLS library to verify certificates, and the issuing CA's certificate must be present in the configured certificate store for verification to succeed.

Typical symptoms

  • git clone fails with 'SSL certificate problem: unable to get local issuer certificate'
  • git push or git pull fails with SSL certificate errors
  • git fetch from HTTPS remotes returns certificate verification errors
  • The same Git operations work on other machines but fail on yours
  • Error occurs only when connected to a corporate VPN or network
  • Error started appearing after a system update or Git upgrade
  • Git operations work over SSH but fail over HTTPS
  • The error appears when accessing GitHub, GitLab, Bitbucket, or private Git servers

Common causes

  1. Corporate proxy/firewall intercepts HTTPS traffic and re-signs certificates with its own CA
  2. System CA certificates are outdated and don't include the required Certificate Authority
  3. Git for Windows is configured to use its bundled certificate store instead of Windows certificates
  4. Private Git server uses a self-signed certificate not trusted by the system
  5. The server is not sending the complete certificate chain (missing intermediate certificates)
  6. System date/time is incorrect, causing valid certificates to appear expired or not yet valid
  7. OpenSSL or the certificate bundle file has become corrupted
  8. Environment variables override the default certificate store location

How to fix "fatal: unable to access 'https://github.com/': SSL certificate problem: unable to get local issuer certificate"

1Configure Git to use Windows certificate store (Windows users)

On Windows, Git often uses its own bundled certificate store instead of the Windows system certificates. This is the most common cause of SSL errors on Windows systems, especially in corporate environments.

bash
# Configure Git to use Windows Secure Channel (SChannel)
git config --global http.sslBackend schannel

This tells Git to use the Windows certificate store, which includes certificates installed by your IT department or added via Windows Update.

If you need to revert to the bundled OpenSSL certificates:

bash
git config --global http.sslBackend openssl

For Visual Studio users, you can also configure this in Git settings:
1. Open Visual Studio
2. Go to Git > Settings > Git Global Settings
3. Change "Cryptographic Network Provider" from "Unset" to "Secure Channel"

2Update system CA certificates

Outdated CA certificates are a common cause of this error. Update your system's certificate store:

Ubuntu/Debian:

bash
sudo apt update
sudo apt install --reinstall ca-certificates
sudo update-ca-certificates

RHEL/CentOS/Fedora:

bash
sudo yum update ca-certificates
# or on Fedora
sudo dnf update ca-certificates
sudo update-ca-trust

macOS:

bash
# Homebrew users can update OpenSSL
brew update
brew upgrade openssl

Windows:
- Run Windows Update to get the latest root certificates
- Or download updated certificates from Microsoft's Root Certificate Program

3Configure Git to use a specific CA bundle

You can tell Git exactly which certificate bundle to use for SSL verification:

bash
# Find where Git is looking for certificates
git config --list | grep -i ssl

# Set a specific CA bundle file
git config --global http.sslCAInfo "/path/to/ca-bundle.crt"

Common CA bundle locations:

Git for Windows:

bash
git config --global http.sslCAInfo "C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt"

Linux:

bash
git config --global http.sslCAInfo /etc/ssl/certs/ca-certificates.crt

macOS with Homebrew:

bash
git config --global http.sslCAInfo $(brew --prefix)/etc/openssl@3/cert.pem
4Add the missing CA certificate to the system trust store

If verification still fails, you need to trust the issuing CA certificate (for example, a corporate root CA or the self-signed CA of a private Git server). Add the CA — not the server's leaf certificate — to your system trust store so it survives CA updates and is picked up by all tools.

Step 1: Identify and export the issuing CA

Inspect the chain the server presents and confirm which certificate is the issuer/root rather than the leaf:

bash
# Show the full chain the server sends
openssl s_client -showcerts -connect github.com:443 </dev/null 2>/dev/null

In the output, the first certificate (s: matching the hostname) is the server's leaf; the certificate(s) above it, ending in a self-signed root (where subject == issuer), are the CA(s) you must trust. In a corporate-proxy setup, export your organization's root CA from IT or your browser's certificate viewer instead of scraping it from the wire. Save the CA in PEM format as issuing-ca.crt.

Step 2: Install the CA into the system trust store

Do not edit /etc/ssl/certs/ca-certificates.crt (or /etc/pki/tls/certs/ca-bundle.crt) directly — those files are auto-generated by update-ca-certificates/update-ca-trust and your change would be wiped out on the next update. Drop the CA into the managed source directory instead:

Debian/Ubuntu:

bash
# File must have a .crt extension and PEM contents
sudo cp issuing-ca.crt /usr/local/share/ca-certificates/issuing-ca.crt
sudo update-ca-certificates

RHEL/CentOS/Fedora:

bash
sudo cp issuing-ca.crt /etc/pki/ca-trust/source/anchors/issuing-ca.crt
sudo update-ca-trust extract

macOS (system Keychain):

bash
sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain issuing-ca.crt

Windows: Import the CA into the Local Machine > Trusted Root Certification Authorities store, then set git config --global http.sslBackend schannel so Git uses it.

If you cannot modify the system store, point Git at a dedicated bundle that includes the CA instead (see Step 3 with http.sslCAInfo), rather than appending to the system-managed file.

5Handle corporate proxy SSL interception

If you're behind a corporate proxy that intercepts HTTPS traffic, you need to install your company's root CA certificate:

Step 1: Get the corporate CA certificate
- Contact your IT department for the root CA certificate
- Or export it from your browser's certificate viewer

Step 2: Add to the trust store

Windows:
1. Import the certificate into the Windows Certificate Store (Local Machine > Trusted Root Certification Authorities)
2. Configure Git to use Windows certificates:

bash
git config --global http.sslBackend schannel

Linux:

bash
# Install the corporate CA into the managed source directory (not the generated bundle)
sudo cp corporate-ca.crt /usr/local/share/ca-certificates/corporate-ca.crt
sudo update-ca-certificates

# Or point Git directly at a bundle containing the CA
git config --global http.sslCAInfo /path/to/corporate-ca-bundle.crt

Verify the proxy is intercepting:

bash
# Check the certificate issuer - if it's your company, the proxy is intercepting
curl -v https://github.com 2>&1 | grep -i "issuer"
6Verify system date and time

SSL certificates have validity periods. If your system clock is wrong, valid certificates may appear expired or not yet valid:

bash
# Check current system time
date

# On Linux, sync with NTP
sudo timedatectl set-ntp true

# Or manually set the time
sudo timedatectl set-time "2025-01-15 10:30:00"

# On Windows, sync time via Settings > Time & Language > Date & time

After correcting the time, retry your Git operation. This is especially common on virtual machines or systems that have been suspended for long periods.

7Temporarily disable SSL verification (development only, last resort)

Warning: Disabling SSL verification removes protection against man-in-the-middle attacks. Exhaust the secure options above (install the issuing CA, fix the CA bundle, sync the clock) first. Only use this to confirm the problem is SSL-related, in an isolated development environment, and never against production or sensitive repositories.

bash
# Disable SSL verification for a single command only (preferred over global config)
GIT_SSL_NO_VERIFY=true git clone https://example.com/repo.git

# Disable for a specific repository only (scoped, not global)
git config http.sslVerify false

# Disable for a specific domain only
git config --global http.https://example.com/.sslVerify false

Avoid the blanket git config --global http.sslVerify false, which silently disables verification for every host and every future clone. If you set verification off anywhere, re-enable it as soon as you have a proper fix:

bash
git config --global http.sslVerify true
# and remove any repo- or host-scoped overrides you added
git config --unset http.sslVerify

Advanced notes

Understanding certificate chains:
SSL certificates form a chain of trust: your server's certificate (the leaf) is signed by an intermediate CA, which is signed by a root CA. To trust the connection, the issuing CA (intermediate and/or root) must be in your trust store — adding only the leaf certificate is not the correct fix. View the full chain with:

bash
openssl s_client -showcerts -connect github.com:443 </dev/null 2>/dev/null

The first certificate is the leaf; certificates where subject equals issuer are self-signed roots.

Git's SSL backend options:
- openssl - Uses the OpenSSL library with bundled certificates (default on most systems)
- schannel - Uses Windows Secure Channel (Windows certificate store)
- secure-transport - Uses macOS Secure Transport (Keychain)

Check the current backend:

bash
git config --global http.sslBackend

Environment variables that affect SSL:
- GIT_SSL_NO_VERIFY - If set to any value, disables SSL verification
- GIT_SSL_CAINFO - Path to CA certificate file
- GIT_SSL_CAPATH - Path to a directory containing CA certificates
- SSL_CERT_FILE - Used by OpenSSL for the certificate file location
- SSL_CERT_DIR - Used by OpenSSL for the certificate directory

Debugging SSL issues:

bash
# Verbose Git output showing SSL details
GIT_CURL_VERBOSE=1 git clone https://github.com/user/repo.git

# Test the SSL connection directly against a specific CA bundle
openssl s_client -connect github.com:443 -CAfile /path/to/ca-bundle.crt

# Verify a certificate against a CA bundle
openssl verify -CAfile /path/to/ca-bundle.crt server-cert.pem

For CI/CD pipelines:
If you see this error in CI/CD, ensure the build container has updated CA certificates:

dockerfile
# Dockerfile example
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y ca-certificates git

Or for Alpine-based images:

dockerfile
FROM alpine:3.18
RUN apk add --no-cache ca-certificates git

To add a corporate CA in CI, copy it into /usr/local/share/ca-certificates/ (Debian) or /etc/pki/ca-trust/source/anchors/ (RHEL) and run the update command, rather than baking GIT_SSL_NO_VERIFY into the pipeline.

Frequently asked questions

What does "fatal: unable to access 'https://github.com/': SSL certificate problem" mean?
The "SSL certificate problem: unable to get local issuer certificate" error occurs when Git's SSL/TLS layer cannot complete the certificate verification chain. Every SSL certificate is signed by a Certificate Authority (CA), and your system maintains a list of trusted CAs. When Git connects to a remote server over HTTPS, it checks whether the server's certificate chains up to a CA in this trust store.
How do I fix "fatal: unable to access 'https://github.com/': SSL certificate problem"?
Git can't verify the remote's SSL/TLS certificate because the signing Certificate Authority isn't in your trust store. Common in corporate proxy networks, with self-signed certs, or outdated CA bundles.
What causes "fatal: unable to access 'https://github.com/': SSL certificate problem"?
Corporate proxy/firewall intercepts HTTPS traffic and re-signs certificates with its own CA System CA certificates are outdated and don't include the required Certificate Authority Git for Windows is configured to use its bundled certificate store instead of Windows certificates
Is the "fatal: unable to access 'https://github.com/': SSL certificate problem" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading