gitでsslのno verify設定を安全に行う手順と注意事項

目次

はじめに

本記事は、Gitのコマンド実行時に発生するSSL証明書に関するエラーを回避するため、検証を一時的に無効化(スキップ)する方法と注意点を分かりやすく解説します。

想定する読者は、自己署名証明書や社内で配布されたカスタム証明書を使う環境で、Gitのクローンやプッシュが失敗する方です。例えば、開発用サーバーが自己署名証明書を使っている、あるいは社内プロキシが独自の証明書で通信を中継しているときにエラーが出ることがあります。

本記事では、まずSSL検証の役割を簡単に説明します。その後、検証を無効化する具体的な方法を紹介し、無効化するときのセキュリティリスクも丁寧に説明します。最後に、安全に運用するための代替策やトラブルシューティングのポイントをまとめます。

以降の章で手順と注意点を順を追って説明しますので、ご自身の環境に合わせて読み進めてください。

GitのSSL証明書検証とは

概要

GitはHTTPSでリモートリポジトリへ接続するとき、相手側のSSL/TLS証明書が正しく信頼できるかを確認します。これは通信の盗聴や改ざん、なりすまし(MITM攻撃)を防ぐための基本的な仕組みです。

なぜ検証するのか

例えば、あなたがリモートのサーバーへpushするとき、第三者が通信を傍受して内容を書き換えると危険です。証明書検証は「相手が本当にそのサーバーか」「証明書が信頼できる機関によって発行されているか」「期限が切れていないか」を確かめます。これにより安全な通信路を確保します。

Gitはどのように検証するか

Gitは内部でHTTPライブラリ(例: libcurl)やシステムのSSLライブラリ(例: OpenSSL)を使い、次の点をチェックします。
– 証明書の署名が信頼できる認証局(CA)によるものか
– 証明書の有効期限
– 接続先ホスト名が証明書の名前(CNまたはSAN)と一致するか

よくあるエラー例と原因

  • “certificate verify failed”:署名済みの信頼チェーンが見つからない場合
  • “unable to get local issuer certificate”:中間証明書が欠けている場合
  • ホスト名不一致:証明書の名前が接続先と違う場合

これらは主に社内で自己署名証明書を使っている環境や、プロキシが通信を差し替えている環境で発生します。次章では、こうした状況での対処法を扱います。

SSL検証を無効化する方法

概要

状況に応じてSSL検証を一時的または限定的に無効化できます。ここではコマンド単位、リポジトリ単位、全体設定、設定ファイル編集の方法を分かりやすく示します。

1) コマンド実行時のみ(一時的)

環境変数を使うと、そのコマンドだけSSL検証をスキップできます。例:

  • Unix/macOS(1回だけ):
    GIT_SSL_NO_VERIFY=true git clone https://example.com/repo.git
  • セッション内で有効にする(bash):
    export GIT_SSL_NO_VERIFY=true
    git pull
    unset GIT_SSL_NO_VERIFY

Windows(PowerShell):
$env:GIT_SSL_NO_VERIFY = “true”; git clone https://example.com/repo.git

2) リポジトリ単位で無効化

そのリポジトリ内だけ無効化します。作業するリポジトリのルートで実行してください。

git config http.sslVerify false

元に戻すには:
git config –unset http.sslVerify

3) 全体で無効化(グローバル設定)

すべてのリポジトリでSSL検証を無効化します。使うときは慎重にしてください。

git config –global http.sslVerify false

取り消すには:
git config –global –unset http.sslVerify

4) 設定ファイルを直接編集する

  • リポジトリ単位: .git/config
  • 全体: ~/.gitconfig または Windows: %USERPROFILE%.gitconfig

上記のファイル内で “[http]” セクションに sslVerify = false を追加または削除します。

注意: これらは検証をスキップする方法です。安全性の影響については第4章で詳しく説明します。

SSL検証無効化のセキュリティリスク

概要

SSL検証を無効にすると、通信内容は暗号化される場合がありますが、相手サーバーの正当性が確認できません。そのため第三者が通信の中間に入り込む中間者攻撃(MITM)のリスクが高まります。

具体的なリスク

  • パスワードやアクセストークンの漏洩:認証情報や個人情報が盗まれる恐れがあります。例:CIに保存したトークンが傍受されると、リポジトリを書き換えられます。
  • データ改ざん:ダウンロードしたコードやパッチに悪意ある変更が加えられる可能性があります。
  • なりすまし:攻撃者が正規サーバーに見せかけて応答し、機密情報を奪うことができます。

実運用での注意点

無効化は一時的なトラブルシューティングや、閉域ネットワークで自己署名証明書を使う場合に限定してください。恒常運用や公開環境では避けるべきです。

推奨対策

  • 正しい証明書を導入する、またはCAを信頼ストアに追加する。
  • 一時的に無効化する場合は時間を限定し、作業後に元に戻す。
  • 可能ならSSH鍵認証やVPNを使って安全に接続する。

トラブルシューティングと代替策

1) まずは原因を切り分けます

  • エラーメッセージを確認し、ホスト名や証明書の期限切れ、チェーン不備がないか見ます。例: “certificate signed by unknown authority”。
  • 他のツールで同じサイトに接続できるか試します(例: ブラウザ、curl)。これで問題が Git 側か環境側か分かります。

2) 自己署名証明書を信頼ストアに追加する

  • Windows: 管理者権限で certutil を使うか、証明書をダブルクリックして「ローカルコンピューターの信頼されたルート証明機関」に追加します。
  • macOS: sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain cert.pem
  • Linux: /usr/local/share/ca-certificates/ に .crt を置き、sudo update-ca-certificates を実行します。
    この方法は安全で、恒久的にエラーを解消できます。

3) Git クライアントに証明書パスを明示する

  • リポジトリまたはグローバル設定で指定します。例: git config –global http.sslCAInfo /path/to/ca.pem
  • CI や複数端末で使うときは、各環境で同じパスを用意するか、環境変数で指定します。

4) プロキシやネットワーク構成の見直し

  • 会社のプロキシが中間で証明書を書き換えている場合があります。プロキシの CA を信頼ストアに入れるか、プロキシ設定を見直します。
  • VPN、ファイアウォール、DNS が影響する場合もあるため、ネットワーク管理者に確認します。

5) 一時的な回避策と注意点

  • 一時的に git -c http.sslVerify=false clone … のようにして回避できますが、安全性が大きく下がります。短時間での検証に限定してください。

6) テストと検証の方法

  • curl -v –cacert /path/to/ca.pem https://your.git.server で接続確認します。
  • openssl s_client -connect your.git.server:443 -showcerts で証明書チェーンを確認します。

7) 運用上のおすすめ

  • 証明書は自動配布(構成管理ツール)で配ると手作業ミスを減らせます。
  • CIやビルド環境にも同じ信頼設定を適用し、再発を防ぎます。
  • 可能なら正式な認証局発行の証明書を使うことを検討してください。

まとめ

ここまでの内容を踏まえ、重要なポイントを分かりやすくまとめます。

  • 暫定対処に留める
  • SSL検証の無効化は一時的な回避策です。長期間の運用は避けます。例:一時的に GIT_SSL_NO_VERIFY=true を使うか、git -c http.sslVerify=false コマンドで単発の操作に限定します。

  • 恒久的な対策を優先する

  • 可能な限り正規の証明書を使い、システムやブラウザの信頼ストアに追加します。社内CAの場合はそのCA証明書を信頼ストアへ入れると安全で便利です。

  • 設定は局所的にする

  • リポジトリ単位や一時的な環境変数で対処し、グローバル設定で無効化しないようにします。作業後は必ず元に戻します(例:git config –unset http.sslVerify)。

  • トラブル時の確認項目

  • エラーメッセージ、時刻設定、証明書チェーン、プロキシ設定を順に確認します。根本原因を解決すれば安全に復帰できます。

日常的には正しい証明書運用と信頼ストアの管理で、セキュリティと利便性を両立してください。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

目次