GitHub の SSL エラー、http.sslVerify false ではなく安全な方法で解決しよう
はじめに
社用 PC にインストールされているセキュリティソフトによっては、SSL インスペクション機能により、git fetch などのコマンドを実行すると、以下のエラーが発生します。
$ git fetch
fatal unable to access "URL": SSL peer certificate or SSH remote key was not OK
ネット上では、以下の対処方法が紹介されることが多いです。
# HTTPS通信でのサーバー証明書の検証を無効にする
git config --global http.sslVerify false
しかし、この方法は中間者攻撃リスクを増加させます。わざわざ脆弱性を作る必要はありません。
また、社内のセキュリティポリシーへ抵触する可能性も考えられます。
SSL インスペクション機能に起因したエラーの場合、サーバー証明書の検証を有効にしたままでも接続を確立することが可能です。
本記事では、セキュリティソフト Zscaler を導入している社用 PC（Windows11）を例として、対処法を紹介します。
SSL インスペクション機能について
# 通常
PC → GitHub サーバー
# SSL インスペクション機能あり
PC → Zscaler → GitHub サーバー
Zscaler 公式の解説が分かりやすいので、引用します。
SSLインスペクションとは、クライアントとサーバーの間のSSL暗号化されたインターネット通信を捕捉し、検査することです。インターネット トラフィックの大部分はSSL暗号化されていますが、悪意のあるコンテンツが含まれている場合もあるため、SSLトラフィックの検査は極めて重要になっています。
git などの一部のアプリケーションでは、通信に Zscaler が割り込むことによって、証明書の検証が上手くいかずエラーとなります。
(補足) Zscaler 以外のセキュリティソフトについて
Zscaler 以外にも SSL インスペクション機能を持つセキュリティソフトがあります。
手元に検証環境が無いため、本記事では割愛しますが、Zscaler での対処法を応用できるかもしれません。
SSL エラーの原因調査
以下のコマンドで GitHub への接続時の通信状況を確認できます。
$ openssl s_client -crlf -connect www.github.com:443
CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
verify return:1
depth=0 CN = github.com
verify return:1
---
# 省略
上記は SSL インスペクション機能が無い状態での結果です。
depth=2、depth=1、depth=0 と書かれている箇所は、SSLサーバー証明書の階層構造を示しています。
以下の様な流れで GitHub.com のサーバー証明書が信頼できるか（改竄されていないか）を検証しています。
GitHub.comのサーバー証明書 (depth=0)
↑ 発行/署名
中間証明書 (Sectigo ECC Domain Validation Secure Server CA) (depth=1)
↑ 発行/署名
ルート証明書 (USERTrust ECC Certification Authority) (depth=2)
Zscaler の SSL インスペクションが有効になっている場合、GitHub のサーバー証明書の検証時に、システムが Zscaler のルート証明書（depth=2）を適切に取得できず、エラーが発生します。
depth=2 <略> CN = Zscaler Intermediate Root CA
verify error:num=20:unable to get local issuer certificate
verify return:1
Zscaler 公式にて、git などの一部のアプリケーションでこの様な問題が起こると記載があります。
一部のアプリケーションでは、デフォルトのシステム信頼ストアを使用する代わりに、カスタム信頼ストアを維持します。その結果、アプリケーションはZscalerで生成されたサーバー証明書を検証できず、TLS接続は失敗します。このような場合、ユーザーはカスタム ルート証明機関(CA)をカスタム信頼ストアに手動で追加するか、サーバー証明書の検証を無効にする必要があります。
サーバー証明書の仕組みについては下記が参考になりました。
対処方法
流れ
- PCに登録されている Zscaler ルート証明書をエクスポート
- git config に証明書のパスを登録
- 完了！
手順は下記を参考にしています。
ルート証明書のエクスポート
certmgr を実行します。
start certmgr.msc
信頼されたルート証明機関＞証明書 を開きます。
発行者に Zscaler の名前が含まれる証明書を探し、右クリック＞すべてのタスク＞エクスポートを選択します。
次へを押すとエクスポートするファイル形式の選択画面となります。
Base 64 encoded X.509 (.CER) を選択します。
任意のフォルダを保存先に指定します。
ファイル名は自由な様です。私は ZscalerRootCA.cer としました。
git config に証明書のパスを登録
エクスポートした証明書を任意のディレクトリに移動させます。
Zscaler の公式解説に準拠し、C:\Users\<ユーザー名>\AppData\Roaming に今回は保存します。
以下のコマンドで用意した証明書を git が参照できるようにします。
git config --global http.sslcainfo C:\Users\<ユーザー名>\AppData\Roaming\ZscalerRootCA.cer
これで設定は完了です。
おわりに
安直に git config --global http.sslVerify false を設定してはいけない。
エラーの原因を精査し、適切な設定を行うことで、セキュリティを維持したまま問題を解決できます。
安直に git config --global http.sslVerify false を設定してはいけない。
Discussion