エラーの発生状況ワークフローの途中で、重要なアップデートをプッシュしようとしたその時、Gitが突然停止することがあります。通常のプログレスバーの代わりに、次のようなイライラさせるエラーメッセージが表示されます。
fatal: unable to access 'https://github.com/...': SSL certificate problem: self signed certificate in certificate chain
これは通常、Gitがサーバーの身元を検証できない場合に発生します。GitHubやGitLabがダウンしているように見えるかもしれませんが、原因のほとんどはローカルマシンやオフィスネットワーク内にあります。
なぜGitは接続をブロックするのか？Gitはネットワーク通信にcURLライブラリを使用しています。HTTPS経由で接続する場合、Gitは世界的に信頼された認証局（CA）によって署名された証明書を期待します。「self signed certificate（自己署名証明書）」エラーは、通常次の3つの理由のいずれかで発生します。
- **企業プロキシとインスペクション：**Zscaler、Fortinet、Blue Coatなどのセキュリティツールは、脅威をスキャンするためにトラフィックを傍受することがよくあります。これらのツールは、本物のGitHub証明書をGitが認識できない社内発行の証明書に置き換えます。- **ローカルアンチウイルスソフトの干渉：**KasperskyやBitdefenderなどのスイートは、Webトラフィックを監視するためにSSLチェーンに介入し、実質的に「善意の」中間者攻撃（man-in-the-middle）のように振る舞うことがあります。- **古いCAバンドル：**Gitのインストール環境が、何年も更新されていない古い
ca-bundle.crtファイル内の証明書を参照している可能性があります。## 解決策1：迅速な（ただし安全ではない）回避策納期が迫っており、信頼できるプライベートネットワークで作業している場合は、チェックをバイパスできます。**注意して使用してください：**SSL検証を無効にすると、中間者（MitM）攻撃に対して脆弱になります。これは、鍵が壊れているからといって玄関の鍵をかけないでおくようなものです。 グローバルで検証を無効にするには：
git config --global http.sslVerify false
単一のコマンドに対してのみチェックをスキップしたい場合：
git -c http.sslVerify=false clone https://github.com/username/repo.git
解決策2：Windows Secure Channelを使用する（Windows推奨）Windowsマシンを使用している場合、これが最もスマートな修正方法です。デフォルトでは、Gitは独自の信頼済み証明書リストを保持するOpenSSLライブラリを使用します。これを、Windowsの証明書ストアを使用するようにGitに指示できます。
git config --global http.sslBackend schannel
これにより、IT部門がグループポリシーを通じて既に承認している証明書を、Gitが自動的に信頼するようになります。高いセキュリティを維持しつつ、「一度設定すればOK」の解決策です。
解決策3：企業のCA証明書を追加するOpenSSLを使用する必要がある場合（LinuxやmacOSで一般的）、会社のルート証明書を信頼するようにGitに手動で教える必要があります。
ステップ1：証明書を取得するWindowsでは、ChromeでリポジトリのURLを開きます。鍵アイコン > この接続は保護されています > 証明書は有効ですをクリックします。詳細タブで階層の最上位にある証明書を見つけ、Base-64 encoded X.509 (.CER) ファイルとしてエクスポートします。
macOSやLinuxでは、次のコマンドを使用して証明書チェーンを直接取得できます。
openssl s_client -showcerts -connect github.com:443 </dev/null
ステップ2：Gitにファイルパスを指定するファイル（例：company-root.pem）を入手したら、その場所をGitに伝えます。
git config --global http.sslcainfo "C:/Users/YourName/certs/company-root.pem"
検証コードを変更せずに、ls-remote を実行して接続をテストします。このコマンドはサーバーにブランチとタグのリストを要求します。
git ls-remote https://github.com/your-org/your-repo.git
ハッシュとリファレンスのリストが表示されれば、ハードルを無事にクリアしたことになります。
企業ネットワークのナビゲーションエンタープライズ環境での接続のデバッグは、探偵の仕事のように感じられることがよくあります。自分のIPが奇妙なルートを通っている疑いがある場合は、IP Subnet Calculator などのツールを使用して、内部ゲートウェイに到達しているのか、公開プロキシに到達しているのかを確認するのに役立ちます。私はよく、内部のGitLabインスタンス用に NO_PROXY の範囲を定義するためにこれを使用します。
最後に、環境変数を確認してください。ターミナルで env | grep -i proxy を実行します。プロキシが定義されている場合は、HTTP_PROXY と HTTPS_PROXY の設定が一致していることを確認してください。ここでの不一致は、SSLハンドシェイク失敗の一般的な原因です。