GitHub turns off SHA-1 in HTTPS on github.com and partner CDNs

GitHub disabled SHA-1 in HTTPS for github.com and its partner content delivery networks on 15 September 2026, on the schedule the company announced in April. The change follows a brownout GitHub ran from 00:00 to 18:00 UTC on 14 July 2026, when it temporarily turned SHA-1 off to give operators a preview of what would break. GitHub Enterprise Server is not affected.

What "SHA-1 in HTTPS" means, in plain terms

TLS is the security layer on every https:// connection. During the handshake, the two sides agree on how the server will sign the messages that prove it is who it says it is. SHA-1 is one of the signature hash algorithms that has been in that agreement for over twenty years. It has known collision attacks since 2017, so browsers, CAs and standards bodies have been walking it out of TLS for years.

What GitHub turned off is not SHA-1 in every part of the site. Git commit hashes still use SHA-1, and this change does not touch them. What went away is SHA-1 as an option the server will accept in the TLS handshake with a client. A modern browser, curl, git or SDK offers a range of signature algorithms and will pick a stronger one automatically. Something old enough to only advertise SHA-1 for the TLS signature will fail to complete the handshake, and the client sees a connection error rather than a helpful message.

Who actually breaks

GitHub names three affected client categories in the April announcement: browsers, "any software that uses the GitHub API", and git clients that push and pull over HTTPS. On the API and library side, that means old versions of things like libcurl, openssl, python-requests and language-specific TLS stacks. On the git side, it is git binaries linked against those same old stacks. If the underlying operating system is old enough that the whole crypto library predates the SHA-1 walk-out, the git binary shipped on it will fall in the same bucket.

GitHub's suggested test is to open https://github.dev in whatever client you want to check. That subdomain has had SHA-1 turned off for months, so a client that loads it works against the new github.com and a client that cannot is the one you need to update.

What to check on Monday

CI jobs that mount an old base image, developer laptops that still run an operating system past its patch window, deploy scripts that hard-pin a curl version, and any long-running server that has never been rebuilt against a current libcurl or openssl are the places to look first. git version and curl --version on those hosts, and comparing them against a recent release, is the fastest way to sort the list.

Source

SHA-1 in HTTPS on GitHub sunset, The GitHub Blog, 15 September 2026. Original announcement: Sunsetting SHA-1 in HTTPS on GitHub, 20 April 2026.