GitHub schedules SHA-1 TLS shutdown for September 15

GitHub announced on April 20 that its hosted HTTPS services would stop accepting TLS connections that rely on SHA-1 signature algorithms. The changelog set a brownout for July 14 and full disablement for September 15, 2026. The scope includes github.com, GitHub Enterprise Cloud, and GitHub content-delivery endpoints, while GitHub Enterprise Server is excluded.

Old clients face a clear cutoff

This change concerns the cryptographic capabilities used to establish HTTPS, not the hash algorithm of Git commit object IDs. Modern operating systems, browsers, Git clients, and TLS libraries should negotiate stronger signatures. Risk concentrates in old appliances, embedded build images, outdated language runtimes, and corporate TLS interception systems that still present or require SHA-1 signatures.

GitHub provided github.dev as a test destination configured without SHA-1 support. A successful browser visit is useful but incomplete: automation often runs with a different certificate store and network path than a developer laptop.

Test from the systems that connect

Inventory outbound GitHub traffic from CI runners, release servers, dependency proxies, scanners, and developer gateways. Test each runtime and proxy path against the designated endpoint, then inspect TLS failures rather than automatically bypassing certificate checks. Updating Git alone may not help when it delegates TLS to an older system library.

For containers, rebuild from maintained base images and confirm the effective OpenSSL, Java, or platform TLS version inside the job. For proxies, verify both client-facing and upstream handshakes. Keep the July brownout in incident timelines so a temporary failure is recognized as a compatibility signal. Teams that cannot upgrade before September need an explicit replacement plan; weakening certificate verification would exchange a predictable migration for a larger security problem.