GitHub 在 HTTPS 中停用 SHA-1
2026-09-16
此前，我们宣布将于 2026 年 9 月 15 日在 GitHub 的 HTTPS 中禁用 SHA-1。按照原定计划，GitHub 已在 github.com 及合作 CDN 上禁用 HTTPS 中的 SHA-1，包括 GitHub Enterprise Cloud 和带数据驻留的 GitHub Enterprise Cloud。GitHub Enterprise Server 不受影响。请查看此前公告以了解更多信息。
GitHub 已在 github.com 及合作 CDN 的 HTTPS 中停用 SHA-1，范围包括 GitHub Enterprise Cloud 和带数据驻留的 GitHub Enterprise Cloud；GitHub Enterprise Server 不受影响。
- GitHub 已在 github.com 及合作 CDN 的 HTTPS 中停用 SHA-1，范围包括 GitHub Enterprise Cloud 和带数据驻留的 GitHub Enterprise Cloud；GitHub Enterprise Server 不受影响。
- 原贴提到：Previously we announced we would be disabling SHA-1 in HTTPS for GitHub
- 来源：github.blog
这是什么信号
GitHub 按此前公布的排期，已在 github.com 及合作 CDN 的 HTTPS 中停用 SHA-1，范围包括 GitHub Enterprise Cloud 和 GitHub Enterprise Cloud with Data Residency。GitHub Enterprise Server 不受影响。
这不是一次实验性开关，而是平台侧对弱哈希算法的正式淘汰动作。SHA-1 早已不适合作为信任基础，继续在 TLS/HTTPS 链路中保留它，会让证书签名、流量校验和依赖链暴露在碰撞攻击与合规风险之下。
为什么重要
对使用 GitHub 的企业来说，影响不只在浏览器访问。CI/CD 流水线、旧版 Git 客户端、自建反向代理、TLS 终止设备、制品仓库、扫描器和监控探针，只要仍把 SHA-1 当作可接受的签名算法，就可能在连接 GitHub 或合作 CDN 时失败。
覆盖 GHEC with Data Residency 意味着跨国或受监管行业的数据驻留环境同样纳入变更。GHES 不受影响，则给自托管客户留下缓冲，但也提醒团队不要把所有 GitHub 部署形态混为一谈。
对谁有价值
平台工程、安全团队、DevOps 和负责 GitHub 企业治理的人最需要关注。它直接关系到供应链安全、TLS 配置基线、旧系统兼容性和审计口径。
对开发者个人而言，若日常使用新版客户端和操作系统，体感可能很弱；但维护老旧工具链、内网代理或自动化脚本的人，需要主动验证。
可以怎么行动
- 盘点所有访问 github.com 和 GitHub Enterprise Cloud 的 HTTPS 客户端、代理、网关与扫描工具，确认是否仍允许 SHA-1。
- 把 TLS 签名算法基线提升到 SHA-256 或更强，更新旧版运行时、Git 客户端、OpenSSL 和负载均衡配置。
- 在 CI/CD、Actions、Webhooks、API 调用和包管理链路中做连通性回归，重点覆盖合作 CDN 路径。
- 自托管 GitHub Enterprise Server 客户可确认本次不受影响，但仍应按自身升级节奏评估 SHA-1 淘汰计划。
- 关注 GitHub Changelog 和状态页的后续说明，避免把此次 HTTPS/TLS 变更误读为 Git 仓库对象哈希的全面替换。
风险或限制
最大风险是旧环境静默失败或只在特定网络路径失败，排查成本高。其次，企业若把影响范围扩大化，可能误伤仍依赖 SHA-1 的内部系统；若缩小化，又可能漏掉合作 CDN 和 GHEC 数据驻留环境。公告称此前计划在 2026 年 9 月 15 日禁用，并已按计划执行，因此应以实际变更和自身环境验证为准。
这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。
如果把《GitHub 在 HTTPS 中停用 SHA-1》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。