【図解】I-FILTERのSSLデコードの仕組みを、証明書の基礎から完全に理解する
【図解】I-FILTERのSSLデコードの仕組みを、証明書の基礎から完全に理解する
社内のプロキシサーバー（I-FILTER）の移行や運用をしていると、必ず直面するのが**「証明書」**の問題です。
「なぜ警告画面が出るのか？」「どの端末にどの証明書を入れればいいのか？」
これらを正しく理解するために、一般的な通信からI-FILTER特有の動きまでを整理しました。
1. 基本：普通のWebサイト（Google）との通信
まずは、プロキシを通さない、一般的なPCとWebサイト（例：Google）の通信についてです。
この仕組みは**「パスポートと入国審査」**に例えると分かりやすくなります。
登場人物
| 役割 | 例 | 説明 |
|---|---|---|
| Webサーバー | 旅行者 | |
| クライアント | PC | 入国審査官 |
| 認証局 | DigiCertなど | 政府（信頼できる第三者機関） |
仕組み
ステップ1：基盤（事前準備）
- PC（WindowsやブラウザOSに）には、あらかじめ**「信頼できる認証局のリスト（政府リスト）」**が最初からインストールされています。
ステップ2：提示
- Googleは「私はGoogleです」と、認証局に署名してもらった**サーバー証明書（パスポート）**をPCに提示します。
ステップ3：検証
- PCは、提示された証明書の発行元を見ます。
- 「ふむ、これは『DigiCert』が発行しているな。私のリストにも載っている信頼できる機関だ」と判断します。
ステップ4：通信確立
- 信頼が確認できれば、暗号化通信が始まります。
2. 応用：社内Webサイト（オレオレ認証局）との通信
次に、社内で構築したWebサイトなど、**自己署名証明書（オレオレ証明書）**を使っているケースです。
仕組み（問題点）
社内サーバー管理者が「自分で認証局を立てて、自分でサーバー証明書を発行」しています。いわば**「手作りのパスポート」**です。
ステップ1：提示
- 社内Webサーバーは「手作りの証明書」をPCに提示します。
ステップ2：検証（エラー）
- PCは発行元を見ますが、「こんな認証局（社内の管理者）なんて知らない！リストに載っていない！」となり、セキュリティ警告を表示して通信をブロックします。
❌ セキュリティ警告
「このサイトのセキュリティ証明書は信頼できません」
解決策
PCに「この手作りパスポートの発行元（社内認証局）は信頼していいよ」と教えてあげる必要があります。
必須作業
- 社内認証局の**ルート証明書（CA証明書）**を取得
- クライアントPCの「信頼されたルート証明機関」にインポート
これを行うことで、Googleのときと同じように「ああ、これは知っている発行元（社内管理者）だね」となり、通信が可能になります。
3. 実践：I-FILTERを経由した通信（SSLデコード）
ここからが本題です。I-FILTERがHTTPS通信の中身をチェック（SSLデコード）する場合、通信は以下の2つの区間に分断されます。
[PC] <---(区間B)---> [I-FILTER] <---(区間A)---> [Webサーバー]
このとき、I-FILTERは「仲介者」として特殊な動きをします。
区間B：I-FILTER ⇔ PC（なりすましと偽装）
I-FILTERは通信の中身を見るために、Webサーバーになりすまします。
偽装
- I-FILTERは、アクセス先に合わせてその場で「偽の証明書」を動的に作成します。
- 例：Googleへのアクセスなら、Google名義の偽証明書を作成
署名
- その偽証明書に、I-FILTER自身の秘密鍵（
default_ca）で署名をしてPCに渡します。
検証
- そのままだとPCは「I-FILTERなんて知らない発行元だ！」と警告を出します。
【必須作業】
I-FILTERのルート証明書である default_ca.cer を、クライアントPCに配布・インストールしておく必要があります。これにより、PCはI-FILTERが偽造した証明書を「正規のもの」として受け入れます。
区間A：I-FILTER ⇔ Webサーバー（I-FILTERがクライアントになる）
ここが見落とされがちなポイントです。Webサーバー側から見ると、**「I-FILTERサーバー」こそがWeb閲覧者（クライアント）**になります。
接続先がGoogleの場合
- I-FILTERサーバー（Windows OS）はDigiCertなどを知っているので問題ありません。
- 通信は正常に確立されます。
接続先が社内Webサイト（オレオレ証明書）の場合
- I-FILTERサーバー自身が「社内認証局」を知らないと、I-FILTERがWebサイトへの接続を拒否してしまいます。
- Webサーバー側から見ると、「不正な証明書を提示してくるクライアント」として判定されます。
【必須作業】
I-FILTERがインストールされているサーバー自身の証明書ストアに、接続先（社内Web）のルート証明書をインストールする必要があります。
4. まとめ：誰が誰を信頼すべきか
I-FILTER経由で社内Webサイトを見る場合、双方向の信頼関係が必要です。
| 通信区間 | クライアント役 | サーバー役 | 必要な証明書 | インストール場所 |
|---|---|---|---|---|
| PC ⇔ I-FILTER | PC | I-FILTER（偽装） |
default_ca.cer（I-FILTERのCA証明書） |
クライアントPC |
| I-FILTER ⇔ Web | I-FILTER | 社内Web | 社内WebのCA証明書 （オレオレCAのルート証明書） |
I-FILTERサーバー |
フロー図
【通常のWebアクセス（Google）】
PC ──┐
│ default_ca.cer Google
│ インストール済み ↓
│ ✓信頼される Google配下の正規CA
I-FILTER────→ Webサーバー
│
└─→ DigiCert等（Windows OSに認識済み）
【社内Webアクセス（I-FILTER経由）】
PC ──┐
│ default_ca.cer ✓ 社内Web
│ インストール済み ↓
│ ✓信頼される 社内CA（オレオレ）
I-FILTER────→ Webサーバー
│
└─→ 社内CAをインストール必須
5. トラブルシューティング用チェックリスト
証明書エラーが発生したときは、以下のチェックリストで原因を特定します。
クライアント側エラーの場合
以下の症状が出ているとき：
- PCでブラウザが警告画面を表示
- 「セキュリティ証明書が信頼できない」というメッセージ
チェック項目
-
クライアントPCに
default_ca.cerはインストールされているか？ -
default_ca.cerの有効期限は切れていないか？ -
配布している
default_ca.cerは、現在のI-FILTER管理画面からダウンロードしたものと一致しているか？ - PCを再起動して、証明書ストアがリロードされたか？
- ブラウザのキャッシュをクリアしたか？
対処方法
- I-FILTER管理画面から最新の
default_ca.cerをダウンロード - 以下の場所にインストール
- Windows: Windows証明書ストア → 「信頼されたルート証明機関」
- macOS: キーチェーン → システム → 「常に信頼」
-
Linux:
/etc/ssl/certs/または各ディストリビューション依存
- PCを再起動
I-FILTER側エラーの場合
以下の症状が出ているとき：
- PCから見てアクセスがタイムアウト
- I-FILTERのログに「Certificate verification failed」が出ている
チェック項目
- （社内Web接続時）I-FILTERサーバー自身に、社内Webのルート証明書はインストールされているか？
- I-FILTERサーバーの証明書ストアをリロードしたか？
- I-FILTERサービスを再起動したか？
- 社内WebのCA証明書の有効期限は切れていないか？
対処方法
- 社内Web認証局のルート証明書を取得
- I-FILTERサーバー（Windows OS）の証明書ストアにインストール
- Windows証明書ストア → 「信頼されたルート証明機関」に配置
- I-FILTERサービスを再起動
# PowerShellでの確認例
Get-ChildItem Cert:\LocalMachine\Root | Where-Object {$_.Subject -like "*社内CA*"}
6. デバッグコマンド集
Windows証明書ストアの確認
# ルート証明書一覧表示
Get-ChildItem Cert:\LocalMachine\Root | Format-List Subject, Thumbprint, NotAfter
# 特定の証明書を検索
Get-ChildItem Cert:\LocalMachine\Root | Where-Object {$_.Subject -like "*default*"}
証明書のインストール
# ローカルマシンのルート証明書ストアにインポート
Import-Certificate -FilePath "C:\path\to\default_ca.cer" -CertStoreLocation "Cert:\LocalMachine\Root"
# 現在のユーザーのルート証明書ストアにインポート
Import-Certificate -FilePath "C:\path\to\default_ca.cer" -CertStoreLocation "Cert:\CurrentUser\Root"
OpenSSLでの証明書確認
# 証明書の内容を確認
openssl x509 -in default_ca.cer -text -noout
# 証明書の有効期限を確認
openssl x509 -in default_ca.cer -noout -dates
# 証明書のサムプリント（フィンガープリント）を確認
openssl x509 -in default_ca.cer -noout -fingerprint
I-FILTERログの確認
# I-FILTER固有のエラーログを確認
# ※ ログ位置はインストール環境に依存
# 同期エラーや証明書エラーを検索
grep -i "certificate\|verification\|ssl" /var/log/i-filter/*
7. よくある質問（FAQ）
Q1. default_ca.cerの有効期限が近づいている場合は？
A: I-FILTER管理画面から新しい default_ca.cer をダウンロードして、全クライアントPCに配布してください。古い証明書は削除し、新しい証明書に置き換えます。この作業は、有効期限切れ前に完了させることが重要です。
Q2. 社内WebのCA証明書をI-FILTERに配布する最良の方法は？
A: 以下の方法が推奨されます：
- グループポリシーを使用して配布（Active Directory環境）
- **Mobile Device Management (MDM)**ツールを使用
- 構成管理ツール（Ansible、Puppetなど）で一括配布
- 最終手段としてマニュアル配布
Q3. I-FILTER経由でのWebアクセスが遅い場合、証明書が原因の可能性は？
A: 可能性は低いですが、完全には否定できません。以下を確認してください：
- I-FILTERのCPU使用率は高いか？（SSL/TLSデコードは計算量が多い）
- ディスク I/Oは高いか？
- ネットワーク帯域幅は飽和していないか？
証明書関連のエラーではなく、通信が正常に確立されているのに遅い場合は、ハードウェアスペックや設定を見直してください。
Q4. Linux上でI-FILTERを実行している場合、証明書の配置場所は異なるか？
A: はい、異なります。一般的には以下の場所に配置します：
-
/etc/ssl/certs/- CA証明書ディレクトリ -
/etc/pki/ca-trust/extracted/- CentOS/RHEL系
ディストリビューション固有のコマンドで配置してください：
# Debian/Ubuntu系
sudo update-ca-certificates
# CentOS/RHEL系
sudo update-ca-trust
# 手動配置の場合
sudo cp default_ca.cer /etc/ssl/certs/
sudo update-ca-certificates --fresh
8. まとめ：完全な理解へ
この仕組みさえ理解していれば、証明書エラーが出たときに「どの区間で信頼関係が結べていないのか」をすぐに特定できるようになります。
| 状態 | 原因 | 解決策 |
|---|---|---|
| PCでセキュリティ警告が表示 |
default_ca.cerがPCにない、または期限切れ |
PCに最新のdefault_ca.cerをインストール |
| アクセスがタイムアウト | I-FILTERが社内Webの証明書を信頼していない | I-FILTERサーバーに社内CA証明書をインストール |
| 間欠的なエラーが発生 | 証明書ストアのリロードされていない | サービス再起動またはOS再起動 |
| 特定のWebサイトだけエラー | そのサイトの中間CA証明書がない | 中間CA証明書も合わせてインストール |
運用のコツ
-
定期的な監視: 全クライアントPCの
default_ca.cerインストール状況を把握する - 事前更新: 証明書の有効期限が切れる30日前には、新しい証明書を配布開始する
- ドキュメント化: 社内ナレッジベースに配置手順を記載し、サポート負荷を削減する
- ログ監視: I-FILTERのログから証明書エラーを定期的にチェックする
これで、I-FILTERの証明書運用に必要な知識がすべて揃いました。社内運用で直面する様々な課題に対応できるようになるはずです。
Discussion