On September 15, 2026, GitHub turned off SHA-1 for HTTPS and TLS on github.com and its CDNs. They had been warning about it since April. If your client can't do a TLS handshake without SHA-1, you now get a connection error.
I'll skip the history lesson on SHA-1. What I want to cover is why this took until 2026 to finally happen, and how to check your own setup first.
Why was SHA-1 still around
TLS handshake is the part where your client and github.com agree on how to verify the certificate. It has nothing to do with Git's own object hashing, which is a separate, much slower migration to SHA-256 that most repos haven't touched yet.
Old clients kept SHA-1 alive in that handshake. GitHub kept SHA-1 working in TLS for years so those clients wouldn't just stop connecting.
The rollout went like this:
- April 20, 2026: GitHub announced the change and warned about a brownout coming
- July 14, 2026: an 18-hour brownout, 00:00 to 18:00 UTC, where SHA-1 was turned off just long enough for people to notice
- September 15, 2026: SHA-1 turned off for good
A ten-second test you can run right now
GitHub had already disabled SHA-1 on github.dev early, so you can use it as a canary:
curl -v https://github.dev 2>&1 | grep -i "SSL connect\|handshake"
A clean connection means your TLS stack is fine. A handshake error means you were already going to break on the real deadline, and now you know early.
Run this everywhere that talks to GitHub, especially:
- CI runners, especially self-hosted ones with old base images
- servers that pull from GitHub unattended, deploy scripts, cron jobs
- internal tools hitting the GitHub API directly instead of through an SDK
What actually broke
Affected: github.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, and partner CDNs. Not affected: GitHub Enterprise Server, the self-hosted version. If your org runs GHES, none of this touches you.
Inside that affected scope, the failures came from outdated crypto libraries: old curl/libcurl, unpatched .NET Framework builds, stale Python ssl modules, Alpine Docker images whose openssl never got bumped. Browsers have supported modern certs for almost a decade, so regular users on anything recent never noticed.
Most of the people who got hit were running infrastructure they'd forgotten about.
If it broke for you
The fix is dull, in a good way:
- Update your TLS library,
openssl,libcurl, whatever your runtime uses - Rebuild the CI base image rather than patching it. If it's old enough to hit this, other things on it are stale too
- Run the
github.devcheck again to confirm
If you're stuck on something you truly can't update, some locked-down embedded box, there's no workaround here. GitHub isn't turning SHA-1 back on. The real fix is getting off that system.
The pattern worth remembering
Announce early. Run a scoped brownout as a fire drill. Give people a canary URL so they can check themselves. Then cut it for real. Most companies skip straight to a changelog post and hope nobody's affected. That's probably why so few people noticed this happening in real time. The brownout did its job.
Go run that curl command against github.dev on whatever CI box you haven't looked at lately. It's probably fine. But "probably" is exactly why you should check.
For more such articles, click
