Contents
On September 15, GitHub finished a deprecation it had been broadcasting since April: SHA-1 is no longer accepted in the HTTPS/TLS layer for github.com and its partner CDNs.[1] If a client can’t negotiate a TLS handshake without SHA-1-based signatures, it now gets a connection failure instead of a page, an API response, or a repository. GitHub Enterprise Server is untouched; this only hits github.com, GitHub Enterprise Cloud, and GitHub Enterprise Cloud with Data Residency.[1]
The change itself is small and, for anyone running current software, invisible. The interesting part is what happens to the small number of systems that do get hit, and why the failure they produce is going to send a lot of people down the wrong debugging path.
What actually got disabled
TLS 1.2 negotiates a signature algorithm for the handshake itself, via the signature_algorithms extension: the server and client agree on how the key exchange and certificate verification messages get signed, and historically that list included SHA-1-based options like rsa_pkcs1_sha1. GitHub’s change removes SHA-1 from that negotiation. A client that only knows how to offer SHA-1 signature schemes, or a TLS library too old to have SHA-256 options in its default list, can’t complete a handshake with github.com anymore. The failure happens before HTTP, before authentication, before git protocol negotiation. It’s a TLS-layer rejection.
GitHub’s own guidance for who’s affected is blunt: browsers, “any software that uses the GitHub API,” and git clients that push and pull over HTTPS.[2] Their fix is equally blunt: use a modern browser, a modern HTTP library, and “a recent version of git with an up-to-date operating system and components."[2] There’s no algorithm negotiation you can configure your way around here. The client either has SHA-256-capable TLS or it doesn’t.
The confusion this is going to cause
Here’s the part worth writing down, because it’s not in GitHub’s changelog and it’s exactly the kind of thing that costs someone an afternoon: git has its own, completely separate, unrelated relationship with SHA-1. Git’s object model, the hashes it uses for blobs, trees, and commits, still defaults to SHA-1, and git has been in a slow, opt-in transition toward SHA-256 object hashing for years, with its own known collision concerns (the SHAttered and shambles attacks against SHA-1) driving that migration.
Those are two different SHA-1s, in two different layers, with two different fates. GitHub’s September 15 change touches the TLS transport underneath HTTPS. It has zero effect on how git hashes objects inside a repository, and it doesn’t require or imply anything about a repo’s object format. But if you’re an engineer who’s been half-following git’s SHA-256 migration story and your CI suddenly starts failing HTTPS clones with a cryptic TLS error right around a “SHA-1” deprecation announcement, the obvious wrong conclusion is “something about our repo’s hash format broke.” It didn’t. The object hashes are irrelevant to this failure. The bug is entirely in the TLS client stack trying to reach github.com, not in anything git-specific at all.
That distinction matters operationally. If you go looking for a git-hashing fix, you’ll find nothing to change, because there’s nothing to change in git’s object format. The actual fix lives one layer down, in whatever library git delegates HTTPS to: OpenSSL on most Linux distributions, Secure Transport on macOS, Schannel on Windows.
Who this actually breaks
Given how long ago TLS 1.2 added SHA-256 signature support (the RFC is from 2008, and mainstream TLS libraries added it within a few years), almost nothing running current software notices this change at all. GitHub even gives you a way to test a browser directly: load https://github.dev, where SHA-1 has already been off, and if it loads cleanly your TLS stack is fine.[2]
The failures land on things nobody has touched recently: self-hosted CI runners frozen on an old OS snapshot, build agents on legacy Windows Server images that predate the SHA-2 TLS updates Microsoft shipped for Windows 7 and Server 2008 R2, embedded or appliance-style Linux images built once and never patched, and Docker base images pinned to an ancient tag for reproducibility reasons that nobody remembers anymore. None of these are exotic. They’re exactly the class of infrastructure that sits quietly doing its job for years specifically because nobody wants to touch it, until an external dependency changes underneath it.
That’s also why this is worth a post and not just a changelog entry to skim. The failure mode reads as intermittent or environment-specific: a repo clones fine from your laptop, fails from the old build box, and the error message is a generic TLS handshake failure that doesn’t name SHA-1 or GitHub’s policy at all. openssl s_client -connect github.com:443 on the affected host will show you the actual negotiated (or failed) handshake if you want to confirm it’s TLS and not DNS, auth, or a firewall rule. If the handshake dies before a certificate even gets exchanged, and the box is old enough that you’re not sure the last time its OS packages were updated, this is very likely it.
The decision this changes
GitHub telegraphed this for five months, ran a scoped brownout in July specifically to surface who’d be affected before the real cutover, and still the day-of failures for genuinely stale infrastructure were probably a surprise to whoever owns that infrastructure, because “read the changelog” isn’t how most people find out their build server is on borrowed time. The practical move isn’t reacting to this specific sunset after the fact. It’s treating “what’s our oldest unpatched thing that still talks TLS to an external service” as a standing audit, not a one-time cleanup, because this isn’t the first cipher or protocol sunset a major platform has run and it won’t be the last. TLS 1.0 and 1.1 went through the same cycle a few years back. The next one might be a minimum RSA key size or a certificate chain requirement instead of a signature algorithm, and it will produce the exact same symptom: a handshake failure on the one machine nobody has logged into in two years, with an error message that tells you nothing about which layer actually broke.
Sources
[1] https://github.blog/changelog/2026-09-15-sha-1-in-https-on-github-sunset/: GitHub Changelog, “SHA-1 in HTTPS on GitHub sunset,” September 15, 2026
[2] https://github.blog/changelog/2026-04-20-sunsetting-sha-1-in-https-on-github/: GitHub Changelog, “Sunsetting SHA-1 in HTTPS on GitHub,” April 20, 2026 (deprecation schedule and client guidance)