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:

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.