Live
AWS Capacity Constraints Through 2027 Require New EC2 Planning StrategiesBedrock’s unified API pushes AI teams toward multi‑model pipelinesUsing eBPF Runtime Controls to Bridge the Patch GapLLM cost efficiency shift: GPT‑6.1 Terra trims token spend versus Claude Opus 5.5AI‑driven CMS recommendation bias: tracking Webflow’s MCP integration visibilityAI Security Agent PageBreak Detects 500+ XSS Flaws – Implications for DevSecOps PipelinesOpen‑Weight AI Models and Ansible‑Driven HPC Management: New Paths for Telco and Enterprise OpsBrowser Run switches to Chrome 152 – what engineers need to knowAWS Capacity Constraints Through 2027 Require New EC2 Planning StrategiesBedrock’s unified API pushes AI teams toward multi‑model pipelinesUsing eBPF Runtime Controls to Bridge the Patch GapLLM cost efficiency shift: GPT‑6.1 Terra trims token spend versus Claude Opus 5.5AI‑driven CMS recommendation bias: tracking Webflow’s MCP integration visibilityAI Security Agent PageBreak Detects 500+ XSS Flaws – Implications for DevSecOps PipelinesOpen‑Weight AI Models and Ansible‑Driven HPC Management: New Paths for Telco and Enterprise OpsBrowser Run switches to Chrome 152 – what engineers need to know
GitHub

GitHub HTTPS no longer supports SHA-1: impact on CI/CD and tooling

Ninja·September 17, 2026·1 min read·via GitHub Changelog
AI SummaryPowered by AI

GitHub has turned off SHA‑1 support for HTTPS on its public service and partner CDNs as of 15 Sept 2026. Practitioners must ensure their tools and proxies use stronger hash algorithms or risk broken Git operations.

GitHub has disabled SHA-1 support for HTTPS on github.com and its partner CDNs, covering GitHub Enterprise Cloud and Enterprise Cloud with Data Residency, effective 15 September 2026. The change does not affect GitHub Enterprise Server.

What Changed

All TLS connections to the public GitHub service and the associated CDN endpoints now require certificates that use hash algorithms stronger than SHA-1. Any client that attempts a handshake using a SHA-1‑signed certificate will be rejected.

Why It Matters to Practitioners

AI engineers, cloud/platform engineers, DevOps/SRE teams, and security engineers all rely on automated Git operations over HTTPS. If the tooling, CI runners, or internal proxies still depend on SHA-1‑based certificates, those operations will fail, potentially breaking model versioning pipelines, deployment automation, or audit logging.

Operational and Security Implications

  • Verify that Git client libraries, CI agents, and any custom TLS termination points support SHA‑256 or stronger hashes.
  • Update any self‑managed proxy or CDN configurations that forward traffic to GitHub to use up‑to‑date certificates.
  • Monitor logs for TLS handshake failures that reference SHA‑1, as they indicate lingering dependencies.
  • Security posture improves by removing a known weak hash algorithm from the attack surface.

Related CloudNinjas coverage: hands-on guides.

What This Means For Practitioners

Audit your toolchain for SHA‑1 usage and upgrade libraries or configurations where needed. Test push/pull operations in a staging environment before the cut‑over date to catch incompatibilities. For GitHub Enterprise Server users, plan a similar transition in future releases, even though the current change does not apply to on‑prem installations.

Tags: #github#tls#sha-1#security#ci-cd
Originally published atGitHub Changelog
Related Articles
AWS

AWS Capacity Constraints Through 2027 Require New EC2 Planning Strategies

3 min read
Redhat

Open‑Weight AI Models and Ansible‑Driven HPC Management: New Paths for Telco and Enterprise Ops

3 min read
Azure

Hardware Audit Logging for Azure Cloud HSM: Practical Implications for Engineers

3 min read