GitHub Disabled SHA-1 in HTTPS: Fixing Git Clone/Push SSL Errors After Sept 15, 2026

On September 15, 2026, GitHub completely disabled SHA-1 in HTTPS/TLS connections to github.com, GitHub Enterprise Cloud, and its partner CDNs. If a git clone, git push, or a script calling the GitHub API over HTTPS suddenly started throwing SSL or certificate errors around that date — on a machine, container image, or CI runner that hasn't been touched in a while — this is almost certainly why. Nothing changed in your repo or your credentials; the TLS handshake your client relies on stopped being accepted by the server.

Why this is breaking things that "worked fine yesterday"

GitHub announced this sunset back on April 20, 2026, ran a controlled brownout on July 14, 2026 (00:00–18:00 UTC, SHA-1 disabled for github.com but not yet the CDNs), and then fully and permanently disabled SHA-1 in HTTPS/TLS on September 15, 2026. GitHub Enterprise Server (the self-hosted product) is unaffected — this only hits github.com and GitHub Enterprise Cloud, including the Data Residency edition.

The practical impact is that GitHub's TLS termination no longer negotiates connections that depend on SHA-1 anywhere in the handshake or certificate chain. That includes:

• Browsers viewing github.com or raw/gist/CDN-hosted content
• Any software calling the GitHub REST or GraphQL API over HTTPS — custom scripts, older SDKs, internal tooling
• Git clients performing push/pull/clone/fetch over https:// remotes — this is the one that catches CI pipelines and long-lived servers off guard, because a build box or base image can go untouched for a year and still "just work" for HTTPS git operations right up until the exact day the protocol underneath it stops being accepted

The common thread across all three: nothing in your repo, your PAT, or your SSH key changed. The client-side TLS stack — the version of OpenSSL, LibreSSL, or Schannel that git and curl link against — is what has to support signature algorithms newer than SHA-1, and on older, rarely-updated systems it often doesn't by default.

Step 1: Confirm this is actually the cause

Before touching anything, rule out other causes (expired PAT, revoked SSH key, a firewall/proxy change) by testing against GitHub's own known-good target for this exact issue:

1curl -v https://github.dev 2>&1 | grep -E "SSL|TLS|certificate"

If this fails with a TLS-layer error (not a 4xx/5xx HTTP status), your client's TLS stack is the problem, not your credentials. A clean connection to github.dev confirms your system already supports modern TLS and the failure lies elsewhere (check credentials/network next).

Also check the actual versions in play — these are the numbers that matter, not just "I have git installed":

1git --version
2curl --version | head -1
3openssl version

Step 2: Fix it on Linux (the most common CI failure point)

Most Linux SSL failures against github.com after this sunset trace back to one of two things: an ancient system OpenSSL, or a stale ca-certificates package that hasn't picked up newer intermediate certificate handling. Fix both:

1# Debian/Ubuntu
2sudo apt-get update
3sudo apt-get install --only-upgrade -y git curl ca-certificates openssl libcurl4
4
5# RHEL/CentOS/Alma/Rocky
6sudo dnf update -y git curl ca-certificates openssl

If you're still on a Linux distro whose vendor-shipped OpenSSL predates TLS 1.2 signature algorithm extensions entirely (RHEL/CentOS 6, Ubuntu 14.04, and similar EOL releases), there is no package-manager fix — those distros are past vendor support and their OpenSSL builds cannot be patched forward to support this without replacing the toolchain wholesale. The realistic fix there is upgrading the OS, not chasing individual packages.

For CI runners specifically, the same logic applies to your base image, not just the host. A FROM ubuntu:18.04 or a self-hosted runner container that hasn't been rebuilt in a year is exactly the profile that breaks on this exact date:

1# Before: silently fine until Sept 15, 2026
2FROM ubuntu:18.04
3
4# After: current LTS with a maintained OpenSSL/ca-certificates chain
5FROM ubuntu:24.04
6RUN apt-get update && apt-get install -y git curl ca-certificates

Step 3: Fix it on macOS

macOS ships its own TLS stack via LibreSSL/Secure Transport, and the system git binary (from Xcode Command Line Tools) lags behind upstream git releases. Update both the CLI tools and get git from a source that isn't tied to the OS release cycle:

1softwareupdate --install "Command Line Tools for Xcode"
2
3# Better: use Homebrew's git, which links against a current OpenSSL independent of the OS
4brew install git openssl@3
5brew link --force git

Older Intel Macs still running an OS release from several major versions back are the most likely to hit this, since Apple's own Secure Transport updates ship tied to OS updates that many of those machines no longer receive.

Step 4: Fix it on Windows

Git for Windows bundles its own curl and OpenSSL, so the fix is simply keeping Git for Windows current rather than patching Windows itself:

1git update-git-for-windows

If you installed Git for Windows more than a year or two ago and never re-ran the installer, this single command resolves the overwhelming majority of Windows-side failures tied to this sunset.

Step 5: The fallback that works everywhere — switch to SSH

If you're mid-incident and need CI green again before you can properly patch every affected image, switching the remote from HTTPS to SSH sidesteps this entire class of problem, since SSH authentication doesn't depend on the same TLS certificate chain at all:

1git remote set-url origin git@github.com:ORG/REPO.git

This is a legitimate stopgap, not just a workaround — many teams standardize on SSH remotes for CI specifically because it removes a whole category of TLS/certificate churn from the failure surface. Treat it as a real fix, not just a band-aid, if you're setting up new automation.

Best practices

• Rebuild CI base images on a schedule, not only when something breaks. A base image nobody has rebuilt in a year is the exact profile that fails silently until a date like this one arrives.
• Pin ca-certificates updates into your image build, not just the OS version. The certificate trust store and the TLS library version are two separate things that both need to stay current.
• Prefer SSH remotes for long-lived automation and self-hosted runners where key management is already solved — it removes an entire class of TLS-sunset risk.
• Track GitHub's own changelog for security/TLS-related sunset announcements — this one had a five-month notice period (April 20 to September 15) plus a dedicated brownout window specifically so teams could test ahead of the real cutover.

Common mistakes to avoid

• Assuming a sudden git SSL failure means a revoked credential. Check the TLS layer first (Step 1) before rotating tokens or SSH keys that were never the problem.
• Patching only the CI host and not the container image the job actually runs in. The host's OpenSSL is irrelevant if the job runs inside a Docker container with its own, older TLS stack.
• Upgrading git alone and stopping there. On Linux, git's HTTPS transport typically delegates to the system libcurl/OpenSSL — upgrading git without upgrading those does nothing for this specific failure.
• Ignoring API clients that aren't git at all. Custom scripts hitting api.github.com with an old requests/urllib3/libcurl dependency fail for the identical underlying reason and need the identical fix.

Troubleshooting

fatal: unable to access 'https://github.com/...': OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443 Classic symptom of a TLS handshake the server won't complete with an outdated client. Run Step 1's github.dev test to confirm, then apply the OS-specific fix above.

SSL certificate problem: unable to get local issuer certificate This is usually the CA trust store, not the TLS protocol version — update ca-certificates specifically (Step 2), even if you've already updated git and OpenSSL.

API calls succeed in a browser but fail from a script or cron job on the same machine. The browser uses the OS/browser vendor's own current TLS stack; your script is likely linking against an older, separately-installed OpenSSL or a language runtime's bundled TLS library. Check the specific runtime (Python, Node, Ruby) and its TLS dependency version, not just the system openssl binary.

Everything above looks current and it still fails. Confirm you're not going through a corporate proxy or TLS-inspecting firewall that is itself the outdated component — proxies terminate and re-establish TLS, so an old proxy can reintroduce this failure even with a fully patched client behind it.

FAQ

Does this affect GitHub Enterprise Server (self-hosted)? No. GitHub explicitly scoped this to github.com, GitHub Enterprise Cloud, and GitHub Enterprise Cloud with Data Residency. Self-hosted GitHub Enterprise Server instances are unaffected.

Does this affect SSH-based git operations? No — SSH authentication uses its own key exchange and doesn't depend on the TLS/HTTPS certificate chain this change targets. See Step 5 if you need an immediate workaround.

Is there a quick way to test if my system is affected before it breaks in production? Yes — curl -v https://github.dev (Step 1). GitHub deliberately disabled SHA-1 on that endpoint ahead of the main cutover specifically so people could test against it.

Why did GitHub do this instead of just leaving legacy support in place? SHA-1 has been considered cryptographically broken for collision resistance since 2017, and TLS certificate authorities have been phasing out SHA-1-signed certificate issuance industry-wide for years. GitHub maintaining SHA-1 support in TLS indefinitely would mean carrying a known-weak algorithm forward purely for backward compatibility with unmaintained clients.

I fixed the host but CI is still failing — why? Almost always a container image issue (Step 2's Docker example). The job's TLS stack lives inside the image, not on the runner host, whenever the job runs in a container.

Key takeaways

Further Reading

• Fix GitHub CLI NO_PUBKEY / EXPKEYSIG Errors After the September 2026 Key Rotation
• GitHub Actions Checkout v7: Fixing the Pwn Request Vulnerability Before July 16
• Rotating SSL or TLS Certificate in AWS RDS
• Official: SHA-1 in HTTPS on GitHub Sunset — GitHub Changelog
• Official: Sunsetting SHA-1 in HTTPS on GitHub — GitHub Changelog