Beyond the News
Sign in
Web DevelopmentDeveloper Tools Active dossier

GitHub has switched off SHA-1 HTTPS support — old Git and API clients can now fail

GitHub completed its September 15 SHA-1 HTTPS retirement across github.com and partner CDNs. The change mainly targets legacy TLS stacks rather than Git repository object hashes, and GitHub Enterprise Server is outside this cutoff.

Reviewed and published by Lars Jansen Updated 4 min read
Comment
First published

Key details

  1. GitHub disabled SHA-1 in HTTPS on September 15, 2026 for github.com and partner CDNs.
  2. GitHub Enterprise Cloud and Enterprise Cloud with Data Residency are included.
  3. GitHub Enterprise Server is not affected by this particular cutoff.
  4. Affected surfaces can include browsers, Git clients using HTTPS and software calling the GitHub API.
  5. GitHub recommends current browsers, Git versions, operating systems and TLS libraries/backends.
  6. A July 14 brownout temporarily disabled SHA-1 for 18 hours as a compatibility warning.

What builders should take away

  1. If an old build machine or appliance suddenly cannot clone, push or call GitHub over HTTPS, inspect its TLS library and OS before blaming repository credentials.
  2. Refresh long-lived CI images and pinned enterprise environments that carry old Git/TLS stacks.
  3. Test unusual or embedded clients against GitHub rather than assuming a modern Git version elsewhere in the fleet proves compatibility.
  4. Do not treat this cutoff as a Git object-hash migration; scope remediation to HTTPS/TLS compatibility unless another issue is present.

What changed

GitHub says it followed its announced schedule and disabled SHA-1 in HTTPS for github.com and partner CDNs on September 15, 2026. The scope includes GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency, while GitHub Enterprise Server is unaffected. GitHub had already run an 18-hour brownout on July 14 to expose incompatible clients before final enforcement.

Why it matters

For most current developer machines nothing changes, but old operating systems, TLS libraries, embedded automation images and pinned enterprise environments can now fail when cloning or pushing over HTTPS, calling GitHub APIs or loading GitHub in a legacy browser. The operational point is easy to misread: this is an HTTPS/TLS compatibility retirement, not an announcement that Git's SHA-1 object format has suddenly stopped working.

The announced compatibility deadline has now become enforcement

GitHub first published the migration schedule in April, then ran a July brownout before the final September 15 cutoff. Its new changelog entry confirms SHA-1 HTTPS support is now disabled on GitHub.com and the relevant cloud/CDN surfaces.

The likely failures live below Git itself

Git HTTPS behavior depends on the TLS stack available to the client. On Linux that may involve OpenSSL or another backend; automation can also inherit old libraries from long-lived container or VM images. A Git binary that appears functional locally can therefore still fail against GitHub when the underlying HTTPS stack cannot negotiate supported modern algorithms.

This is not the same as Git repository SHA-1 object IDs

The retirement concerns SHA-1 in HTTPS/TLS. Builders should not confuse it with Git's separate history of SHA-1 object identifiers and repository-format migration. The immediate symptom here is connectivity failure to GitHub over HTTPS, not repository objects suddenly becoming unreadable.

What to watch next

  • Reports of specific legacy CI images, operating systems or Git TLS backends failing after final enforcement.
  • Whether GitHub publishes additional compatibility guidance based on post-cutoff support cases.
  • Separate Git repository object-format or SHA-256 migration milestones, which are technically distinct from this HTTPS change.

Still unclear

  • GitHub does not enumerate every legacy OS, TLS backend or client version that will fail, because compatibility depends on the cryptographic stack and configuration.
  • Enterprise proxies or TLS interception layers can add another compatibility boundary even when the endpoint client itself is current.

Sources

Direct reading behind this dossier.

2 sources
SHA-1 in HTTPS on GitHub sunset
GitHub primary changelog

Confirms final enforcement on github.com and partner CDNs and states GHES is unaffected.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment
Continue reading
Cloud & Infrastructure

App Engine is raising its minimum TLS version to 1.2

App Engine’s TLS migration is now an active rollout. Applications that still depend on TLS 1.1 or earlier can opt out only through August, while September enforcement may block old clients differently on appspot.com and custom domains.

Artificial Intelligence

GitHub AI Scan no longer needs CodeQL default setup

The scanner itself is not the new part. The September 16 change removes the CodeQL-default-setup gate that GitHub’s July rollout originally required, making AI-assisted vulnerability detection easier to add to repositories with different code-scanning configurations.