RBIProxy プライベート CA 要件
文書の目的
RBIProxyのHTTPS中継(MITM)署名に使用されるプライベートCAの技術要件を定義します。
この文書は顧客のPKI担当者CAを発行・伝達する際に参照します。
| 項目 | 内容 |
|---|---|
| 適用製品 | RBIProxy (Kubernetes デプロイ) |
| 後続文書 | 02. RBIProxy 사설 CA 적용 엔지니어 가이드 |
📌 要約 — 必ずご確認ください
- キーアルゴリズム: 現在のリリースはRSA 2048ビット以上これは必須です。ECDSAなどの他のアルゴリズムは動作が保証されていないため、RSAを使用してください。
- キー形式: PKCS#8 PEM プレーンテキスト必須 (
-----BEGIN PRIVATE KEY-----).- 推奨方法: 最も単純な**"専用自己署名ルートCA 1枚"**方式が推奨されます。Intermediate CA方式も可能ですが、4.5節のチェーン転送制約を必ず確認してください。
- 本CAの用途限定: RBIProxyのHTTPS中継署名専用で発行し、既存のPKI業務用CA（コード署名、メールなど）と分離して運用する必要があります。
1. 概要
1.1 背景
RBIProxyはユーザーのHTTPSトラフィックを中継(MITM)Remote Browser Isolation(RBI)サービスに渡します。
このプロセスでRBIProxyは目的のドメイン（例：www.example.comのサーバー証明書を動的に再発行するユーザーのブラウザに提供するために、再発行時に署名者(Issuer)として使用するCA証明書/秘密鍵 1対これが必要です。
基本提供CA（製品に含まれる）を使用せずに顧客のPKIを活用行いたい場合は、本書の要件を満たすCAを準備してください。
1.2 自己CAの適用が検討される場合
次のいずれかに該当する場合は、独自のCAの適用が必要です。
- 基本提供CAの使用に伴うブラウザ警告を削除したい場合
- 顧客別の証明書分離運用が内部セキュリティポリシー上必要な場合
- 既存の社内PKIシステムと統合管理が必要な場合
- 金融業・公共などの監査対応上、固有CAの使用が必要な場合
💡 PoCや単純なテスト段階では、別途作業なしに基本提供CAをそのまま使用できます。
1.3 動作構造 (要約)
- ユーザーPCが外部サイト（例：
https://www.example.com)でHTTPS接続を要求します。 - RBIProxyがリクエストを受け取り、サードパーティCAで該当ドメインのサーバー証明書を即時発行ユーザーのブラウザに渡します。
- ユーザーブラウザはプライベートRoot CAを信頼しているため、チェーン検証が通過しました。警告なし正常に処理されます。
- RBIProxyは実際の外部サイトにトラフィックを中継します。
※ このフローが動作するには、ユーザーのPCに信頼できるルート認証機関のプライベートルートCAに事前 登録されている必要があります（AD GPOなどを通じた配布）。
1.4 全体の進行手順
| ステップ | 主体 |
|---|---|
| 1. 本文書の検討およびCA発行方式の決定 | PKI担当者 |
| 2. CA証明書/秘密鍵の発行 | PKI担当者 |
| 3. ユーザーPCルートCAの配布 (GPOなど) | IT担当者 |
| 4. セキュリティチャネルを通じたファイル転送 | PKI担当者 → 構築担当者 |
| 5. RBIProxyに反映 | 構築担当者 |
| 6. 動作検証 | 両側共同 |
ℹ️ "構築担当者"はRBIProxyを運営中のKubernetes環境に直接作業する担当者を意味します。構築形態に応じて社内ITインフラ担当者、委託SIエンジニア、または製品供給者エンジニアのいずれかになります。本ドキュメント全体で同じ意味で使用されます。"
2. 前提条件
2.1 必要な環境
| 区分 | 要件 |
|---|---|
| プライベート Root CA | 社内独自のRoot CA（または内部PKI）がすでに運用中 |
| ユーザーPC配布体系 | すべての対象PCにプライベートRoot CAが「信頼されたルート認証機関」として配布されています（AD GPOなど）。 |
| デプロイ方法 | Windows システム証明書ストレージベース (Edge/Chrome/IE 参照) |
2.2 効果範囲
| ブラウザ/クライアント | サポート | 備考 |
|---|---|---|
| Microsoft Edge | ✅ | Windowsシステム証明書ストレージの使用 |
| Google Chrome | ✅ | Windowsシステム証明書ストレージの使用 |
| Internet Explorer | ✅ | Windowsシステム証明書ストレージの使用 |
| Firefox | ⚠️ 別途設定 | GPOでsecurity.enterprise_roots.enabled = trueまたは独自のTrustStoreに登録 |
| Java/.NETなどのアプリケーション | ⚠️ 別途対応 | 各ランタイムのTrustStoreに別途登録が必要です |
| macOS / Linux ターミナル | ⚠️ 別途対応 | 各OSの証明書ストアにRoot CAを登録する必要があります |
3. 提供するファイル (納品物)
次のファイルをセ キュアトランスミッションチャネル構築担当者に伝えてください。
| # | ファイル | 必須/選択 | フォーマット | 説明 |
|---|---|---|---|---|
| 1 | CA証明書（自己署名ルートまたは中間） | 必須 | PEM (.crt / .pem) | RBIProxyが署名用に使用するCA |
| 2 | CA 個人鍵 | 必須 | PKCS#8 PEM プレーンテキスト (.key / .pem) | 対応するプライベートキー |
| 3 | Intermediate チェーン (中間 CA たち) | 条件付き (Intermediate方式) | PEM バンドル | ルートと発行CAの間に他の中間CAがある場合はすべて含む（ルートを除く） |
| 4 | ルートCA公開証明書 | 必須 | PEM | 検証用。Self-Signed Root方式であれば #1と同じファイルでも問題ありません。 |
3.1 伝達形式の例
オプション A: 分離ファイル (推奨)
customer-ca.crt ← #1 (단일 또는 #1+#3 체인 번들)
customer-ca.key ← #2 (PKCS#8 평문)
customer-root-ca.crt ← #4 (검증용)
オプションB: 統合PEM
customer-ca-bundle.pem ← #1 + #2 + #3 모두 포함
customer-root-ca.crt ← #4 (검증용)
オプション C: PKCS#12 (.pfx)
customer-ca.pfx ← #1 + #2 + #3 통합 (암호화됨)
* 패스워드는 별도 채널로 전달
customer-root-ca.crt ← #4 (검증용)
ℹ️ RBIProxy ランタイムはPEMフォーマットを直接ロードします。PKCS#12で受け取った場合、構築担当者がOpenSSLを使用してPEM（cert + key）に変換して反映します。変換プロセス中に秘密鍵が平文状態で一時保管されるため、セキュリティ上**オプション A（分離ファイル）**が必要です。
3.2 セキュアトランスポートチャネ ル (推奨)
個人鍵が含まれているファイルは必ず以下の中1つ以上の方法に伝えてください。
| 方式 | 推奨レベル | 備考 |
|---|---|---|
| PKCS#12 + パスワード別チャンネル分離伝達 | ⭐⭐⭐ | ファイルはメール、パスワードは有線/SMS |
| 社内ファイル暗号化ソリューション | ⭐⭐⭐ | 保有している場合 |
| 暗号化USB + 対面伝達 | ⭐⭐ | オフラインでの配信が可能な場合 |
| S/MIME 暗号化メール | ⭐⭐ | 相互認証書の交換が必要 |
| 一般メール添付 (平文) | ❌ | 禁止 |
📌 伝達完了後顧客側で送信用の平文ファイルを即時廃棄してください。
3.3 キー形式の注意事項
プライベートキーは次の条件をすべて満たす必要があります。
| 項目 | 必須事項 |
|---|---|
| ラッピングフォーマット | PKCS#8 PEM (-----BEGIN PRIVATE KEY-----) |
| キーアルゴリズム | RSA 2048ビット以上(RSA 3072/4096 可能) |
| 暗号化の有無 | 平文(伝達チャネルで保護) |
PKCS#8 の例 (推奨)
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASC...
-----END PRIVATE KEY-----
PKCS#1 (-----BEGIN RSA PRIVATE KEY-----) を保有している場合 — 変換必須
openssl pkcs8 -topk8 -nocrypt \
-in customer-ca-pkcs1.key \
-out customer-ca-pkcs8.key
暗号化されたPEM(-----BEGIN ENCRYPTED PRIVATE KEY-----) を保有している場合 — 復号化必須
openssl pkcs8 -in customer-ca-encrypted.key -out customer-ca-plain.key
# 패스워드 입력 후 평문 PKCS#8로 저장됨
⚠️ 変換/復号化された平文の個人鍵ファイルはセキュアトランスミッションチャネル(3.2節を参照)でお伝えし、伝達完了後に原本ファイルを即座に廃棄してください。
4. CA証明書の必須要件 (X.509拡張)
CA証明書は次の要件をすべて満たす必要があります。既存の他の用途（コード署名、メール保護など）で発行されたCAを再利用することは推奨されません。**"TLSサーバー証明書発行用CA"**ロ新規発行する必要があります。(Self-Signed Root / Intermediate すべて同様の要件)
4.1 X.509 拡張フィールドの必須要件
| 拡張フィールド | 必須値 | 備考 |
|---|---|---|
| Basic Constraints | CA:TRUE | 必須— CA証明書であることを明示 |
| Key Usage | keyCertSign, cRLSign | 必須— 一部のブラウザは未設定の場合に警告を表示します |
| Extended Key Usage (EKU) | serverAuth含む | 必須— TLSサーバー証明書発行の用途の明示 |
| Name Constraints | 未設定が必要 | 設定時に該当ドメインのみ中継可能 |
| Path Length Constraint | pathlen >= 0 | end-entity 発行可能 |
ℹ️ Key Usage / Extended Key Usageは最新のブラウザ（特にChrome系）で徐々に厳格に検証する傾向があります。明示的に設定すれば互換性の観点から安全です。
4.2 キー/アルゴリズムの必須要件
| 項目 | 必須事項 |
|---|---|
| キータイプ | RSA 2048ビット以上(3072 / 4096 可能) |
| 署名アルゴリズム | SHA-256 以上(SHA-1は使用できません) |
| 有効期限 | 3年以上必要 |
ℹ️ ECDSAなどの他のアルゴリズムは現在のリリースでは動作が保証されていないためRSAの使用が必須です。
4.3 OpenSSL セルフチェック (伝達前)
伝達する前に、以下のコマンドで要件の満たされているか確認できます。
openssl x509 -in customer-ca.crt -noout -text
出力で次の項目を確認:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication
4.4 チェーン検証
openssl verify -CAfile customer-root-ca.crt customer-ca.crt
# 출력: customer-ca.crt: OK
4.5 中間CA運用時のチェーン転送制約
⚠️ このセクションはIntermediate CA方式で運用する際に必ず知っておくべき制約です。Self-Signed Root CA 1章の方式を選択した場合は該当なし。
現象
現在のRBIProxyはユーザーブラウザに対して動的に発行されたleaf証明書を送信しますが、その上の段階のIntermediate CAを一緒に送信しないことができます。.
影響
ユーザーPCにルートCAのみインストールされている場合、ブラウザはleaf → (빠진 Intermediate) → Rootチェーンを完成できなかったNET::ERR_CERT_AUTHORITY_INVALIDなどの警告を表示できます。
解決方法 — 下記のAまたはBのいずれかを選択してください
A. (推奨) 専用の自己署名ルートCAを使用
- チェーンの長さが1（ルート → 葉）であるため、中間段階自体が存在しない → 本制約は該当しない
- 既存のPKIと分離 された**"RBIProxy専用Root CA 1章"**を新規発行して伝達
- ユーザーPCには該当するRoot CAのみがTrusted Rootに配布されます。
B. 中間CA方式を採用する場合
- ユーザーPCにIntermediate CAまで必ず配布
- Windows: "中間認証機関(Intermediate Certification Authorities)" 中間CAをリポジトリにデプロイする
- GPO配布時のRoot CA配布と同一のポリシーに共に含む必要
- 2段以上のIntermediateチェーンの場合は中間ステップすべて配布
判定マトリックス
| 受け取ったCAの種類 | ユーザーPCに配布する証明書 | ブラウザの動作 |
|---|---|---|
| 専用自己署名ルートCA | ルートCAのみ | ✅ 正常 |
| Intermediate CA (1段) | Root CA + Intermediate CA | ✅ 正常 |
| 中級CA (1段) | ルートCAのみ | ❌ 警告が発生する可能性 |
| 中級CA (2段以上) | Root CA + すべての中間CA | ✅ 正常 |
4.6 キー形式の確認
head -1 customer-ca.key
# "-----BEGIN PRIVATE KEY-----" ← PKCS#8 (필수)
# "-----BEGIN RSA PRIVATE KEY-----" ← PKCS#1 (변환 필수)
# "-----BEGIN ENCRYPTED PRIVATE KEY-----" ← 암호화됨 (복호화 필수)
キーアルゴリズムの確認
openssl pkey -in customer-ca.key -noout -text | head -2
# "RSA Private-Key: (2048 bit, 2 primes)" ← 필수
# "ED25519 Private-Key:" 또는 EC 표시 → RSA로 재발급 필요
5. ユーザーPC環境要件
5.1 ルートCAの配布状況の確認 (Windows)
# PowerShell (관리자 권한)
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*<사내 CA명>*" }
またはGUI:certlm.msc → 信頼できるルート認証機関 > 証明書サーバーにおけるプライベート Root CA の存在確認。
5.2 Firefoxを使用する際の追加設定（任意）
Firefoxは基本的に独自のTrustStoreを使用します。Windowsシステムストレージを信頼するにはGPOまたはpolicies.json次の設定をデプロイ:
{
"policies": {
"Certificates": {
"ImportEnterpriseRoots": true
}
}
}
またはabout:config → security.enterprise_roots.enabled = true
5.3 macOS / Linux ターミナルサポート
| OS | ルートCAの配布方法 |
|---|---|
| macOS | Keychain Access→ システムキーチェーンにRoot CAを追加 → 信頼設定「常に信頼」 |
| Ubuntu/Debian | /usr/local/share/ca-certificates/にコピー後sudo update-ca-certificates |
| RHEL/CentOS | /etc/pki/ca-trust/source/anchors/にコピー後sudo update-ca-trust |
6. セキュリティ/運用の考慮事項
6.1 プライベートキーの保護
- 渡されたCA秘密鍵はKubernetes Secretに保存され、RBIProxy Podに読み取り専用ボリュームにマウントされます。
- Secretアクセス権限は、該当のネームスペースの管理者によって最小化なります。
- 必要に応じてKMS/HSMの連携を別途検討することができます。
6.2 監査ログ
現在の動作
- RBIProxyは動的に発行されたleaf証明書の件別発行履歴は別途ログに残しません。(パフォーマンスの考慮)。
- ただし、次のカテゴリのログが記録されます。
- アクセスログ: ユーザーが接続した外部ドメイン (CONNECTログ)
- CAロードイベント: Pod起動時CA秘密鍵のロード成功/失敗
- シークレットの変更: Kubernetes 監査ログ (クラスター レベル)
厳格な監査要件がある場合
発行されたleaf証明書のシリアル番号、発行時刻、対象ドメインなどを全量記録しなければならないなど、別途監査要件がある場合、構築担当者を通じて別途協議リクエストしてください。
6.3 証明書の交換 (ロールオーバー)
- CAの有効期限最低90日前新規発行および伝達が必要です。
- 交換はKubernetes Secretの再生成とPodの再起動のみで反映可能です（短いセッションの切断を伴います）。
6.4 廃棄 (Revocation)
- RBIProxyが動的に発行するleaf証明書にはCRL/OCSP URLが含まれていません(一時発行の特性)。
- CA自体の廃棄履歴は社内CRL/OCSPシステムに記録されます。
6.5 運用中のCA変更時
- CAの交換は短いセッションの切断(Podの再起動、通常1分以内)を伴います。
- 大規模なユーザーへの影響を最小限に抑えるために業務外の時間帯変更が必要です 。
- 変更前後最低30日以前のCAを廃棄せずに保管してください（ロールバックのため）。
7. チェックリスト (PKI担当者確認用)
送信前に以下の項目を確認してください。
共通 (すべての方式)
-
CA方式の決定: 自己署名ルートCA専用または中間CA
-
"TLSサーバー証明書発行用" CAを新規発行
-
Basic Constraints: CA:TRUE -
Key Usage: keyCertSign, cRLSign（必須） -
Extended Key Usage: serverAuth含む（必須） -
Name Constraints 未設定 (または RBI 中継対象ドメインすべてを含む)
-
キーアルゴリズム = RSA 2048ビット以上
-
SHA-256以上の署名
-
有効期限 3年以上
個人鍵フォーマット
-
個人鍵がPKCS#8 PEMフォーマット (
-----BEGIN PRIVATE KEY-----) -
個人鍵が平文(暗号化されていません)
ユーザーPCの配布
-
自己署名ルートCA方式: 対象のすべてのユーザーPCのルートCAが信頼できるルート認証機関にデプロイ完了
-
中間CA方式: ルートCAが信頼できるルート認証機関中間CAが**"中間認証機関"**と共に配布完了 (4.5節参照)
伝達準備
-
openssl verify -CAfile <Root> <Intermediate>検証 OK (Intermediate方式) -
ルートCA公開証明書（検証用）を同梱
-
セキュアトランスポートチャネル（3.2節参照）準備完了
-
伝達用平文ファイルの廃棄時点の事前決定
8. FAQ
Q1. ルートCAの秘密鍵を渡す必要がありますか？
A. いいえ。Root CAの個人鍵は社内の最高のセキュリティ資産であるため、 渡さないでください。専用Self-Signed Root CAを新規発行するか、既存のRoot CAの下にIntermediate CAを新規発行してお渡しください。
Q2. 既存の内部ウェブサーバー用の証明書をそのまま使用できますか？
A. 不可です。一般サーバー証明書(end-entity)はCA:FALSEは発行されておらず、下位証明書の署名権限がありません。CA証明書を新たに発行する必要があります。
Q3. セルフサインCAと中間CAのどちらを選択すべきですか？
A. 専用自己署名ルートCA 1章を推奨します。Intermediate CA方式は、ユーザーPCにIntermediateまで別途配布する手間があります（4.5節参照）。既存の内部PKI統合監査など特別な要求がない場合、Self-Signed方式がシンプルで確実です。
Q4. ECDSAキーで発行してもいいですか？
A. 現在のリリースでは動作が保証されていないためRSA 2048ビット以上に発行してください。
Q5. 有効期限が短いCA（1年など）も可能ですか？
A. 技術的には可能ですが、毎年再伝達/再配布の負担が発生します。3年以上これが必要です。
Q6. Name Constraintsで制限されたCAを与えてもよいですか？
A. 可能ですが、該当のName Constraintに含まれていないドメインにRBIProxyを通じて接続する際にブラウザ警告が発生します。RBI中継対象ドメインの範囲を正確に合意した後に設定してください。
Q7. 個人鍵フォーマットがPKCS#1 (-----BEGIN RSA PRIVATE KEY-----)ですが、そのまま送ってもいいですか？
A. 使用できません。openssl pkcs8 -topk8 -nocrypt コマンドに変換して伝達する必要があります（3.3節を参照）。
Q8. PKCS#12(.pfx) ファイルだけがあります。このまま送ってもいいですか？
A. 伝達可能です。ただし、RBIProxyランタイムがPEMを使用しているため、構築担当者が内部でPEMに変換して反映します。セキュリティの観点から最初から**分離されたPEMファイル（オプションA）**に伝達する必要があります。
Q9. 証明書が期限切れになるとサービスはどうなりますか？
A. 有効期限が切れたCAをそのままにしておくと、新しいセッションを作成する際にブラウザの警告が発生し、RBIサービスを正常に利用できなくなる可能性があります。満了90日前から更新の準備してください。
Q10. 異なる環境（運用/ステージング）でそれぞれ異なるCAを使用できますか？
A. 可能です。Kubernetes Secretを環境ごとに分けて作成し、各環境のDeploymentに別途マウントすればよいです。運用/ステージングのCAを分けることで、ステージングのCAが漏洩しても運用に影響がないため、分離が必要です。