Sunsetting SHA-1 on GitHub HTTPS: Certificate and Legacy Client Migration Blueprint

GitHub announced HTTPS SHA-1 deprecation, which sounds obvious in 2026, but many enterprises still carry hidden SHA-1 assumptions in internal TLS interception stacks, old runners, and long-lived developer images.

Reference: https://github.blog/changelog/2026-04-20-sunsetting-sha-1-in-https-on-github.

Where breakage usually appears

The biggest failures rarely come from modern laptops. They come from forgotten systems: self-hosted CI workers, old package mirrors, custom Git clients embedded in build tools, and corporate proxy chains terminating TLS with weak policies.

Do not run a blanket migration. First map every path where git clone and git fetch touch GitHub over HTTPS.

Migration sequence

1. Build an inventory of clients and TLS libraries.
2. Group by risk: production CI, developer endpoints, non-critical automation.
3. Patch and validate high-risk groups first.
4. Enforce policy with expirations, not permanent exceptions.

Treat this as a reliability program, not a one-time security ticket.

Hard controls to implement

• Block unsupported TLS/cert stacks at ingress with clear error messages.
• Publish one standard base image for CI runners with validated crypto libraries.
• Add pipeline checks that fail if old Git/TLS fingerprints are detected.
• Add emergency fallback playbooks with strict TTL.

Communication and support model

Create a migration window with daily reporting. Teams need one status page: affected repos, failing runners, owner, and ETA. If support channels are fragmented, migration stalls.

Closing

SHA-1 sunset is less about cryptography awareness and more about operational hygiene. Teams that use this moment to clean legacy runtime assumptions will improve both supply-chain security and delivery consistency.