GitHubへのHTTPS接続で、古いSHA-1前提の証明書チェーンや旧式のHTTPSクライアントを使っているチームは、2026年7月14日のブラウンアウト前に棚卸しと更新を始めるべきです。結論から言うと、影響を受ける可能性があるのはブラウザだけではありません。GitHub APIを呼び出す社内ツール、HTTPSでpush/pullするGitクライアント、CI/CD内のcurlやSDK、プロキシ、コンテナイメージまで確認対象です。
GitHubは2026年4月20日、GitHubおよびCDNのHTTPS通信からSHA-1の利用を段階的に廃止すると発表しました。対象はgithub.com、GitHub Enterprise Cloud、GitHub Enterprise Cloud with Data Residencyで、GitHub Enterprise Server自体は対象外です。2026年7月14日に一時的な無効化テスト、2026年9月15日に完全無効化が予定されています。(The GitHub Blog)
GitHubのSHA-1 HTTPS廃止で何が変わるのか
今回の変更は、GitのコミットIDに使われるSHA-1の話ではありません。対象は、GitHubへHTTPSで接続する際のTLSや証明書まわりです。
つまり、次のような通信が影響を受ける可能性があります。
| 確認対象 | 具体例 | 影響が出やすいケース |
|---|---|---|
| ブラウザ | GitHubのWeb画面閲覧 | 古いOS、更新されていないブラウザ、社内端末の固定イメージ |
| Gitクライアント | git clone、git fetch、git pushをHTTPSで実行 | 古いGit、古いOpenSSL/libcurl、古いWindows端末 |
| APIクライアント | REST API、GraphQL API、GitHub Apps、社内Bot | 古いJava/Python/Node.js、古いコンテナベースイメージ |
| CI/CD | Jenkins、GitLab CI、self-hosted runner、社内ビルドサーバー | 長期間更新していないランナー、古いDockerイメージ |
| ネットワーク機器 | TLS検査プロキシ、SSLインスペクション、社内CA | プロキシ側の証明書チェーンやTLS実装が古い |
| CDN経由の取得 | ソースアーカイブ、rawファイル、依存ファイルの取得 | github.com本体だけをテストしてCDN経路を見落とす |
特に危険なのは、「開発者のPCでは問題ないが、本番デプロイ用の古いCIサーバーだけ失敗する」パターンです。GitHubのHTTPS接続は、開発・ビルド・デプロイ・セキュリティスキャンの複数工程で使われるため、個人端末だけで判断すると漏れが出ます。
廃止スケジュールと移行期限
GitHubが公表しているスケジュールでは、まずブラウンアウトで影響範囲を可視化し、その後に完全無効化します。ブラウンアウトは「一時的にSHA-1を無効化する予行演習」と考えると分かりやすいです。(The GitHub Blog)
| 日付 | 内容 | 対応の意味 |
|---|---|---|
| 2026年4月20日 | GitHubがSHA-1廃止を告知 | 移行計画を開始するタイミング |
| 2026年7月14日 00:00〜18:00 UTC | ブラウンアウト。GitHub側で一時的にSHA-1を無効化 | 影響を受けるクライアントを本番相当で検出できる |
| 2026年7月14日 09:00〜2026年7月15日 03:00 JST | 日本時間でのブラウンアウト期間 | 日本のチームは業務時間中から深夜帯まで監視が必要 |
| 2026年9月15日 | GitHubおよびパートナーCDNで完全無効化 | 未対応のHTTPSクライアントは恒久的に失敗する可能性がある |
注意したいのは、7月のブラウンアウトではCDNが対象外とされている点です。一方、9月の完全無効化ではGitHubとパートナーCDNが対象に含まれます。ブラウンアウトでgit cloneだけ成功しても、rawファイル取得、リリースアーカイブ取得、依存関係のダウンロードまで安全とは限りません。
まず影響を受けるチームか判断する
最初にやるべきことは、「SHA-1を使っているか」を暗号の専門家だけで調べることではありません。GitHubへHTTPS接続している場所を洗い出し、古いTLSスタックが残っていないかを確認することです。
影響を受けやすい環境
次のいずれかに当てはまる場合は、優先的に確認してください。
| リスクの高い環境 | 見るべきポイント |
|---|---|
| 長期間更新していないLinuxサーバー | OpenSSL、curl、Git、CA証明書パッケージ |
| 古いWindows端末 | Git for Windows、Windowsの証明書ストア、Schannel設定 |
| 古いJavaアプリ | JDK/JRE、信頼ストア、HTTPクライアントライブラリ |
| Python 2系や古いPython 3系 | OpenSSL連携、requests、コンテナイメージ |
| 古いNode.js | Node本体、OpenSSLバージョン、GitHub API SDK |
| 社内プロキシ経由の通信 | TLSインスペクション、社内CA、プロキシ製品のファームウェア |
| self-hosted runnerやJenkins | ランナーOS、ビルドイメージ、ジョブ内のgitやcurl |
| ベンダー製の連携ツール | GitHub Apps、Webhook処理、ソース取得機能 |
「GitHubのWeb画面が開けるから大丈夫」と判断するのは危険です。ブラウザは最新でも、CIのコンテナ内で使っているcurlやJavaランタイムが古いことはよくあります。
接続テストで確認すべきコマンド
まずは代表的な接続経路をテストします。テストは、開発者PC、本番CI、self-hosted runner、社内プロキシ配下の端末、コンテナ内のそれぞれで実行してください。
ブラウザの簡易確認
GitHubは、SHA-1がすでに無効化されている確認先としてgithub.devを案内しています。ブラウザで問題なく表示できる場合、そのブラウザはより新しいHTTPS構成に対応していると判断できます。(The GitHub Blog)
ただし、これはブラウザの確認にすぎません。APIクライアント、Gitクライアント、CI/CDの確認は別途必要です。
Gitクライアントの確認
git --version
git remote -v
git ls-remote https://github.com/github/docs.git HEAD失敗する場合は、詳細ログを取得します。
GIT_CURL_VERBOSE=1 git ls-remote https://github.com/github/docs.git HEAD確認すべきポイントは、Gitのバージョンだけではありません。Gitが内部で使うHTTPSバックエンド、OSの証明書ストア、OpenSSLやlibcurlの更新状況も関係します。
git config --show-origin --get http.sslBackendWindowsではGit for WindowsとOS側の証明書ストア、LinuxではOpenSSL/libcurl/CA証明書パッケージ、macOSではシステムキーチェーンやGitの導入方法を確認します。
curlとOpenSSLの確認
curl -Iv https://github.com/
curl -Iv https://api.github.com/
curl -Iv https://github.dev/OpenSSLが使える環境では、バージョンと証明書チェーンの確認も行います。
openssl version -a
openssl s_client -connect github.com:443 -servername github.com </dev/nullここで失敗する場合は、アプリケーションではなくOSやTLSライブラリの問題である可能性が高くなります。
言語ランタイムの確認
GitHub APIを使う社内ツールやBotは、言語ランタイムごとに確認します。
python -c "import ssl, sys; print(sys.version); print(ssl.OPENSSL_VERSION)"node -p "process.version + ' OpenSSL ' + process.versions.openssl"java -versionJavaの場合は、アプリが使っているJDK/JREと実行環境の信頼ストアが一致しているかも確認してください。サーバー上では新しいJavaを入れていても、サービス定義やコンテナが古いJREを参照していることがあります。
移行の進め方：更新すべき順番
SHA-1廃止への対応は、単に「証明書を更新する」作業ではありません。実務では、GitHubへ接続するクライアント側のTLS環境を新しくする作業になります。
優先順位は本番影響から決める
最初に直すべきなのは、開発者の個人PCではなく、止まるとリリースや障害対応に直結する経路です。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 最優先 | 本番デプロイ用CI/CD、リリースパイプライン | 失敗するとデプロイやロールバックが止まる |
| 高 | セキュリティスキャン、SBOM生成、依存関係取得 | 脆弱性対応や監査に影響する |
| 高 | GitHub APIを使う社内Bot、GitHub Apps | 承認、通知、自動化が止まる可能性がある |
| 中 | 開発者PC、社内VDI | 個別対応できるが問い合わせが集中しやすい |
| 中 | 検証環境、古い検証サーバー | 普段使わないため見落とされやすい |
実際に更新するコンポーネント
移行では、次のコンポーネントをまとめて更新します。
- OSのセキュリティ更新
- CA証明書パッケージ
- Git
- curl/libcurl
- OpenSSL、LibreSSL、またはOS標準のTLSバックエンド
- Java、Python、Node.js、Goなどのランタイム
- GitHub API SDKやHTTPクライアントライブラリ
- Dockerベースイメージ
- TLS検査プロキシや社内CA関連の設定
GitHub Docsでは、HTTPSのクローンエラーについて、古いGitやアクセス権限の問題が原因になることがあると案内しています。今回のSHA-1廃止対応では、認証エラーとTLSエラーを混同しないことが重要です。(GitHub Docs)
ありがちな失敗と回避策
失敗：GIT_SSL_NO_VERIFY=trueで回避する
TLSエラーが出たときに、証明書検証を無効化して回避するのは危険です。一時的に接続できても、中間者攻撃を検知できなくなります。CI/CDでこの設定が残ると、ソースコード取得や依存関係取得の信頼性が落ちます。
正しい対応は、証明書検証を無効化することではなく、OS、CA証明書、TLSライブラリ、Gitクライアントを更新することです。GitHub Docsでも、CAルート証明書が古い場合はpush/pullできなくなる可能性があり、一般にOS更新でCAも更新されると説明されています。(GitHub Docs)
失敗：ブラウザだけ更新して完了にする
ブラウザでGitHubが見えることと、CI内のgit fetchが成功することは別です。特にコンテナ内で古いディストリビューションを使っている場合、ホストOSが新しくてもコンテナ内のCA証明書やOpenSSLが古いままです。
次のように、実際のジョブと同じ環境で確認してください。
docker run --rm your-build-image:tag git --version
docker run --rm your-build-image:tag curl -Iv https://api.github.com/失敗：CDN経路をテストしない
GitHub本体への接続だけでなく、rawファイル、リリースアーカイブ、ソースアーカイブ、依存関係取得も確認します。7月のブラウンアウトではCDNが対象外ですが、9月の完全無効化ではパートナーCDNも対象です。(The GitHub Blog)
CIで次のような処理がある場合は、棚卸し対象に入れてください。
- GitHub Releasesからバイナリをダウンロードする
- rawファイルを
curlで取得する - GitHub上のテンプレートや設定ファイルを取得する
- セキュリティツールがGitHubから定義ファイルを取得する
- IaCやビルドスクリプトがGitHub上の外部ファイルを参照する
SSHへの切り替えは暫定策として使えるか
HTTPSでのGit操作が期限までに更新できない場合、Gitのclone/push/pullについてはSSHへ切り替える選択肢があります。GitHub Docsでも、HTTPSでのクローンが難しい場合にSSHのclone URLを使う方法が案内されています。(GitHub Docs)
ただし、SSHは万能な代替策ではありません。
| 用途 | SSHで代替できるか | 補足 |
|---|---|---|
git clone | 可能 | リモートURLをSSH形式に変更する |
git fetch / git push | 可能 | SSHキーやDeploy keyの管理が必要 |
| GitHub API | 不可 | APIはHTTPSクライアントを更新する必要がある |
| ブラウザ閲覧 | 不可 | ブラウザとOS更新が必要 |
| rawファイル取得 | 基本的に不可 | curlなどHTTPS経路の更新が必要 |
ファイアウォールの都合で通常のSSHが使えない場合、GitHubはSSHをHTTPSポートで使う方法も案内しています。この場合のホスト名はgithub.comではなくssh.github.com、ポートは443です。ただし、GitHub Enterprise ServerおよびGitHub Enterprise Cloud with Data Residencyでは、このSSH over HTTPS portはサポートされていません。(GitHub Docs)
トラブル発生時の切り分け表
ブラウンアウト中や完全無効化後に障害が起きた場合は、エラーメッセージだけで判断せず、発生場所と通信経路を分けて確認します。
| 症状 | 可能性が高い原因 | 最初に確認すること |
|---|---|---|
| ブラウザでGitHubが開けない | 古いブラウザ、OS、社内プロキシ | github.devが表示できるか、別ネットワークで再現するか |
git cloneだけ失敗する | Git、libcurl、TLSバックエンド、CA証明書 | git --version、GIT_CURL_VERBOSE=1のログ |
| APIクライアントだけ失敗する | 言語ランタイム、HTTPライブラリ、コンテナイメージ | Python/Node/JavaのバージョンとOpenSSL |
| 社内ネットワークだけ失敗する | TLS検査プロキシ、社内CA | プロキシなしの回線で成功するか |
| 401/403が出る | 認証・権限・トークンの問題 | PAT、GitHub App権限、SAML SSO認可 |
SSL certificate problemが出る | CA証明書や証明書チェーンの問題 | OS更新、CA証明書パッケージ、プロキシ証明書 |
| rawファイルやアーカイブだけ失敗する | CDN経路の未確認 | GitHub本体以外のダウンロード先を棚卸し |
401や403は、SHA-1廃止ではなく認証や権限の問題である可能性が高いです。TLSエラーと認証エラーを同じ障害として扱うと、不要な証明書変更やトークン再発行が増えます。
エンタープライズ管理者向けの移行チェックリスト
GitHub Enterprise Cloudを使う企業では、個別チーム任せにせず、管理者側で横断的に進めるのが安全です。
棚卸し
- GitHubへHTTPS接続するCI/CD基盤を一覧化する
- GitHub APIを使う社内ツール、Bot、GitHub Appsを洗い出す
- self-hosted runner、Jenkins agent、古いVM、VDIを確認する
- Dockerベースイメージとランタイムの更新状況を確認する
- TLS検査プロキシ、社内CA、出口ゲートウェイを確認する
- CDN経由のGitHubコンテンツ取得を確認する
検証
github.devでブラウザ確認を行うgit ls-remoteでHTTPS Git操作を確認するcurl -IvでGitHub APIへの接続を確認する- 代表的なCIジョブを本番と同じイメージで実行する
- 社内プロキシ配下とプロキシ外の両方でテストする
- 7月14日のブラウンアウト時間帯に監視とログ収集を行う
移行
- 古いOSとランタイムを更新する
- Git、curl、OpenSSL、CA証明書を更新する
- 古いコンテナベースイメージを差し替える
- HTTPS Git操作を継続するか、SSHへ切り替えるかを決める
- APIクライアントはHTTPS対応を必ず完了する
GIT_SSL_NO_VERIFYなどの危険な暫定設定を削除する
周知
- 2026年7月14日のブラウンアウト日時を開発部門へ通知する
- 2026年9月15日の完全無効化までに対応期限を設定する
- 失敗時の問い合わせ先をDevOps、セキュリティ、ネットワークで分ける
- 影響が出たジョブ名、端末名、エラー内容を記録するテンプレートを用意する
どこまで対応すれば安全か
安全ラインは、「最新版にした」ではなく「実際の通信経路で成功した」です。次の4つを満たしていれば、移行リスクはかなり下げられます。
| 確認項目 | 合格基準 |
|---|---|
| ブラウザ | github.devが問題なく表示できる |
| Git操作 | 本番CIと開発端末でHTTPSのgit ls-remoteが成功する |
| API通信 | 社内ツールやBotがapi.github.comへ正常接続できる |
| CDN経路 | rawファイル、リリース、アーカイブ取得が成功する |
逆に、次の状態は未対応と考えるべきです。
- 開発者PCだけで確認している
- CIのホストOSだけ更新し、コンテナ内を確認していない
- GitHub APIを使う社内ツールを棚卸ししていない
- TLS検査プロキシや社内CAを確認していない
- 7月のブラウンアウトで失敗していないからCDNも安全だと判断している
まとめ：今やるべきこと
GitHubのSHA-1 HTTPS廃止は、セキュリティ強化として自然な流れですが、古いクライアントが残っている組織ではリリース停止やAPI連携障害につながります。
まずは、GitHubへHTTPS接続している場所を棚卸ししてください。次に、Git、curl、OpenSSL、CA証明書、言語ランタイム、コンテナイメージ、社内プロキシを実環境で確認します。Git操作だけならSSHへの切り替えも選択肢ですが、APIやブラウザ、CDN経由の取得はHTTPSクライアントの更新が必要です。
2026年7月14日のブラウンアウトは、単なる予定イベントではなく、本番相当で影響範囲を見つける機会です。9月15日の完全無効化までに、CI/CD、API連携、プロキシ、コンテナの順で対応を完了させましょう。
コメント