GitHub is removing SHA-1 from HTTPS: lessons from the July brownout

On 14 July, GitHub disabled SHA-1 support in HTTPS for 18 hours. The brownout ran from 00:00 to 18:00 UTC and was designed to expose old browsers, libraries, Git clients and integrations before the permanent change. GitHub plans to disable SHA-1 in HTTPS/TLS for GitHub and partner CDNs on 15 September 2026.

This is not only a GitHub-administrator issue. If a pipeline downloads dependencies, automation publishes releases, a scanner queries the API or a legacy server performs git pull over HTTPS, the incompatibility may stop a business process on the day of final removal.

An important distinction

This change concerns SHA-1 used in the HTTPS/TLS connection, where algorithms establish a trusted channel to GitHub. It does not automatically alter Git object identifiers or commit-signing policy.

That distinction matters when communicating the work. An instruction to “find SHA-1 in repositories” may produce thousands of normal 40-character commit identifiers while missing every legacy TLS client that will actually fail.

GitHub’s deprecation schedule

• 14 July brownout: SHA-1 disabled on github.com for 18 hours; CDNs were not part of this test;
• 15 September: complete SHA-1 removal from HTTPS/TLS for GitHub and partner CDNs;
• scope: browsers, GitHub API clients and Git over HTTPS;
• GitHub Enterprise Server: not affected according to the announcement.

GitHub offers a simple browser check at https://github.dev, where SHA-1 is already disabled. A successful connection proves that browser works, but it does not test the Java runtime inside Jenkins, a Git binary in a container image or the HTTP library embedded in a production scanner.

Where legacy clients hide

The obvious developer laptop is often the least concerning asset because modern operating systems and browsers support newer algorithms. Risk tends to sit in components that are updated infrequently:

• self-hosted runners and old CI/CD images;
• network appliances pulling configuration from a repository;
• servers with unsupported operating systems or Java runtimes;
• IDE plugins, release tooling and scanners;
• internal TLS proxies and HTTPS inspection appliances;
• scripts using old curl, OpenSSL or HTTP libraries;
• vendor integrations that connect to the GitHub API.

The brownout itself is valuable telemetry. Review pipeline failures, synthetic checks, user reports and proxy logs from 00:00–18:00 UTC on 14 July. A TLS negotiation error in that window is a stronger lead than a generic software-age report.

Testing before 15 September

Step 1: document critical flows

Inventory processes, not just user accounts: source checkout, release download, API calls, artifact publishing, webhooks, repository scanning and disaster-recovery rebuilds.

Step 2: use representative environments

A laptop test does not prove a production runner is compatible. Execute the check from the same image, operating system, proxy and library used by the target process.

Step 3: observe the complete path

Where traffic passes through a proxy or TLS inspection, validate both negotiations: client to proxy and proxy to GitHub. A modern intermediary does not fix a legacy client on its internal side.

Step 4: update and repeat

Remediation may require an operating-system, OpenSSL, Java, Git client or proxy-firmware update. Keep the successful post-change result as evidence.

Do not wait for migration day

On 15 September, incompatibility becomes an availability incident: builds may fail to fetch code, automated publishing may stop and a disaster-recovery process could discover the issue at the worst possible time. The most expensive case is an integration that runs monthly—it did not execute during the brownout and remained invisible.

The process owner should accept evidence that a representative client connected without SHA-1. “The library appears recent” is not a sufficient control test.

The wider cryptographic lesson

Algorithm migrations do not end at the server configuration. Dependencies, intermediaries and long-lived images accumulate cryptographic technical debt. An IT security audit should maintain an inventory of TLS versions, certificates and libraries for critical integrations before an external provider imposes a deadline.

Primary source: GitHub Changelog — Sunsetting SHA-1 in HTTPS on GitHub.