GHE.com は10月7日から、X25519 限定の HTTPS 接続を受け付けない。影響するプロキシや TLS 設定、P-256 を有効にする事前対応、SSH が対象外である点を整理する。
2026年10月7日 GHE.com が X25519 だけを提示する TLS 接続を拒否し始める日 GitHub changelog 2026年9月30日付。P-256 と P-384 は引き続きサポートされる
2026年10月7日から、データレジデンシー付きの GitHub Enterprise Cloud（GHE.com）は、TLS の鍵共有で X25519 だけを提示するクライアント からの接続を受け付けなくなる。GitHub の changelog（2026年9月30日付）によると、この日以降、そうしたクライアントは HTTPS 接続を確立できない。changelog の URL には「september-15」という語が残っているが、見出しと本文はどちらも10月7日としている。
大半の組織は何もしなくてよい。changelog には「Most customers don’t need to take action.」とあり、現行のブラウザ、OS、GitHub CLI のリリース、よく使われる TLS ライブラリはすでに P-256 をサポートしていると説明されている。確認が要るのは、アプリケーション、プロキシ、セキュリティアプライアンス、TLS ライブラリのいずれかで、提示するグループを X25519 だけに 明示的に 絞っている環境である。
対象のエンドポイントでは、FIPS 承認の P-256（secp256r1）と P-384（secp384r1）が引き続きサポートされる。今回の変更で扱いが変わるのは、クライアントが X25519 しか出さなかった場合だけだ。その接続は10月7日以降、TLS の段階で成立しなくなる。
X25519 と P-256 を両方提示するクライアントは、この条件に当たらない。ただ、その場合にサーバーがどちらのグループを選ぶのか、X25519 での鍵共有が今後も成立するのかは changelog に書かれていない。
対象エンドポイントの一覧も載っていない。HTTPS で行う Git 操作や API 呼び出しも同じ条件に置かれると読めるが、これは「HTTPS 接続」という書き方からの推測で、個々の経路が名指しされているわけではない。切り替えの時刻とタイムゾーンも示されていないので、10月7日の朝に切り替わる前提で動いておくほうが安全だ。
既定のまま新しめの版を使っている端末やツールは、changelog の説明どおりなら P-256 をサポートしている。問題になるのは、セキュリティ方針や性能上の理由で鍵共有グループを指定し直した場所だ。changelog が挙げる候補は次の四つになる。
TLS をいったん終端して GHE.com へ接続し直す中継機器を挟んでいる場合、一般論として GHE.com から見えるのは中継機器が提示するグループだ。開発者の端末でブラウザや GitHub CLI が問題なく動いていても、中継機器の設定が X25519 限定なら接続は失敗しうる。手元で再現しないからといって安心はできない。
changelog が挙げている事前対応は三つある。
確認コマンドや製品ごとの設定項目は changelog に載っていない。プロキシやアプライアンスの設定で、鍵共有に使う曲線やグループを指定している項目を探し、X25519 の単独指定になっていないかを見ることになる。TLS 設定の検証に手助けが要る場合は GitHub Support に問い合わせるよう案内されている。2026年10月3日時点で、期日までは4日しかない。
SSH 接続は影響を受けない。changelog は、この変更の対象をデータレジデンシー付きの GitHub Enterprise Cloud に限っており、github.com はこの告知の範囲に入っていない。
ただし、GitHub の接続条件はこの秋に別の変更も続いている。github.com 側では HTTPS での SHA-1 が9月15日付で廃止され（GitHub の HTTPS から SHA-1 が消えた件）、SSH についても9月22日付で別の告知が出た（ssh-rsa の扱い）。GHE.com と github.com を併用している組織は、プロキシの TLS 設定を見直すついでに、これらの条件もまとめて確認しておくと手戻りが減る。
