If you use Git every day, you may have seen the recent GitHub announcement about removing SHA-1 from HTTPS connections.
At first glance, this can sound like a change to Git itself because Git repositories have historically used SHA-1 for object identifiers. But that is not what this particular GitHub change is about.
GitHub has disabled SHA-1 in HTTPS/TLS connections to GitHub.com and partner CDNs. The change took effect on September 15, 2026. GitHub Enterprise Server is not affected by this change.
For most developers using a current version of Git, there should be no change to normal clone, pull, fetch, and push operations.
The main concern is older Git clients, operating systems, TLS libraries, proxies, and CI/CD environments that still depend on legacy cryptographic support.
This article explains what changed, what it does not change, and how to check whether your Git environment is ready.
What Exactly Changed?
GitHub announced that it would remove SHA-1 from HTTPS connections used by GitHub and its CDNs.
The change affects HTTPS connections involving:
For Git users, the important part is this:
Git client
|
| HTTPS
v
GitHub
The HTTPS connection needs to use modern TLS cryptographic algorithms.
Older clients that cannot negotiate an acceptable modern configuration may fail to establish the connection.
GitHub first announced a temporary brownout for July 14, 2026 to help identify systems that were still relying on SHA-1. The permanent disablement was scheduled for September 15, 2026 and has now taken effect.
This Is Not the Same as Removing SHA-1 From Git Objects
This is the most important distinction.
Git itself has historically used SHA-1 to generate object IDs.
For example, a Git commit can have an identifier that looks like:
4f8b42c1d8f7...
That is related to Git's object hashing.
Git has also been working toward SHA-256 repositories as a longer-term replacement for SHA-1 object hashing.
The GitHub HTTPS change is different.
It concerns the cryptographic algorithms used to establish secure HTTPS/TLS connections.
Think of the two situations separately:
Git Object Hashing
------------------
Commit
|
v
SHA-1 / SHA-256
|
v
Git Object ID
HTTPS Security
--------------
Git Client
|
v
TLS
|
v
GitHub
A GitHub HTTPS connection failing because of an old TLS implementation does not mean the repository's Git object IDs have suddenly changed.
GitHub's documentation and announcement specifically describe the 2026 change as the removal of SHA-1 from HTTPS/TLS.
Why Is GitHub Removing SHA-1 From HTTPS?
SHA-1 is an old cryptographic hash algorithm.
Security research has demonstrated practical collision attacks against SHA-1, which is one reason modern security protocols have moved away from it.
The broader industry has been gradually retiring older cryptographic algorithms and protocols.
GitHub has already made similar changes in other areas of its infrastructure. For example, GitHub previously removed older SSH algorithms and required stronger RSA signature algorithms for newer keys.
The goal is to avoid depending on cryptographic mechanisms that are no longer considered appropriate for modern secure communication.
For developers, the practical lesson is simple:
Old client
|
| Legacy TLS support
v
GitHub
X
Connection may fail
Modern client
|
| Modern TLS support
v
GitHub
|
v
Connection succeeds
Who Can Be Affected?
The change is most relevant to environments running old software.
A modern developer workstation with an up-to-date Git installation will generally already have the required cryptographic support.
Problems are more likely in environments such as:
Old Linux distributions
Old Windows installations
Legacy build servers
Old Git installations
Outdated TLS libraries
Custom Git clients
Embedded systems
Old containers
Long-lived CI/CD agents
Corporate proxies that terminate TLS
Internally maintained developer tools
This is why checking the entire connection path is more useful than checking only the Git version.
Check Your Git Version
Start with the simplest check:
git --version
For example:
git version 2.x.x
A recent Git version is strongly preferred.
GitHub specifically recommends using a recent version of Git together with an up-to-date operating system and supporting components. The exact compatibility also depends on the HTTPS/TLS backend used by the Git installation.
Do not treat the Git version as the only test, though.
A current Git binary can still be running on an old operating system with outdated TLS components.
Check Which HTTPS Backend Git Uses
Git can use different TLS implementations depending on how it was built and packaged.
You can inspect your Git installation with:
git --version --build-options
You can also inspect the Git configuration:
git config --show-origin --get http.sslBackend
If no value is returned, Git may simply be using its default HTTPS backend.
The important point is that Git itself is not necessarily responsible for every part of the TLS connection.
A simplified stack can look like this:
Git
|
v
HTTP layer
|
v
TLS library
|
v
Operating System
|
v
Network / Proxy
|
v
GitHub
An old component anywhere in this chain can become the actual compatibility problem.
Test a GitHub HTTPS Connection
The easiest practical test is to perform a normal Git operation against a repository that you are allowed to access.
For example:
git ls-remote https://github.com/example/example.git
If the connection works, Git should return references from the remote repository.
For an existing project, you can also test:
git fetch
or:
git pull
If your repository uses HTTPS, a successful operation confirms that your current Git environment can establish the required connection to that remote.
GitHub supports both HTTPS and SSH remote URLs for Git operations.
Check Your Remote URL
Before troubleshooting, find out whether your repository actually uses HTTPS.
Run:
git remote -v
You may see:
origin https://github.com/company/project.git (fetch)
origin https://github.com/company/project.git (push)
That repository is using HTTPS.
You may instead see:
origin [email protected]:company/project.git (fetch)
origin [email protected]:company/project.git (push)
That repository is using SSH.
This distinction matters because the 2026 change discussed here specifically concerns SHA-1 in HTTPS/TLS.
What If You Use SSH?
If your Git remote looks like this:
[email protected]:company/project.git
your Git operations are using SSH rather than HTTPS.
The 2026 SHA-1 HTTPS change is therefore not the change affecting that connection.
However, SSH has its own cryptographic compatibility requirements and GitHub has made separate changes to its SSH security over time.
Do not mix the two issues.
For this particular change:
HTTPS Remote
|
+-- Affected by HTTPS SHA-1 removal
SSH Remote
|
+-- Not affected by this specific HTTPS change
GitHub has separately documented its SSH cryptographic changes, including the removal of older SSH algorithms.
Why CI/CD Pipelines Need Extra Attention
A developer's laptop is usually easy to update.
CI/CD servers are different.
You may have:
GitHub
|
v
CI Server
|
+-- Git
+-- OS
+-- TLS libraries
+-- Proxy
+-- Build tools
A pipeline can continue running for years without anyone manually updating its base image.
For example, a pipeline might use an old container:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: dotnet build
In a managed environment, many underlying components are maintained for you.
But self-hosted runners are different.
A self-hosted runner may contain an old:
Operating System
Git
OpenSSL
Certificate store
Proxy configuration
That makes infrastructure maintenance important.
Check Self-Hosted Runners
If your organization uses self-hosted GitHub Actions runners, check:
git --version
Then inspect the operating system.
On Linux:
cat /etc/os-release
You can also check the TLS library installed on the machine.
For OpenSSL-based systems:
openssl version
The exact commands depend on your operating system and how Git was installed.
The goal is not to find one magic version number.
The goal is to identify whether the complete HTTPS stack is modern enough to negotiate the algorithms GitHub now requires.
Corporate Proxies Can Make Troubleshooting Harder
One common source of confusion is a corporate HTTPS proxy.
Your Git client may not connect directly to GitHub.
Instead:
Git
|
v
Corporate Proxy
|
v
Internet
|
v
GitHub
In that setup, the proxy can participate in TLS handling.
This means a developer may have a current Git installation while an old proxy or TLS inspection appliance causes the connection to fail.
If the same repository works from one network but fails from another, investigate the network path rather than immediately reinstalling Git.
Common Errors You May See
The exact error depends on the Git version, operating system, TLS library, and network configuration.
You may see messages related to:
SSL connection
TLS handshake
SSL certificate
connection reset
protocol version
handshake failure
unable to access
For example:
fatal: unable to access 'https://github.com/...':
SSL connection timeout
Or:
SSL_ERROR...
Do not assume every SSL-related error is caused by the SHA-1 change.
Certificate problems, proxy failures, DNS issues, firewall rules, and expired trust stores can produce completely different problems.
The first step should always be to identify the actual TLS and network path.
Use Git Trace Information
Git provides tracing facilities that can help diagnose connection problems.
For example:
GIT_TRACE=1 git ls-remote https://github.com/example/example.git
On Windows PowerShell:
$env:GIT_TRACE="1"
git ls-remote https://github.com/example/example.git
For more detailed HTTP diagnostics, Git also provides:
GIT_CURL_VERBOSE=1 git ls-remote https://github.com/example/example.git
Use verbose tracing carefully.
It can expose connection details and other information that should not be pasted into public issue trackers or logs without review.
Do Not Disable SSL Verification
A common reaction to HTTPS errors is to run:
git config --global http.sslVerify false
This is not a proper solution.
It disables certificate verification and weakens the security of your Git connection.
Do not use it as a permanent workaround for a TLS compatibility problem.
If your organization has a custom certificate authority, configure the trusted certificate chain correctly instead of disabling verification.
For example, investigate:
Git configuration
|
v
Certificate store
|
v
Operating system trust
|
v
Corporate proxy
The correct solution depends on your environment.
Updating Git Is Usually the First Step
If you discover that a machine is using an old Git installation, update it.
After updating, verify:
git --version
Then test:
git ls-remote https://github.com/example/example.git
If the command succeeds, test the actual workflow:
git fetch
git pull
git push
A successful read operation is useful, but a real push is the better test if you have permission to push to the repository.
Update the Operating System Too
Updating Git while leaving an unsupported operating system in place may not solve the problem.
For example:
Old OS
|
+-- Old TLS library
|
+-- New Git
The Git executable may still depend on system libraries or other components that are too old.
A better maintenance approach is:
Operating System
|
v
TLS / Crypto Libraries
|
v
Git
|
v
Application / CI Tool
Keep the entire stack maintained.
What About GitHub Enterprise Server?
There is an important distinction between GitHub.com and GitHub Enterprise Server.
GitHub's September 15, 2026 announcement says the SHA-1 HTTPS disablement applies to GitHub.com and partner CDNs, including GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency.
GitHub Enterprise Server is not affected by this specific change.
If your organization runs GitHub Enterprise Server internally, do not automatically apply the GitHub.com timeline to your installation.
Instead, check the version and security guidance for your specific GitHub Enterprise Server release.
A Practical Compatibility Checklist
If your team uses GitHub over HTTPS, check the following:
Check | What to Verify |
|---|
Git version | Use a current supported version |
Operating system | Keep it maintained |
TLS library | Ensure modern cryptographic support |
Remote URL | Confirm whether Git uses HTTPS or SSH |
CI runners | Check self-hosted runners separately |
Containers | Check the Git and OS versions inside images |
Proxy | Verify TLS inspection compatibility |
Certificates | Keep the trust store current |
Git configuration | Review custom SSL settings |
Production test | Run an actual Git operation |
This is a better approach than simply asking whether "Git is compatible."
What Developers Should Do Now
If you are using a normal, recently updated development machine, start with:
git --version
Then:
git remote -v
If the remote uses HTTPS, test:
git ls-remote https://github.com/example/example.git
If that works, your current Git-to-GitHub HTTPS path is functioning.
For organizations, go one step further and audit:
Developer machines
CI/CD runners
Build servers
Deployment servers
Containers
Automation scripts
Corporate proxies
Internal developer tools
The machines most likely to be missed are usually old servers and self-hosted automation environments.
Summary
GitHub's SHA-1 HTTPS change is a cryptographic security change, not a sudden change to how Git repositories identify every commit.
The important distinction is:
Git Object Hashing
|
v
SHA-1 / SHA-256
versus:
HTTPS/TLS Connection
|
v
Modern cryptographic algorithms
GitHub disabled SHA-1 in HTTPS/TLS on September 15, 2026 for GitHub.com and partner CDNs. GitHub Enterprise Server is not affected by this specific change.
For most developers, keeping Git, the operating system, and TLS components up to date should be enough.
The bigger job for development teams is checking older CI/CD runners, self-hosted machines, containers, and corporate network infrastructure.
If an HTTPS Git operation starts failing, don't immediately disable SSL verification or switch protocols. First check the Git version, HTTPS backend, TLS libraries, certificates, proxy configuration, and the complete network path.
That approach fixes the actual compatibility problem without weakening the security of the Git connection.
Join the conversation! Your thoughts help the community grow.