はじめに
目的
本書は「SSL代理証明書」について分かりやすく解説します。企業や組織のネットワークで使われることが多く、HTTPS通信を一時的に復号して検査するための仕組みを扱います。専門的な背景がなくても理解できるよう、具体例を交えて説明します。
対象読者
- 企業のIT担当者や管理者
- セキュリティ関連の初学者
- 社内システム導入を検討している方
専門用語は最小限にし、設定や注意点を順を追って説明します。
本章の内容
本章では本書の狙いと読み進め方を示します。以降の章で仕組み、設定上のポイント、類似用語との違いを順に扱います。例えば社内プロキシがHTTPSを検査する場合、どのように証明書を扱うかを具体的に示します。
注意点
代理証明書は便利ですが、プライバシーや信頼性に関わるため慎重に扱う必要があります。次章以降で技術的な仕組みや運用上の注意を丁寧に説明します。
SSL代理証明書とは
概要
SSL代理証明書は、社内のプロキシサーバーが外部サイトとのHTTPS通信を一旦復号（中身を読む）し、再び暗号化してクライアントに渡すために使う証明書です。外部サイトの証明書ではなく、プロキシが提示する証明書でクライアントとHTTPS接続が成立します。
どう使うか（具体例）
例えば会社のプロキシがメール添付やダウンロードをウイルス検査する場合、暗号化されたままでは中身を検査できません。そこでプロキシは一度暗号化を解除して検査し、問題なければ別の証明書で再暗号化して社員のPCに渡します。これにより安全性と業務上の監視を両立できます。
クライアント側の設定
代理証明書を使うには、社内でそのプロキシのルート証明書を社員の端末にインストールして信頼させます。インストールされていないとブラウザが警告を出し、通信ができません。
主な注意点
・プライバシーの観点で通信内容を社内で閲覧できる点に注意が必要です。
・証明書ピンニングや一部アプリは動作しない場合があります。
・内部CAの管理を適切に行わないと、セキュリティリスクが高まります。
仕組みの概要
以下では、先に挙げた4つの流れをわかりやすく説明します。専門用語は最小限にし、具体例を交えて順を追って解説します。
全体のイメージ
クライアント（あなたの端末）と本物のサイトの間に「代理人（プロキシ）」が入り、いったん通信を受け取ってから本物のサイトとやり取りします。代理人は社内で用意した“信頼された証明書”を使って、その場でそのサイト用の代理証明書を発行します。クライアントはあらかじめその社内証明書を信頼しているため、代理人と安全に通信できます。
ステップごとの簡単な説明
- クライアントが https://example.com にアクセスします。ブラウザは安全な接続を期待します。
- プロキシがその通信を受け取り、外部の example.com に対して本物のサーバー証明書でSSL接続を行います。つまりプロキシと本物のサイトが暗号化された回線を作ります。
- 同時にプロキシは社内のルート証明書を使って「example.com向け」の代理証明書をその場で作り、クライアントに提示します。例えると、代理人が相手の身分証を確認して、社内の印を押した身分証のコピーを渡すようなものです。
- クライアントはあらかじめインポートしてある社内のルート証明書を基に、代理証明書を正当とみなしてプロキシと暗号化された接続を確立します。したがってクライアントから見ると通常の安全な接続に見えます。
具体例での理解
たとえば銀行のサイトにアクセスすると、ブラウザは安全な鍵交換を期待します。プロキシが介在すると、あなたとプロキシ、プロキシと銀行サイトという2つの暗号化された通路ができます。プロキシは途中で暗号を復号して内容を検査でき、必要に応じてログを残したりフィルタリングしたりします。
注意点
社内ルート証明書は非常に強い権限を持つため厳重に管理する必要があります。もしこのルートが漏れると、同じ仕組みで外部通信を偽装される危険があります。しかし、正しく運用すれば企業内の安全対策として有効です。
必要な設定・ポイント
1) ルート証明書の配布と登録
社内独自CAやUTMが発行するルート証明書を、全クライアント端末の「信頼されたルート証明機関」に登録します。例：Windows環境ならグループポリシー（GPO）、モバイル端末ならMDM、少数台なら手動インストールを使います。Firefoxは独自の証明書ストアを使うので別途設定が必要です。
2) 中継装置の証明書設定
中継装置（プロキシ/UTM）に、復号・再暗号化で使う証明書と秘密鍵を正しく配置します。中継装置はクライアントに対して内部CAで発行したサーバー証明書を提示します。秘密鍵は厳重に保護してください。
3) 例外とプライバシー配慮
金融や医療など個人情報が含まれるサイトは検査対象から除外するリストを作成します。通信を復号するためプライバシーや法令順守（盗聴や検閲に抵触しないか）を必ず確認し、社内規程で利用目的や同意を明示します。
4) 運用・保守のポイント
CRL/OCSPの公開、時刻同期（NTP）、証明書の有効期限管理とロールオーバー手順を整えます。更新時にはクライアント側での再配布を忘れないでください。
5) テストと監査
導入前後にブラウザの警告確認、opensslなどでチェーン検証を行い、アクセスログと監査ログを定期的に確認します。ユーザーへの周知と問い合わせ窓口を用意すると運用が安定します。
類似用語との違い
公的なサーバー証明書
公的な認証局（例：Let’s Encryptや商用CA）が発行します。インターネット上の誰が見ても、そのドメインの正当なサーバーであることを示します。ブラウザはあらかじめ信頼されたルートを持っているため、警告なく接続できます。銀行やECサイトなど公開サービスで使います。
自己署名証明書（オレオレ証明書）
自分で作って自分で署名する証明書です。発行者が自分自身なので、他のクライアントは信頼しません。検証環境や開発でよく使います。ブラウザは警告を表示し、手動で信頼設定をしない限り安全とはみなしません。
代理証明書（SSL代理証明書）
プロキシがクライアントに提示する証明書で、背後にある実際のサーバーの代わりに振る舞います。企業内のプロキシが社内ルートCAで署名した証明書を配ることで成り立ちます。自己署名とは異なり、社内で信頼されたルートを使えば警告は出ません。外部の利用者には使えません。
見分け方と扱い方
ブラウザで証明書の「発行者（Issuer）」と「証明書チェーン」を確認してください。発行者が公的CAなら公開用、自己が発行者ならオレオレ、社内CA名なら代理証明書の可能性が高いです。したがって、用途に応じて正しい証明書を使い、社内でルートを配布する場合は慎重に管理してください。
