What changed on 15 September
GitHub has completed the removal of SHA-1 from HTTPS connections to github.com and its partner CDNs. The change covers GitHub Enterprise Cloud, including Data Residency, and follows a July brownout that temporarily disabled SHA-1 to expose incompatible clients before the permanent cutover.
GitHub Enterprise Server is unaffected because this change applies to GitHub-hosted HTTPS endpoints rather than customer-managed server deployments.
Who can actually break
The affected surface is broader than the website. GitHub’s original deprecation notice says old browsers, software using the GitHub API and Git clients that push or pull over HTTPS can fail if their TLS stack cannot negotiate algorithms newer than SHA-1.
For Git, compatibility depends on the HTTPS backend supplied by the operating system and libraries such as OpenSSL. A recent Git binary can therefore still sit on top of an obsolete TLS environment, while a modern browser on the same machine may work normally.
What maintainers should check
GitHub’s guidance is straightforward: keep browsers, API frameworks, Git clients, operating systems and TLS libraries current. The company previously suggested github.dev as a compatibility test because SHA-1 had already been disabled there before the wider rollout.
Teams with old build images, long-lived self-hosted runners, embedded tooling or legacy corporate proxies have the strongest reason to test. A failure after the cutover is a transport compatibility problem rather than a repository or authentication change.
Why it matters
The removal closes another legacy cryptographic dependency from GitHub’s public HTTPS surface. Most current systems should notice nothing, but infrastructure that quietly depended on SHA-1 now has a hard failure rather than a warning period. That makes the change operationally important for old automation even though the security migration was announced months in advance.