AWS Private CA v2.0 完全ガイド 2026

初心者から実務者向けの包括的解説

AWS Private CA（Certificate Authority） は、FIPS 140-2/140-3 認証 の企業向けマネージド PKI（公開鍵基盤）であり、内部サービス・IoT デバイス・マイクロサービス間通信向けのプライベート証明書を自動発行・管理します。オンプレミス CA のような運用負荷（バックアップ・HA・CRL 管理）を排除しながら、顧客が鍵を完全制御できるセキュリティを実現します。本ドキュメントは、Private CA のアーキテクチャ・階層型 CA 構成・OCSP・CRL・コンプライアンス・2026 年動向を体系的に解説する完全ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています：

• 初心者向け： Private CA とは何か、Public CA との違いを学びたい方
• セキュリティアーキテクト向け： 階層型 CA 構成・信頼チェーン・コンプライアンス要件対応
• DevOps・SRE 向け： ECS/EKS での mTLS・IoT デバイス認証・証明書ライフサイクル管理
• 開発者向け： PKCS#10 CSR 生成・証明書発行 API・エクスポート・統合実装
• 意思決定者向け： HashiCorp Vault・Smallstep CA・Microsoft AD CS との比較

2026 年の Private CA エコシステム

• ML-DSA（量子耐性署名）対応： Post-Quantum Cryptography サポート
• External Key Store（XKS）統合： CloudHSM・オンプレ HSM での鍵管理
• Kubernetes 統合深化： EKS での ACME サポート
• Self-signed vs ACM Integration： ハイブリッド PKI 構成の簡素化
• CRL・OCSP 自動化： 動的な失効管理

目次

1. 概要
2. Private CA が解決する課題
3. 主な特徴
4. アーキテクチャ
5. Root CA と Subordinate CA
6. 信頼チェーン・階層構成
7. 証明書タイプ・用途
8. ACM との連携
9. 主要ユースケース
10. CSR・証明書発行フロー
11. CRL・OCSP・失効管理
12. 設定・操作の具体例
13. ECS/EKS 統合
14. IoT デバイス認証
15. コード署名
16. External Key Store（XKS）
17. バックアップ・災害復旧
18. セキュリティ・監査
19. トラブルシューティング
20. 類似サービス比較
21. ベストプラクティス
22. 2025-2026 最新動向
23. 学習リソース
24. 実装例・チェックリスト
25. まとめ

概要

初心者向けメモ： Private CA は「自社専用の認証局（銀行の支店のような信頼拠点）」です。パブリック CA（Let’s Encrypt・DigiCert）はインターネット全体が信頼している（ブラウザに組み込まれた証明書）が、Private CA はあなたの組織内だけで信頼されます。従来、自社で CA を運用するには Linux サーバーで OpenSSL を管理する必要がありましたが、AWS Private CA はこれを マネージドで提供 し、高可用性・監査ログ・自動バックアップが組み込まれます。

AWS Private CA は以下を実現するマネージド PKI サービスです：

Private CA が解決する課題

1. 社内 PKI 構築・運用の複雑性

課題：

• OpenSSL・Apache Directory Server での自前 CA 運用は専門知識が必須
• バージョンアップ・セキュリティパッチ・バックアップの手間
• HA 構成・災害復旧・CRL 管理が複雑
• CA 侵害時の対応（Root 秘密鍵保護）に高度なセキュリティが必要

Private CA の解決：

従来（オンプレミス CA）:
  CA 専任者 → サーバー管理 → バージョン更新 → セキュリティパッチ → バックアップ → CRL管理
  工数: 月間 20-40 時間

Private CA:
  AWS マネージド → 運用完全委譲 → 自動バックアップ → FIPS 140-2 認証
  工数: 月間 2-5 時間（監視のみ）

2. 内部通信の TLS 化（mTLS）

課題：

• マイクロサービス間通信を保護したいが、証明書配布・更新が手動
• 各サービスで秘密鍵管理が分散し、キーローテーション管理が困難
• サービス間認証の信頼性が低い

Private CA の解決：

mTLS 通信の完全自動化:
  1. サービス A が CSR（証明書署名要求）を生成
  2. Private CA が自動署名・証明書を発行
  3. サービス B も同様に証明書を取得
  4. 両サービスが相互の証明書を検証（相互 TLS）
  5. 信頼された通信チャネル成立

3. IoT デバイスの大量認証

課題：

• 製造段階で個体識別用の証明書を付与したいが、手動発行は困難
• デバイス秘密鍵が流出しないよう Secure Element に保管する必要
• デバイス数が増加すると証明書管理が爆発

Private CA の解決：

• IoT デバイス自動認証:
• 製造ライン → デバイスごとに CSR 生成 → Private CA が自動発行 → Secure Element に保管
• スケール: 月間数百万デバイスまで対応

4. 規制要件（FIPS 140-3・PCI-DSS）

課題：

• 金融機関・医療機関は「政府認定の暗号化」が必須（FIPS 140-3）
• オンプレ CA では Level 3 認証を取得困難
• 定期的なセキュリティ監査が必要

Private CA の解決：

コンプライアンス自動満足:
  FIPS 140-2 Level 3 認証済み HSM
  ↓
  キーは AWS managed HSM 内に閉じ込め（顧客アクセス不可）
  ↓
  CloudTrail で全操作を監査ログ
  ↓
  コンプライアンスレポート自動生成

主な特徴

1. Root CA と Subordinate CA の分離

Root CA:
  - セキュリティが最高の状態
  - オフライン保管も可能
  - 新規 Subordinate CA への署名だけ実施
  - 日常の証明書発行には使用しない

Subordinate CA:
  - 日常の証明書発行を担当
  - Root CA より秘密鍵が侵害されやすい環境でも耐える
  - 侵害時は Subordinate CA だけを廃止可能（Root 秘密鍵は無傷）
  - 複数の Subordinate CA を並列構成可能（ロードバランシング・地理的分散）

メリット:
  ✅ Root 秘密鍵の侵害リスク低減
  ✅ 運用の柔軟性（Subordinate だけ更新可能）
  ✅ 規制要件への対応

2. FIPS 140-2/140-3 認証

FIPS 140（Federal Information Processing Standard）:
  Level 1: 基本的な暗号化モジュール
  Level 2: 改ざん検出・ロール・認証
  Level 3: 物理セキュリティ・環境監視・リモートアクセス制限（←AWS Private CA対応）
  Level 4: 高度な物理セキュリティ・多層防御

AWS Private CA は Level 3 認証済み
  → 金融機関・医療機関・政府向け要件を満足

3. Key Wrapping と Customer Key

AWS Managed:
  - AWS がキーマテリアルを HSM 内で管理
  - 顧客は秘密鍵にアクセス不可

External Key Store（XKS）:
  - CloudHSM で顧客が鍵を完全制御
  - AWS も物理的にアクセス不可
  - より高度なコンプライアンス要件対応

4. 動的失効管理（CRL・OCSP）

CRL（Certificate Revocation List）:
  - 失効証明書のリストを定期配布
  - クライアントが定期的にダウンロード
  - ネットワークが大規模時に効率的

OCSP（Online Certificate Status Protocol）:
  - リアルタイム失効確認（クライアント → Private CA）
  - レスポンスキャッシュで高速化
  - ネットワーク通信量削減

Private CA での実装:
  自動 OCSP レスポンダー
  ↓
  クライアントがリアルタイム確認
  ↓
  失効証明書は即座に検出

アーキテクチャ

Root CA → Subordinate CA → End-Entity Cert（階層構成）

┌─────────────────────────────────────────────────────────────┐
│ Root CA（セキュアに保管）                                    │
│ CN=Company Root CA                                           │
│ 秘密鍵: オンラインのみ / オフライン保管も可能               │
│ 職務: Subordinate CA 証明書に署名する                       │
└────────────────────┬────────────────────────────────────────┘
                     │
         ┌───────────┴──────────┐
         │                      │
┌────────▼──────────┐  ┌──────▼──────────┐
│ Subordinate CA 1  │  │ Subordinate CA 2 │
│ 東京DC            │  │ 大阪DC           │
│ CN=Issuing CA JP  │  │ CN=Issuing CA JP │
│ 職務: End-entity  │  │ 職務: End-entity │
│ 証明書発行        │  │ 証明書発行      │
└────────┬──────────┘  └──────┬──────────┘
         │                      │
    ┌────▼────┐          ┌─────▼────┐
    │Service A │          │ Service B │
    │Cert      │          │Cert       │
    │(mTLS)    │          │(mTLS)     │
    └──────────┘          └───────────┘

信頼チェーン検証フロー

クライアント（Service B）が Server（Service A）に接続:

1. Service A: サーバー証明書を提示
   CN=service-a.internal
   発行者: Subordinate CA 1
   署名: (秘密鍵で署名)

2. クライアント: サーバー証明書の署名を Subordinate CA 1 の公開鍵で検証
   → 検証成功

3. クライアント: Subordinate CA 1 証明書の署名を Root CA の公開鍵で検証
   → 検証成功

4. クライアント: Root CA 証明書が信頼鍵ストアに登録されているか確認
   → 登録済み（CA 証明書として事前配布）

5. 信頼チェーン完成 → mTLS 通信成立

Root CA と Subordinate CA

Root CA の特性

セキュリティ:
  - 最高レベルの秘密鍵保護
  - AWS managed HSM での暗号化保管
  - CloudTrail で全操作監査
  - キーローテーション（年単位）

職務:
  - Subordinate CA 証明書の署名
  - 日常の end-entity 証明書発行には使用しない

有効期限:
  - 10-20 年（非常に長い）
  - インスタンスは常駐（オンライン・オフラインの切り替え可能）

侵害対策:
  - Subordinate CA だけ廃止すれば復旧可能
  - Root 秘密鍵は無傷のままチェーンが機能

Subordinate CA の特性

セキュリティ:
  - Root より低いセキュリティレベルでも耐える
  - CloudHSM での顧客管理鍵も可能

職務:
  - End-entity 証明書の日常発行
  - mTLS・IoT・コード署名等用途別に複数可能

有効期限:
  - 3-10 年（Rootより短い）
  - インスタンスは常時稼働

運用:
  - ロードバランシング（複数 Subordinate CA で分散）
  - 地理的分散（リージョン別 CA）
  - 目的別専用化（mTLS 用・IoT 用・コード署名用）

侵害対策:
  - 侵害 Subordinate CA だけ廃止
  - 他の Subordinate CA は継続稼働
  - Root CA は維持（新 Subordinate CA に署名）

複数 Subordinate CA の構成例

┌─────────────────────────────────────────────────┐
│ Root CA（非常に安全）                           │
└────────────────┬────────────────────────────────┘
                 │
        ┌────────┼────────────────┬────────┐
        │        │                │        │
        ▼        ▼                ▼        ▼
   ┌────────┐┌────────┐┌──────────┐┌──────────┐
   │mTLS用 ││IoT用   ││Code Sign ││Test用    │
   │Issuing││Issuing││Issuing   ││Issuing   │
   │CA     ││CA     ││CA        ││CA        │
   └────────┘└────────┘└──────────┘└──────────┘
        │        │        │            │
        │        │        │            │
   ┌────▼──┐ ┌──▼────┐┌──▼──────┐┌───▼──────┐
   │Service││Devices││Lambda   ││Testing   │
   │Certs  ││Certs  ││Code Sign││Certs     │
   └───────┘ └───────┘└─────────┘└──────────┘

メリット:
  ✅ 侵害の影響を局所化（mTLS CA 侵害でも IoT・Code は無傷）
  ✅ 用途別のセキュリティ設定
  ✅ ロードバランシング

信頼チェーン・階層構成

X.509 証明書のフィールド

Subject（被証明者）:
  CN: service-a.internal
  O: MyCompany
  OU: Engineering

Issuer（発行者）:
  CN: Issuing CA JP
  O: MyCompany

Validity:
  Not Before: 2025-01-01
  Not After: 2027-12-31

Public Key:
  KeyType: RSA-2048
  (暗号化・署名検証用)

Extensions:
  - Basic Constraints: CA=false（end-entity 証明書）
  - Subject Alt Name: service-a.internal, service-a.corp
  - Key Usage: Digital Signature, Key Encipherment
  - Extended Key Usage: Server Authentication, Client Authentication

自己署名（Self-signed）vs CA 署名

Self-signed（Root CA の場合）:
  Issuer = Subject
  自分の秘密鍵で自分の証明書に署名
  ├─ 利点: 外部に依存しない
  ├─ 用途: Root CA
  └─ 検証: 信頼鍵ストアに Root CA 証明書を事前登録

CA 署名（End-entity）:
  Issuer = Issuing CA
  CA の秘密鍵で end-entity 証明書に署名
  ├─ 利点: 信頼チェーン明確
  ├─ 用途: mTLS・IoT・Web サービス
  └─ 検証: CA 証明書 → Root CA → 信頼鍵ストア

証明書タイプ・用途

ACM との連携

ACM Private Issuer（Private CA との統合）

ACM の Private Issuer 機能:
  ↓
  Private CA で発行した証明書を ACM で管理
  ↓
  CloudFront / ALB / API Gateway で使用可能
  ↓
  自動更新対応

ワークフロー:

① ACM で「Private Certificate を Request」
② Private Issuer として Subordinate CA を指定
③ ACM が Private CA に証明書発行要求
④ Private CA が署名・発行
⑤ ACM が証明書を管理・自動更新
⑥ CloudFront / ALB に自動適用

ACM Private Certificate の利点

メリット:
  - Private CA の証明書を ACM で一元管理
  - CloudFront / ALB / API Gateway への適用が簡単
  - 自動更新対応（有効期限 60 日前に自動更新試行）
  - CloudTrail で監査

用途例:
  - 内部 API エンドポイント（*.internal.corp）
  - Private CloudFront ディストリビューション
  - VPN エンドポイント
  - Kubernetes Ingress のバックエンド

主要ユースケース

1. マイクロサービス間 mTLS（ECS）

ECS サービス（Service A）と別サービス（Service B）が TLS で通信

アーキテクチャ:

        ┌────────────────────────────────────┐
        │     AWS Private CA                 │
        │ (Subordinate CA: mTLS-Issuing)     │
        └────────────────────────────────────┘
                    │
        ┌───────────┴───────────┐
        │                       │
   ┌─────▼──────┐          ┌─────▼──────┐
   │ Service A  │          │ Service B  │
   │ Cert:      │          │ Cert:      │
   │ service-a  │          │ service-b  │
   │ (Client)   │          │ (Server)   │
   └─────┬──────┘          └──────┬─────┘
         │                        │
         └──────────mTLS──────────┘

実装:

① Private CA で Service A 클라이언트 증명書 발행
② Private CA で Service B 서버 증명서 발行
③ 两 서비스가 상호 증명서를 신뢰 키 스토어에 등록
④ mTLS 통신 확립

2. IoT デバイス認証

製造ラインでデバイスごとに証明書を配付・Secure Element に焼き込み

フロー:

製造段階:
  ① デバイスが Secure Element 内で秘密鍵を生成
  ② CSR（証明書署名要求）を作成
  ③ CSR を制御サーバーに送信
  ④ 制御サーバーが Private CA に証明書発行要求
  ⑤ Private CA が署名・発行
  ⑥ 証明書をデバイスに返信
  ⑦ デバイス Secure Element に証明書をインストール

運用段階:
  ① デバイスが AWS IoT Core に接続（証明書で認証）
  ② IoT Core がデバイス証明書の署名を Private CA で検証
  ③ 認証成功 → MQTT 通信開始
  ④ デバイスからセンサーデータを定期送信

スケール:
  月間数百万デバイス対応可能

3. コード署名（CI/CD パイプライン）

Lambda・ECS・EC2 AMI のコード署名で完全性を保証

フロー:

① CI/CD パイプライン（CodePipeline）が Private CA にコード署名用証明書をリクエスト
② Private CA が署名用証明書を発行
③ CodeBuild がコンパイル済みバイナリに署名
④ 署名済みバイナリ + 証明書を配布
⑤ デプロイ時に署名を検証 → 完全性確認

利点:
  ✅ 供給チェーン攻撃（バイナリ改ざん）の防止
  ✅ コンプライアンス要件対応

4. VPN クライアント認証

社員が VPN で社内リソースにアクセス時に証明書認証

フロー:

① Private CA で VPN クライアント証明書を発行
② デバイス（PC・スマホ）にインストール
③ VPN 接続時に証明書を提示（クライアント認証）
④ VPN サーバーが証明書検証 → Private CA で署名確認
⑤ 認証成功 → VPN トンネル確立

セキュリティ:
  ✅ パスワード不要（証明書認証）
  ✅ デバイス認証と同時にユーザー認証

5. Kubernetes（EKS）での自動証明書管理

EKS クラスター内での Workload Certificate 自動管理

フロー:

① cert-manager がクラスター内で動作
② cert-manager が Private CA と連携
③ Pod（ワークロード）が TLS 通信を開始
④ cert-manager が自動で証明書をリクエスト
⑤ Private CA が発行
⑥ Pod が証明書を使用
⑦ 有効期限 30 日前に自動更新

メリット:
  ✅ Kubernetes ネイティブな証明書管理
  ✅ Operator パターンで自動化
  ✅ GitOps と統合可能

CSR・証明書発行フロー

CSR（Certificate Signing Request）の生成

# ステップ 1: 秘密鍵を生成
openssl genrsa -out service-a.key 2048

# ステップ 2: CSR を生成
openssl req -new \
  -key service-a.key \
  -out service-a.csr \
  -subj "/CN=service-a.internal/O=MyCompany/OU=Engineering"

# ステップ 3: Subject Alternative Names（SAN）を追加
cat > service-a.conf << EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]

[v3_req]
subjectAltName = DNS:service-a.internal,DNS:service-a.corp,IP:10.0.0.10
EOF

openssl req -new \
  -key service-a.key \
  -out service-a.csr \
  -subj "/CN=service-a.internal/O=MyCompany" \
  -config service-a.conf

# ステップ 4: CSR の内容を確認
openssl req -text -noout -in service-a.csr

Private CA での証明書発行

# CSR ファイルを Base64 エンコード
CSR_CONTENT=$(cat service-a.csr | base64)

# Private CA に証明書発行要求
aws acm-pca issue-certificate \
  --certificate-authority-arn arn:aws:acm-pca:ap-northeast-1:123456789012:certificate-authority/ca-abc123 \
  --csr file://service-a.csr \
  --signing-algorithm SHA256WITHRSA \
  --template-arn arn:aws:acm-pca:::template/EndEntityServerAuthCertificate/V1 \
  --validity Value=365,Type=DAYS \
  --region ap-northeast-1

# 出力例:
# {
#   "CertificateArn": "arn:aws:acm-pca:...:certificate/...",
#   "CertificateChainArn": "arn:aws:acm-pca:...:certificate/..."
# }

# ステップ 2: 発行された証明書を取得
aws acm-pca get-certificate \
  --certificate-authority-arn arn:aws:acm-pca:ap-northeast-1:...:certificate-authority/ca-abc123 \
  --certificate-arn arn:aws:acm-pca:...:certificate/... \
  --region ap-northeast-1 \
  --output json > cert-response.json

# 証明書を PEM ファイルに保存
jq -r '.Certificate' cert-response.json > service-a.crt
jq -r '.CertificateChain' cert-response.json > service-a-chain.crt

証明書チェーンの検証

# 証明書チェーンを確認
openssl verify -CAfile service-a-chain.crt service-a.crt

# 出力:
# service-a.crt: OK

# 証明書の詳細を表示
openssl x509 -text -noout -in service-a.crt

CRL・OCSP・失効管理

CRL（Certificate Revocation List）の配信

CRL とは:
  失効証明書のシリアル番号リスト
  定期的に（例: 1 日ごと）更新・配布

フロー:

① Private CA が CRL を生成
② CRL を S3 に保存（またはアクセス可能な URL）
③ クライアントが定期的に CRL をダウンロード
④ サーバー証明書が CRL に含まれるか確認
   → 含まれている = 失効（通信拒否）
   → 含まれていない = 有効（通信許可）

実装例:

aws acm-pca describe-certificate-authority \
  --certificate-authority-arn arn:aws:acm-pca:... \
  --query 'CertificateAuthority.RevocationConfiguration'

# 出力:
# {
#   "RevocationConfiguration": {
#     "CrlConfiguration": {
#       "Enabled": true,
#       "ExpirationInDays": 30,
#       "CustomCname": "crl.example.internal",
#       "S3BucketName": "my-crl-bucket"
#     }
#   }
# }

OCSP（Online Certificate Status Protocol）

OCSP とは:
  リアルタイムで失効状態を問い合わせ

フロー:

クライアント:
  ① サーバー証明書を受け取る
  ② OCSP レスポンダーに失効確認要求
     （証明書のシリアル番号を含む）

OCSP レスポンダー（Private CA）:
  ③ シリアル番号から失効状態を検索
  ④ OCSP レスポンスを返送（署名付き）

クライアント:
  ⑤ OCSP レスポンスの署名を検証（CA 証明書で）
  ⑥ 失効状態を確認
     → revoked = 接続拒否
     → good = 接続許可

メリット:
  ✅ リアルタイム確認（CRL は定期配布）
  ✅ ネットワーク効率的（小さい応答）
  ✅ CRL より最新

AWS Private CA での OCSP:
  自動 OCSP レスポンダーを AWS が提供
  クライアント側の統合実装は不要（証明書に OCSP URL 埋め込み）

失効証明書の取り消し

# 失効証明書を確認（例: デバイス損失時）
aws acm-pca revoke-certificate \
  --certificate-authority-arn arn:aws:acm-pca:ap-northeast-1:...:certificate-authority/ca-abc123 \
  --certificate-serial "12:34:56:78:90:AB:CD:EF" \
  --revocation-reason KeyCompromise \
  --region ap-northeast-1

# revocation-reason オプション:
#   Unspecified / KeyCompromise / CACompromise / AffiliationChanged /
#   Superseded / CessationOfOperation / CertificateHold / RemoveFromCRL /
#   PrivilegeWithdrawn / AACompromise

# 失効状態を確認
aws acm-pca describe-certificate-authority \
  --certificate-authority-arn arn:aws:acm-pca:... \
  --query 'CertificateAuthority.RevocationConfiguration'

設定・操作の具体例

AWS CLI での実装

# 例1: Root CA を作成（General Purpose）
ROOT_CA_ARN=$(aws acm-pca create-certificate-authority \
  --certificate-authority-configuration \
    KeyAlgorithm=RSA_2048,\
    SigningAlgorithm=SHA256WITHRSA,\
    Subject='{
      "C": "JP",
      "ST": "Tokyo",
      "L": "Tokyo",
      "O": "MyCompany",
      "OU": "Security",
      "CN": "MyCompany Root CA"
    }' \
  --certificate-authority-type ROOT \
  --tags Key=Environment,Value=Production Key=Purpose,Value=RootCA \
  --region ap-northeast-1 \
  --query 'CertificateAuthorityArn' \
  --output text)

# 例2: Root CA 証明書に署名（CSR ベース）
CSR=$(aws acm-pca get-certificate-authority-csr \
  --certificate-authority-arn $ROOT_CA_ARN \
  --region ap-northeast-1 \
  --query 'Csr' \
  --output text)

# Root CA を自己署名（create-certificate-authority で自動的に作成される）

# 例3: Subordinate CA を作成
SUB_CA_ARN=$(aws acm-pca create-certificate-authority \
  --certificate-authority-configuration \
    KeyAlgorithm=RSA_2048,\
    SigningAlgorithm=SHA256WITHRSA,\
    Subject='{
      "C": "JP",
      "O": "MyCompany",
      "OU": "Issuing",
      "CN": "MyCompany Issuing CA"
    }' \
  --certificate-authority-type SUBORDINATE \
  --tags Key=Purpose,Value=IssueEndEntity \
  --region ap-northeast-1 \
  --query 'CertificateAuthorityArn' \
  --output text)

# 例4: Subordinate CA の CSR を取得
SUB_CSR=$(aws acm-pca get-certificate-authority-csr \
  --certificate-authority-arn $SUB_CA_ARN \
  --region ap-northeast-1 \
  --query 'Csr' \
  --output text)

# Subordinate CA CSR を Root CA で署名
SIGNED_CERT=$(aws acm-pca issue-certificate \
  --certificate-authority-arn $ROOT_CA_ARN \
  --csr "$SUB_CSR" \
  --signing-algorithm SHA256WITHRSA \
  --template-arn arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1 \
  --validity Value=3650,Type=DAYS \
  --region ap-northeast-1 \
  --query 'CertificateArn' \
  --output text)

# 例5: Subordinate CA で End-Entity 証明書を発行
END_CSR=$(cat service-a.csr)

CERT_ARN=$(aws acm-pca issue-certificate \
  --certificate-authority-arn $SUB_CA_ARN \
  --csr "$END_CSR" \
  --signing-algorithm SHA256WITHRSA \
  --template-arn arn:aws:acm-pca:::template/EndEntityServerAuthCertificate/V1 \
  --validity Value=365,Type=DAYS \
  --region ap-northeast-1 \
  --query 'CertificateArn' \
  --output text)

# 例6: 発行された証明書を取得・保存
aws acm-pca get-certificate \
  --certificate-authority-arn $SUB_CA_ARN \
  --certificate-arn $CERT_ARN \
  --region ap-northeast-1 \
  --output text > service-a.crt

# 例7: CA ステータスを確認
aws acm-pca describe-certificate-authority \
  --certificate-authority-arn $SUB_CA_ARN \
  --region ap-northeast-1 \
  --query 'CertificateAuthority.[Status,Type,CreatedAt]'

CloudFormation での実装

AWSTemplateFormatVersion: '2010-09-09'
Description: 'AWS Private CA with Root and Subordinate CAs'

Resources:
  # Root CA
  RootCA:
    Type: AWS::ACMPCA::CertificateAuthority
    Properties:
      Type: ROOT
      KeyAlgorithm: RSA_2048
      SigningAlgorithm: SHA256WITHRSA
      Subject:
        C: JP
        ST: Tokyo
        L: Tokyo
        O: MyCompany
        CN: MyCompany Root CA
      RevocationConfiguration:
        CrlConfiguration:
          Enabled: true
          ExpirationInDays: 30
          S3BucketName: !Ref CRLBucket
      Tags:
        - Key: Purpose
          Value: RootCA

  # Subordinate CA
  SubordinateCA:
    Type: AWS::ACMPCA::CertificateAuthority
    Properties:
      Type: SUBORDINATE
      KeyAlgorithm: RSA_2048
      SigningAlgorithm: SHA256WITHRSA
      ParentArn: !Ref RootCA
      Subject:
        C: JP
        O: MyCompany
        CN: MyCompany Issuing CA
      Tags:
        - Key: Purpose
          Value: IssueEndEntity

  # CRL 保存用 S3 バケット
  CRLBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 'my-crl-bucket-${AWS::AccountId}'
      VersioningConfiguration:
        Status: Enabled
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

  # Root CA 証明書の活性化
  RootCertificateActivation:
    Type: AWS::ACMPCA::CertificateAuthorityActivation
    Properties:
      CertificateAuthorityArn: !Ref RootCA
      CertificateChain: |
        -----BEGIN CERTIFICATE-----
        (Root CA 証明書の PEM)
        -----END CERTIFICATE-----
      Status: ACTIVE

  # Subordinate CA 証明書の活性化
  SubordinateCertificateActivation:
    Type: AWS::ACMPCA::CertificateAuthorityActivation
    Properties:
      CertificateAuthorityArn: !Ref SubordinateCA
      CertificateChain: |
        -----BEGIN CERTIFICATE-----
        (Subordinate CA 証明書 PEM)
        -----END CERTIFICATE-----
      Status: ACTIVE

Outputs:
  RootCAArn:
    Value: !Ref RootCA
    Export:
      Name: RootCAArn

  SubordinateCAArn:
    Value: !Ref SubordinateCA
    Export:
      Name: SubordinateCAArn

Terraform での実装

# AWS Private CA を Terraform で管理

resource "aws_acmpca_certificate_authority" "root" {
  permanent_deletion_time_in_days = 7
  type                            = "ROOT"

  certificate_authority_configuration {
    key_algorithm     = "RSA_2048"
    signing_algorithm = "SHA256WITHRSA"

    subject {
      country_name             = "JP"
      state_or_province_name   = "Tokyo"
      locality_name            = "Tokyo"
      organization_name        = "MyCompany"
      common_name              = "MyCompany Root CA"
    }
  }

  enabled = true

  tags = {
    Purpose = "RootCA"
  }
}

resource "aws_acmpca_certificate_authority" "subordinate" {
  permanent_deletion_time_in_days = 7
  type                            = "SUBORDINATE"

  certificate_authority_configuration {
    key_algorithm     = "RSA_2048"
    signing_algorithm = "SHA256WITHRSA"

    subject {
      country_name      = "JP"
      organization_name = "MyCompany"
      common_name       = "MyCompany Issuing CA"
    }
  }

  parent_arn = aws_acmpca_certificate_authority.root.arn

  enabled = true

  tags = {
    Purpose = "IssueEndEntity"
  }
}

# CRL 保存用 S3 バケット
resource "aws_s3_bucket" "crl" {
  bucket = "my-crl-bucket-${data.aws_caller_identity.current.account_id}"
}

# CRL Configuration
resource "aws_acmpca_certificate_authority" "subordinate_with_crl" {
  # ... (上記の設定に加えて)
  
  revocation_configuration {
    crl_configuration {
      enabled             = true
      expiration_in_days  = 30
      custom_cname        = "crl.example.internal"
      s3_bucket_name      = aws_s3_bucket.crl.id
    }
  }
}

data "aws_caller_identity" "current" {}

ECS/EKS 統合

ECS での mTLS 実装

# ECS タスク定義例

{
  "family": "service-a",
  "containerDefinitions": [
    {
      "name": "service-a",
      "image": "my-ecr-repo/service-a:latest",
      "portMappings": [
        {
          "containerPort": 8443,
          "protocol": "tcp"
        }
      ],
      "environment": [
        {
          "name": "TLS_CERT_PATH",
          "value": "/etc/tls/service-a.crt"
        },
        {
          "name": "TLS_KEY_PATH",
          "value": "/etc/tls/service-a.key"
        },
        {
          "name": "CA_CERT_PATH",
          "value": "/etc/tls/ca-chain.crt"
        }
      ],
      "mountPoints": [
        {
          "sourceVolume": "tls-certs",
          "containerPath": "/etc/tls",
          "readOnly": true
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/service-a",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ],
  "volumes": [
    {
      "name": "tls-certs",
      "efsVolumeConfiguration": {
        "filesystemId": "fs-12345678",
        "transitEncryption": "ENABLED"
      }
    }
  ],
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "networkMode": "awsvpc"
}

EKS での cert-manager 統合

# cert-manager リソース（Kubernetes Manifest）

apiVersion: v1
kind: Namespace
metadata:
  name: cert-manager
---
# cert-manager インストール（Helm）
# helm install cert-manager jetstack/cert-manager \
#   --namespace cert-manager \
#   --create-namespace \
#   --version v1.13.0

# Issuer リソース（Private CA）
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: private-ca-issuer
spec:
  aws:
    region: ap-northeast-1
    hostedZoneID: Z1234567890ABC

---
# Certificate リソース
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: service-a-cert
  namespace: default
spec:
  secretName: service-a-tls
  commonName: service-a.default.svc.cluster.local
  dnsNames:
    - service-a
    - service-a.default
    - service-a.default.svc.cluster.local
  issuerRef:
    kind: ClusterIssuer
    name: private-ca-issuer
  duration: 2160h  # 90d
  renewBefore: 720h  # 30d
---
# Service でアノテーション指定
apiVersion: v1
kind: Service
metadata:
  name: service-a
  annotations:
    cert-manager.io/inject-ca-from: cert-manager/private-ca-issuer
spec:
  selector:
    app: service-a
  ports:
    - port: 8443
      targetPort: 8443
      protocol: TCP
---
# Deployment で証明書を使用
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-a
spec:
  selector:
    matchLabels:
      app: service-a
  template:
    metadata:
      labels:
        app: service-a
    spec:
      containers:
      - name: service-a
        image: my-repo/service-a:v1
        ports:
        - containerPort: 8443
        volumeMounts:
        - name: tls
          mountPath: /etc/tls
          readOnly: true
        env:
        - name: TLS_CERT_PATH
          value: /etc/tls/tls.crt
        - name: TLS_KEY_PATH
          value: /etc/tls/tls.key
      volumes:
      - name: tls
        secret:
          secretName: service-a-tls

IoT デバイス認証

デバイスプロビジョニングフロー

#!/bin/bash

# デバイス製造時スクリプト

DEVICE_ID="device-$(uuidgen)"
AWS_REGION="ap-northeast-1"
CA_ARN="arn:aws:acm-pca:${AWS_REGION}:123456789012:certificate-authority/ca-abc123"

echo "Provisioning device: ${DEVICE_ID}"

# ステップ 1: デバイスの秘密鍵を生成（Secure Element に保管）
openssl genrsa -out ${DEVICE_ID}.key 2048
echo "Generated private key"

# ステップ 2: CSR を生成
openssl req -new \
  -key ${DEVICE_ID}.key \
  -out ${DEVICE_ID}.csr \
  -subj "/CN=${DEVICE_ID}/O=MyCompany/OU=IoT"
echo "Generated CSR"

# ステップ 3: CSR を制御サーバーに送信
curl -X POST \
  -H "Content-Type: application/json" \
  -d @${DEVICE_ID}.csr \
  https://provisioning-server.internal/api/csr

# ステップ 4: 制御サーバー側で証明書を発行
aws acm-pca issue-certificate \
  --certificate-authority-arn ${CA_ARN} \
  --csr file://${DEVICE_ID}.csr \
  --signing-algorithm SHA256WITHRSA \
  --template-arn arn:aws:acm-pca:::template/IoTDeviceCertificate/V1 \
  --validity Value=1825,Type=DAYS \
  --region ${AWS_REGION}

# 発行証明書を取得
aws acm-pca get-certificate \
  --certificate-authority-arn ${CA_ARN} \
  --certificate-arn ... \
  --region ${AWS_REGION} | \
  jq -r '.Certificate' > ${DEVICE_ID}.crt

# ステップ 5: 証明書をデバイスに返信
curl -X POST \
  -H "Content-Type: application/x-pem-file" \
  --data-binary @${DEVICE_ID}.crt \
  https://provisioning-server.internal/api/certificate/${DEVICE_ID}

# ステップ 6: デバイスが秘密鍵 + 証明書を Secure Element にインストール
# (デバイス側で実行)
# secureElement.importPrivateKey(${DEVICE_ID}.key, ${DEVICE_ID})
# secureElement.importCertificate(${DEVICE_ID}.crt, ${DEVICE_ID})

echo "Device provisioning completed"

コード署名

CI/CD でのコード署名実装

#!/bin/bash

# CodeBuild 内での実行（buildspec.yml）

ARTIFACT="myapp-${CODEBUILD_BUILD_ID}.jar"
CA_ARN="arn:aws:acm-pca:ap-northeast-1:...:certificate-authority/code-sign-ca"
AWS_REGION="ap-northeast-1"

echo "Signing artifact: ${ARTIFACT}"

# ステップ 1: コード署名用の秘密鍵・証明書を Private CA から取得
aws acm-pca issue-certificate \
  --certificate-authority-arn ${CA_ARN} \
  --csr file://codebuild.csr \
  --signing-algorithm SHA256WITHRSA \
  --template-arn arn:aws:acm-pca:::template/CodeSigningCertificate/V1 \
  --validity Value=365,Type=DAYS \
  --region ${AWS_REGION}

# ステップ 2: 証明書を取得
aws acm-pca get-certificate \
  --certificate-authority-arn ${CA_ARN} \
  --certificate-arn ... \
  --region ${AWS_REGION} | \
  jq -r '.Certificate' > codesign.crt

# ステップ 3: アーティファクトに署名
# Java の例
jarsigner -keystore keystore.jks \
  -tsa http://timestamp.example.internal \
  ${ARTIFACT} \
  codesign-key

# または OpenSSL で署名
openssl dgst -sha256 -sign codesign.key ${ARTIFACT} > ${ARTIFACT}.sig

# ステップ 4: 署名済みアーティファクトを保存
aws s3 cp ${ARTIFACT} s3://signed-artifacts/
aws s3 cp ${ARTIFACT}.sig s3://signed-artifacts/

echo "Artifact signed and uploaded"

External Key Store（XKS）

CloudHSM での鍵管理

AWS Private CA でキーを CloudHSM（顧客管理）で保管

メリット:
  ✅ キーマテリアルを顧客が完全制御
  ✅ AWS も物理的にアクセス不可
  ✅ FIPS 140-3 Level 3 認証
  ✅ 高度なコンプライアンス要件対応

デメリット:
  ❌ 運用が複雑（CloudHSM の管理が必要）
  ❌ コストが高い（CloudHSM 月額費用）

セットアップ:

1. CloudHSM クラスタを作成
2. CloudHSM 内でキーペアを生成
3. Private CA 作成時に XKS キーストアを指定
4. キー管理操作を CloudHSM で実行

バックアップ・災害復旧

Private CA のバックアップ戦略

自動バックアップ（AWS 管理）:
  - CA データベース（メタデータ・失効証明書リスト）
  - CloudTrail ログ
  - S3 での CRL 保管

顧客の追加対策:
  - Root CA 証明書の安全な保管（オフサイト）
  - Root CA 秘密鍵のバックアップ（オプション）
  - CSR・発行証明書のバックアップ（コンプライアンス用）

災害復旧フロー:

① CA 侵害検知
② Subordinate CA 廃止
③ 新 Subordinate CA 作成
④ Root CA で新 CA に署名
⑤ 新証明書を全デバイス・サービスに配布
⑥ 旧証明書を失効（CRL に追加）

セキュリティ・監査

CloudTrail で操作を監査

# Private CA 関連の CloudTrail イベント
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::ACMPCA::CertificateAuthority \
  --region ap-northeast-1

# イベント種別:
#   CreateCertificateAuthority
#   IssueCertificate
#   RevokeCertificate
#   DeleteCertificateAuthority
#   GetCertificate

IAM ポリシー例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "IssueCertificatesOnly",
      "Effect": "Allow",
      "Action": [
        "acm-pca:IssueCertificate",
        "acm-pca:GetCertificate",
        "acm-pca:DescribeCertificateAuthority"
      ],
      "Resource": "arn:aws:acm-pca:*:*:certificate-authority/ca-*"
    },
    {
      "Sid": "DenyCADeletion",
      "Effect": "Deny",
      "Action": "acm-pca:DeleteCertificateAuthority",
      "Resource": "*"
    }
  ]
}

トラブルシューティング

類似サービス比較

ベストプラクティス

✅ 推奨事項

1. Root CA は常時オンライン管理
   理由: Root CA 侵害時の影響が最大

2. Subordinate CA を用途別に分離
   理由: 侵害の影響を局所化

3. CRL と OCSP を併用
   理由: CRL（バックアップ）+ OCSP（リアルタイム）

4. 定期的な CSR・発行証明書のバックアップ
   理由: コンプライアンス要件対応

5. CloudTrail ですべての操作を監査
   理由: セキュリティ・コンプライアンス

6. IAM ポリシーで削除操作を制限
   理由: 誤削除防止

❌ アンチパターン

1. Root CA を日常の証明書発行に使用
   → Subordinate CA を使用

2. CRL・OCSP の検証を無視
   → 失効証明書の検出が遅延

3. CSR の SAN（Subject Alt Name）を検証しない
   → セキュリティリスク

4. Kubernetes での cert-manager なしで手動管理
   → スケール不可

2025-2026 最新動向

1. ML-DSA（Post-Quantum Cryptography）対応

AWS は 2025-2026 年に量子耐性署名への対応を準備

現在: RSA-2048・ECDSA
将来: ML-DSA（Module-Lattice-Based Digital Signature）

影響:
  - Private CA で ML-DSA 秘密鍵生成対応
  - ML-DSA 署名アルゴリズムサポート
  - デバイス・サービスの段階的移行

2. Kubernetes（EKS）との自動統合

cert-manager を通じた ACME サポート拡大

現在: cert-manager + Private CA（手動設定）
将来: ACME プロトコルでネイティブ統合

メリット:
  - 設定簡略化
  - Kubernetes Operator による自動化

3. External Key Store（XKS）の広域化

• CloudHSM・オンプレミス HSM との連携拡大
• 計画:
• オンプレ HSM（Thales・Entrust）のサポート
• マルチリージョン XKS クラスタ

学習リソース

公式ドキュメント

• AWS Private CA ユーザーガイド
• AWS Private CA API リファレンス

比較・参考資料

• HashiCorp Vault PKI
• Smallstep CA
• cert-manager（Kubernetes）

実装例・チェックリスト

チェックリスト

## Private CA 導入前チェック

### 要件確認
- [ ] 内部 PKI が必要か（mTLS・IoT・内部ドメイン等）
- [ ] 階層型 CA 構成（Root + Subordinate）を理解
- [ ] セキュリティ要件を確認（FIPS 140-3 必須か等）
- [ ] 予想発行証明書数

### 設計
- [ ] Root CA・Subordinate CA の分割方針
- [ ] Subordinate CA の用途別分離戦略
- [ ] CRL・OCSP の配信方法
- [ ] バックアップ・災害復旧戦略

### 実装
- [ ] Root CA を作成
- [ ] Subordinate CA を作成
- [ ] Root CA で Subordinate CA に署名
- [ ] CA を ACTIVE に変更
- [ ] CRL 配信用 S3 を設定
- [ ] CloudTrail ロギングを有効化

### 検証
- [ ] CSR 生成・署名フロー確認
- [ ] OCSP レスポンダー動作確認
- [ ] CRL ダウンロード・検証

### セキュリティ
- [ ] IAM ポリシーで削除を制限
- [ ] CloudTrail ログ保護（MFA Delete）
- [ ] Root CA 秘密鍵のバックアップ

まとめ

AWS Private CA（v2.0） は、以下を実現するマネージド PKI サービスです：

1. 階層型 CA 構成 - Root CA（秘密保管）+ Subordinate CA（日常発行）で信頼チェーン構築
2. FIPS 140-3 認証 - 金融・医療向けコンプライアンス要件対応
3. マイクロサービス mTLS - ECS/EKS でのサービス間信頼通信
4. IoT デバイス大量認証 - 製造ラインでの自動プロビジョニング
5. 自動運用 - CRL・OCSP・バックアップをマネージド提供

導入フロー

1. 階層設計（Root + Subordinate）
   ↓
2. Root CA 作成・自己署名
   ↓
3. Subordinate CA 作成・Root で署名
   ↓
4. End-entity 証明書発行開始
   ↓
5. mTLS・IoT・コード署名等で運用

2026 年の進化

• ML-DSA（量子耐性暗号）対応
• Kubernetes ACME 統合
• External Key Store（XKS）拡大

最終更新：2026-04-27 バージョン：v2.0