GitHub disabled SHA-1 in HTTPS connections to github.com and its partner CDNs on September 15, 2026. The change covers GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency. GitHub Enterprise Server, the self-hosted product, is not affected by this change, according to GitHub's changelog post.
SHA-1 has been considered cryptographically weak for years, and browser vendors and certificate authorities have been phasing it out of TLS certificate chains for a long time. GitHub's move removes it from the HTTPS negotiation path entirely rather than just discouraging it. That matters because clients, build agents, and internal tools that still negotiate TLS using older cipher suites or hash algorithms will not get a warning. They will get a connection failure, and the error message will not say anything about SHA-1 by name.
GitHub's changelog entry confirms the disablement happened and specifies which products are in scope. It does not say what triggered the timing, whether any customers were notified in advance, or what fallback behavior clients should expect when a handshake fails. It also does not list specific TLS libraries, operating system versions, or git client versions known to be incompatible. Anything beyond the four confirmed facts, the date, the scope, the Enterprise Server exclusion, and the CDN involvement, is not part of GitHub's statement and should be treated as unconfirmed until GitHub or another primary source says otherwise.
For on-call engineers, the operational risk sits in old infrastructure nobody has touched recently. Build servers running outdated OpenSSL, legacy CI runners, hardcoded webhook integrations, and old Docker base images are the likely failure points. Check TLS handshake logs for errors tied to git clone or API calls to github.com, and check what TLS library version your build agents are running. If a pipeline that pulls from GitHub starts failing with generic SSL errors and no clear certificate problem, SHA-1 removal is now a plausible cause, not just a theoretical one. GitHub Enterprise Server customers can rule this out immediately, since that product line is untouched.
The fix is usually not complicated once the cause is identified: update the TLS stack or the client. Diagnosis is the hard part, because SHA-1 negotiation failures often surface as opaque connection resets rather than descriptive errors naming the missing algorithm. Teams that haven't audited which systems still touch github.com directly, rather than through a mirror or proxy, won't know they're exposed until something breaks at 2 a.m. Platform teams should inventory every service with a hardcoded dependency on github.com's HTTPS endpoint before the next scheduled build runs, not after it fails.
GitHub has not disclosed a rollback plan or an extended compatibility window for the September 15 change. Nothing in the changelog suggests SHA-1 support will return. For teams still running infrastructure old enough to depend on it, the fix is replacing the TLS stack, not waiting for GitHub to reverse course.