GitHub has completed its SHA-1 in HTTPS sunset. On September 15, 2026, GitHub disabled SHA-1 in HTTPS for github.com and partner CDNs, including GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency. GitHub Enterprise Server is unaffected. See GitHub’s sunset announcement for the official scope.
Most current browsers, operating systems, Git clients, and API libraries should continue working. The risk is concentrated in old machines, pinned build images, TLS-intercepting proxies, and tools that have not received updates in years. If a GitHub integration started failing after the change, use this checklist to find the stale component.
What changed
The change is about the cryptographic algorithms accepted by HTTPS/TLS connections to GitHub and its CDNs. GitHub’s preparation guidance explicitly calls out three groups: browsers loading GitHub, software using the GitHub API, and Git clients that push or pull over HTTPS. The original schedule included a July brownout and complete removal on September 15. GitHub’s preparation guidance also recommends current browsers, libraries, Git, operating systems, and TLS components.
This is not a request to rewrite repository history or replace every SHA-1 Git object. It is an HTTPS compatibility change. Treat it like a transport and client-support upgrade: identify the component negotiating TLS, update it, and then test the real path used by your developers and CI runners.
Start with the three paths that matter
Do not test only in your laptop browser. A repository can work in a modern browser while an old runner, API worker, or proxy still fails. Check each path separately.
# Browser/API edge: inspect the HTTPS response
curl -I https://github.com
# Git over HTTPS: exercise the same protocol used by fetch and clone
git --version
git ls-remote https://github.com/OWNER/REPOSITORY.git
# TLS edge: inspect the certificate and negotiated endpoint
openssl s_client -connect github.com:443 -servername github.com </dev/null 2>/dev/null | \
openssl x509 -noout -issuer -subject -dates -fingerprint -sha256These commands do not prove that every API request or CDN download will succeed, but they quickly separate a healthy direct connection from a client or network-path problem. Use a repository the runner can read. Do not paste tokens into a command or disable certificate verification to make a failed test pass.
Where failures usually hide
Old base images. A workflow may use a current action but still run inside an old container with an old Git, OpenSSL, curl, or CA bundle. Rebuild the image from a supported distribution and inspect the versions actually installed at runtime.
Pinned runners. Self-hosted runners often outlive the software image they started with. Check the operating system, Git, TLS library, and certificate bundle on every runner group, not only the machine used to author workflows.
TLS inspection. Corporate proxies can terminate HTTPS and create a second TLS connection to GitHub. A browser may trust the company certificate while a Git process or language runtime does not. Compare a direct test with the proxied path and install the organization’s CA through the supported operating-system or runtime mechanism.
API dependencies. Older HTTP clients can fail before authentication is even attempted. Update the framework or library, then run a harmless authenticated read in a staging environment. A 401 or 403 is an application credential issue; a TLS handshake or certificate error is a transport issue.
A safe upgrade sequence
1. Inventory every integration that reaches github.com, api.github.com, or a GitHub-backed CDN. Include laptops, CI, release tooling, bots, webhooks that make follow-up API calls, and internal mirrors.
2. Record versions from the failing environment, not from a developer workstation: Git, curl or the HTTP library, OpenSSL or another TLS backend, operating system, container image, and CA bundle.
3. Update the smallest supported layer first. Prefer a maintained runner image or base image before adding application-level workarounds. Keep certificate verification enabled throughout the test.
4. Re-run the exact operation that failed: clone, fetch, push, API call, package download, or release upload. A successful curl request alone is not enough when the production path uses a proxy or a different runtime.
5. Pin the fixed image or minimum runtime versions in your build configuration, and add the check to image refreshes. The goal is to prevent a quietly aging runner from becoming the next outage.
What GitHub Enterprise Server users should do
GitHub says Enterprise Server is unaffected by this specific sunset. That does not mean an Enterprise Server installation has no TLS maintenance work. Its administrators still control the server version, certificates, proxies, and supported clients. Keep the GitHub.com checklist separate from your appliance upgrade policy, and follow the release documentation for the Enterprise Server version you run.
The short version
If GitHub access is healthy, no action may be required. If something broke, find the oldest TLS-speaking component in the actual path: browser, API library, Git, runner image, proxy, or CA bundle. Update it, test the real operation, and keep verification enabled. That is the durable fix for the SHA-1 HTTPS sunset and for the next cryptographic deprecation too.