GitHub の HTTPS から SHA-1 が消えた、対象は github.com と partner CDN
GitHub が9月15日に github.com と partner CDN の HTTPS で SHA-1 を無効化した。Enterprise Cloud と Data Residency 版は対象、GHES は対象外。
GitHub が9月15日に github.com と partner CDN の HTTPS で SHA-1 を無効化した。Enterprise Cloud と Data Residency 版は対象、GHES は対象外。
github.com への HTTPS 接続が9月15日を境に失敗し始めたなら、証明書の期限やプロキシ設定より先に TLS の世代を見たほうがいい。GitHub は予告どおり同日、github.com と partner CDN の HTTPS で SHA-1 を無効化した。対象には GitHub Enterprise Cloud と Data Residency 版の Enterprise Cloud が含まれ、GitHub Enterprise Server は含まれない。今日やることがあるかどうかは、自分の接続先がこのどちらに落ちるかで決まる。
| 接続先 | 9月15日の無効化 |
|---|---|
| github.com | 対象 |
| partner CDN | 対象 |
| GitHub Enterprise Cloud | 対象 |
| GitHub Enterprise Cloud with Data Residency | 対象 |
| GitHub Enterprise Server | 対象外 |
出典:GitHub Changelog「SHA-1 in HTTPS on GitHub sunset」(2026年9月15日)
表に出ない条件が一つある。9月15日のうち何時に切り替わったかは changelog に書かれていない。障害の発生時刻と突き合わせて原因を確定させたいなら、公式の記述だけでは足りない。
4月20日の予告は、影響の及ぶ先を接続してくる側の三つに分けている。GitHub のサイトを表示するブラウザ、GitHub API を使うソフトウェア、HTTPS で push と pull をする Git クライアントである。逆に言えば、SHA-1 より新しいアルゴリズムに対応している実装なら、この変更で挙動は変わらない。
7月14日には、周知のためのブラウンアウトが実施されている。UTC の0時から18時のあいだ SHA-1 を一時的に無効化する、という内容だった。このブラウンアウトに CDN は含まれていない。 だから7月14日に何も壊れなかったことは、CDN 経由でアセットやリリース成果物を取得している経路が9月15日以降も通る根拠にはならない。予告の書き方では、partner CDN が範囲に入るのは9月15日の完全無効化からである。
SSH で push と pull をしている経路については、2件の記事のどちらも触れていない。書かれているのは HTTPS と TLS の話に限られる。
予告は確認の手順を用途ごとに書き分けている。ブラウザは最新のものを使い、対応アルゴリズムはブラウザ側のドキュメントで確認する。API に繋ぐ側は新しいフレームワークかライブラリを使う。Git クライアントは新しいバージョンの git を、更新された OS とコンポーネントと組み合わせて使う。
この最後の条件は、git のバージョンを上げるだけでは満たせないことがある。git の HTTPS は複数のライブラリやバックエンドで実装されていて、予告は Linux 上の git が OpenSSL を TLS バックエンドに使う例を挙げている。確認の単位は git 単体ではなく、その下の TLS ライブラリと OS を含む。 ピン留めした古いベースイメージで CI を回しているチームは、ここに引っかかりうる。ただし対応の下限になる git や OpenSSL のバージョンは、どちらの記事にも書かれていない。実際に接続して確かめるほかない。
ブラウザ側の確認先として予告が挙げているのは https://github.dev である。4月の時点でこのホストでは SHA-1 が既に無効化されていて、接続の問題なく表示できればモダンな HTTPS 構成に対応していると判断できる、と書かれている。9月15日の無効化のあともこの確認方法が同じ意味を持つかは、9月15日の記事には書かれていない。
GitHub Enterprise Server が対象外であることは、4月の予告と9月15日の記事の両方に書かれている。自社でホストしている GHES に対して HTTPS で繋いでいるだけなら、この変更のために動く必要はない。見るべきはGHES 自身のリリースのほうだ。
ただし「対象外」と書かれている範囲は、GHES というサーバ側の HTTPS 終端についてである。GHES を運用している環境から github.com や partner CDN へ出ていく通信まで含めて対象外なのかは、どちらの記事にも書かれていない。外へ出る経路を持っているなら、その先は github.com 側の条件に従うと考えるのが自然だが、これは推測であって出典の記述ではない。