SSLインスペクションとは？企業ネットワークで証明書エラーが起きる仕組み

会社のパソコンで、こんなエラーに出くわしたことはないでしょうか。

SSL: CERTIFICATE_VERIFY_FAILED
self signed certificate in certificate chain
unable to get local issuer certificate

自宅では普通に動くのに、会社のネットワークにつないだ途端に動かない。開発ツールやコマンドラインツールで特によく起きる現象です。

背景にあるのがSSLインスペクション（HTTPSインスペクション、TLS復号）と呼ばれる仕組みで、これについては米国の政府機関が公式に注意喚起を出しています。

「HTTPS inspection works by intercepting the HTTPS network traffic and performing a man-in-the-middle (MiTM) attack on the connection.」
（HTTPSインスペクションは、HTTPS通信を傍受し、その接続に対して中間者攻撃を実行することで機能する）
——米国CISA「HTTPS Interception Weakens TLS Security」

攻撃という言葉が使われていますが、違法行為の話ではありません。技術的な仕組みが、中間者攻撃とまったく同じだという意味です。この記事では、なぜ企業がこれを導入するのか、なぜエラーが起きるのか、そして公的機関が何を警告しているのかを整理します。

SSLインスペクションとは何をしているのか

TLS（とその前身のSSL）は、クライアントとサーバーの間の通信を暗号化するプロトコルです。CISAは、証明書によって「信頼された第三者の認証局によって検証された正当なサーバー」との接続であることを示す身元の連鎖が確立される、と説明しています。

「第三者が検証している」という点が、HTTPSの信頼の土台です。

そこに割って入る

SSLインスペクションは、この通信の途中に機器（プロキシやセキュリティアプライアンス）を置き、次のことをします。

1. クライアントとサーバーの間の暗号化された通信をいったん復号する
2. 中身を検査する（マルウェア、情報漏えい、業務外サイトなど）
3. 企業自身が発行した証明書で暗号化し直して、クライアントへ渡す

結果として、通信は次のように2つに分断されます。

区間	誰と誰の通信か	使われる証明書
クライアント ⇔ 検査機器	PC と 社内のセキュリティ機器	企業が発行した証明書
検査機器 ⇔ Webサーバー	社内のセキュリティ機器 と 本物のサーバー	本来の証明書

だから証明書エラーが起きる

クライアントから見ると、本物のサーバーの証明書ではなく、企業が発行した見慣れない証明書が返ってきます。

これをそのまま受け取れば、当然「この証明書は信頼できない」というエラーになります。証明書がどのように検証されるのか（ルート・中間・サーバーの連鎖）は 証明書チェーンとは？中間証明書が欠けるとエラーになる理由 で解説しています。

そこでCISAは、管理者が打つ対策をこう記しています。「クライアントに警告を出さずにHTTPSインスペクションを行うには、管理者はクライアント端末に信頼された証明書をインストールしなければならない」。

企業のPCには、あらかじめ会社の証明書が「信頼するもの」として登録されている——これがブラウザでエラーが出ない理由です。

では、なぜツールではエラーが出るのか

ここが実務上の核心です。

ブラウザはOSの証明書ストアを見ますが、開発ツールの多くは自前の証明書リストを持っています。会社の証明書はOS側に入っていても、ツール側のリストには入っていません。

そのため、ブラウザでは問題なく開けるサイトが、コマンドラインツールでは弾かれます。

• Git——Windowsでは参照先を選べる（企業プロキシ環境でGitがSSLエラーになる理由と対処法）
• AWS CLI——同梱の cacert.pem を参照（企業プロキシ環境でAWS CLIがSSLエラーになる理由と対処法）
• Python（requests等）——certifi パッケージの証明書を参照
• Node.js——バンドルされたルート証明書を参照

「ブラウザでは見られるのに、ツールでは繋がらない」の正体は、たいていこれです。

なぜ企業はこれを導入するのか

手間もリスクもあるのに、なぜ導入されるのか。CISAは、多くの組織が「悪意あるサーバーへのHTTPS接続を使うマルウェアを検知する」ことなどを目的にこの製品を使っている、としています。

現在、Web通信のほとんどはHTTPSで暗号化されています。つまり企業のセキュリティ機器から見ても中身が見えないため、マルウェアの通信も機密ファイルの持ち出しも検知できません。それを見るために復号する——これがSSLインスペクションの目的です。正当な必要性があるからこそ、多くの企業で使われています。

【重要】公的機関が警告していること

ただし、CISAの警告は「導入すればセキュリティが上がる」という単純な話ではないことを示しています。

クライアントは、自分で検証できなくなる

「The problem with this architecture is that the client systems have no way of independently validating the HTTPS connection. The client can only verify the connection between itself and the HTTPS interception product.」
（このアーキテクチャの問題は、クライアント側が独立してHTTPS接続を検証する手段を持たないことである。クライアントは、自分自身と検査製品との間の接続しか検証できない）

本物のサーバーが安全かどうかの判断を、検査機器に全面的に委ねることになります。

その検査機器が、正しく検証していない場合がある

CISAは、調査報告に基づいてこう指摘しています。

「Many HTTPS inspection products do not properly verify the certificate chain of the server before re-encrypting and forwarding client data, allowing the possibility of a MiTM attack.」
（多くのHTTPSインスペクション製品は、再暗号化してクライアントのデータを転送する前に、サーバーの証明書チェーンを適切に検証していない。これは中間者攻撃の可能性を許すことになる）

エラーがユーザーに伝わらない

さらにCISAは、「証明書チェーンの検証エラーがクライアントに転送されることはまれ」であり、その結果クライアントは「正しいサーバーと意図したとおりに通信できたと信じてしまう」と述べています。

危険なサイトに繋がっていても、警告が出ないまま通信が成立してしまう可能性があるということです。

弱い暗号が使われていても気づけない

検査製品は、自身とWebサーバーの間で非推奨のプロトコルバージョンや弱い暗号の使用を許してしまうことがあります。しかしクライアントは強い暗号で検査製品に接続しているため、CISAの表現を借りれば「反対側の弱さにユーザーは気づかない」という状態になります。

手元のブラウザには鍵マークが表示されていても、機器の向こう側では古い暗号が使われているかもしれない、という指摘です。

自社の環境を確認する方法

CISAは、確認に使えるサイトとして badssl.com を挙げ、「HTTPSインスペクション製品が証明書チェーンを適切に検証しているかをクライアントが確認できるリソース」と説明しています。

判断基準も明確です。「直接インターネットに接続したクライアントが接続を拒否するテストは、HTTPSインスペクション製品経由で接続した場合も同様に接続を拒否すべき」——最低限これを満たしているか、というものです。

期限切れの証明書や不正な証明書を使ったテストサイトに、社内から繋がってしまわないか。繋がるなら、検査機器が検証をすり抜けさせている可能性があります。

※実際に検証する際は、情報システム部門に事前に相談してください。無断でセキュリティ機器の挙動を試す行為は、社内規定に抵触する可能性があります。

エラーが出たときの実務対応

やってはいけないこと

検索するとよく出てくるのが、証明書の検証を無効化する方法です。

• --no-verify-ssl / --insecure / -k オプション
• NODE_TLS_REJECT_UNAUTHORIZED=0
• verify=False（Python requests）

これらは「エラーを消す」のではなく「検証をやめる」操作です。

ここまで見てきたとおり、SSLインスペクション環境では検証が既に検査機器に依存した状態にあります。そのうえでクライアント側の検証まで放棄すれば、通信の正当性を確認する主体が誰もいなくなります。一時的な切り分けに使うことはあっても、設定として恒久化しないでください。

正しい方向

会社の証明書を、ツールが参照する証明書ストアに追加するのが本来の対処です。

• 情報システム部門から社内CA証明書を入手する
• ツールごとの証明書ストアに追加する（環境変数で指定できるものが多い）
• ただしツールによっては環境変数が効かない既知の制限がある（AWS CLIのケース）

また、そもそもどの通信が検査機器を経由しているのかは、PACファイルの設定によって決まります。仕組みは PACファイルとは？企業ネットワークにおけるプロキシ自動設定の仕組み で解説しています。

プロキシそのものの役割やVPNとの違いは プロキシサーバーとは？VPNとの違い をご覧ください。

導入する側が考えるべきこと

情報システム部門の立場では、CISAの結論がそのまま指針になります。

HTTPSインスペクション製品を使用する組織は、その製品が証明書チェーンを適切に検証し、警告やエラーをクライアントに伝えているかを確認すべきである。また導入を検討している組織は、導入前にその長所と短所を慎重に検討すべきである。（CISA）

導入するかどうかではなく、「導入した製品が正しく動いているか」を確認し続けることが求められています。クラウドを使う場合は、どこまでが自社の責任範囲かという整理も関わります（責任共有モデル）。

よくある質問

Q. 自分の会社でSSLインスペクションが使われているか調べる方法は？

ブラウザでHTTPSサイトを開き、証明書の発行者を確認してください。本来の認証局ではなく自社名や社内システム名が表示されていれば、SSLインスペクションが使われています。

Q. 会社に無断で回避してもよいですか？

やめてください。SSLインスペクションは情報漏えい対策として導入されていることが多く、回避行為は社内規定違反になりえます。

ツールが動かない場合は、情報システム部門に「このツールで社内CA証明書が必要」と相談するのが正しい手順です。

Q. すべての通信が復号されているのですか？

通常は除外設定があります。金融機関や医療関連など、法令やプライバシーの観点から復号すべきでない通信は対象外にするのが一般的です。どのURLが検査対象になるかは、PACファイルや機器のポリシーで決まります。

ただし復号される通信については技術的に中身が見える状態になるため、多くの企業では対象範囲・ログの取り扱い・閲覧できる担当者を規程で定めています。

Q. ゼロトラストを導入すれば不要になりますか？

ゼロトラストの考え方でも通信の検査は行われるため、SSLインスペクション自体がなくなるわけではありません。実施する場所が、社内のゲートウェイからクラウド側のサービスに移るという整理になります。

参考にした主な調査・資料

• HTTPS Interception Weakens TLS Security（Alert TA17-075A）｜CISA（米国サイバーセキュリティ・インフラストラクチャセキュリティ庁）
• The Risks of SSL Inspection｜CERT/CC（カーネギーメロン大学 ソフトウェア工学研究所）
• TLS暗号設定ガイドライン｜独立行政法人 情報処理推進機構（IPA）

※CISAの引用は原文（英語）からの抜粋で、和訳は本記事によるものです。製品の挙動や社内ポリシーは組織によって異なります。実際の設定変更や検証を行う際は、必ず情報システム部門にご確認ください。

まとめ

• HTTPS通信をいったん復号して検査し、企業の証明書で再暗号化する仕組み。CISAは「中間者攻撃を実行することで機能する」と表現している
• ブラウザでエラーが出ないのは企業の証明書がPCに事前登録されているため。開発ツールは独自の証明書ストアを持つのでエラーになる
• 導入目的は正当（暗号化された通信を検査してマルウェアを検知する）
• ただしCISAは、クライアントが独立して検証できなくなること、多くの製品が証明書チェーンを適切に検証していないこと、エラーがクライアントに伝わらないことを警告している
• 確認には badssl.com が使える（情報システム部門への事前相談を）
• 検証の無効化（–no-verify-ssl 等）を恒久化しない。社内CA証明書の追加が正しい対処

SSLインスペクションは、セキュリティのために、セキュリティの前提を一部手放す仕組みです。だからこそ公的機関は「導入するな」ではなく、「正しく動いているか確認せよ」と繰り返し述べています。

エラーの原因が分かれば、対処も、相談のしかたも変わります。