GitHub HTTPSのSHA-1廃止に備える, 証明書とレガシーGitクライアント移行の実践設計

GitHubがHTTPSにおけるSHA-1廃止を進めることで、企業側の見えない技術負債が一気に露出します。問題は「SHA-1は古い」という一般論ではなく、社内に残る古いTLS終端やCIランナー、組み込みGitクライアントが連鎖的に失敗することです。

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

典型的な障害ポイント

障害は最新ノートPCより、次のような資産で発生しがちです。

• 長期間更新されていない self-hosted runner
• 社内プロキシやTLSインスペクション装置
• 古いベースイメージを使うビルドコンテナ
• レガシーSDK内蔵のGit実装

ここを無視して一斉切替すると、CI停止やリリース遅延が起きます。

実務向け移行ステップ

1. git clone/fetch 経路を可視化し、利用クライアントとTLSライブラリを棚卸し
2. 重要度で分類（本番CI, 開発端末, 補助自動化）
3. 本番CIから先に更新し、観測しながら段階拡大
4. 例外は期限付きで運用し、恒久化を防止

移行はセキュリティ施策であると同時に、プラットフォーム信頼性改善です。

導入すべき統制

• 非対応クライアントを検知する事前チェックをCIに追加
• 検証済み暗号スタックを含む標準ランナーイメージを提供
• 失敗時の一次切り分け手順を運用Runbook化
• 例外承認にTTLと責任者を必須化

組織運用のコツ

移行期間中は、障害を個別Slackで捌かず、単一ダッシュボードで一元管理します。影響リポジトリ, オーナー, 暫定対処, 恒久対応ETAを同じ画面で見える化すると、意思決定が早くなります。

まとめ

SHA-1廃止対応は、証明書だけの話ではありません。古い前提を抱えた開発基盤を一掃する機会です。ここで標準イメージ, 検証ゲート, 期限付き例外を整備できる組織は、今後の暗号移行でも止まりにくくなります。