AWS ACM/Private CA エンタープライズPKI 本番運用 Vol1

1. エンタープライズPKIの課題とACM/Private CA全体像

1-1. 本記事のゴール

本記事は、AWSでエンタープライズグレードのPKI（Public Key Infrastructure）基盤を本番構築・運用したいインフラエンジニアおよびセキュリティアーキテクト向けの実践ガイドです。

AWS Certificate Manager（ACM）とAWS Private Certificate Authority（AWS Private CA）の2つのサービスを軸に、以下の内容を体系的に解説します。

• パブリック証明書とプライベートPKIの正しい使い分け判断基準
• ルートCA・下位CAによる2層CA階層のテンプレート設計と構築手順
• CRL/OCSPを活用した証明書失効管理と有効期限の自動更新設計
• ALB・API GatewayでのmTLS at scaleの本番実装パターン
• Private CAの監査・CloudTrail連携と月額コスト最適化手法

本記事を読み終えると、「どの場面でACMパブリック証明書を使い、どの場面でPrivate CAが必要か」の判断基準が明確になります。エンタープライズ規模のPKI基盤を自信を持って設計・運用できるようになります。

1-2. 読者像

本記事が特に役立つのは、以下のような読者です。

すでにACMを使っているが内部PKIで課題を感じている方

AWSのマネージド証明書（ACMパブリック証明書）はALBやCloudFrontで使っているが、内部マイクロサービス間の認証やハイブリッド環境のワークロード認証に使うプライベート証明書の管理に課題を感じているエンジニアを主な対象としています。ACMとAWS Private CAの違いを整理し、それぞれの最適な用途を明確にします。

PKI基盤をオンプレミスからAWSへ移行したい方

オンプレミスのActive Directory Certificate ServicesやStandalone CAをAWSへ移行し、AWS Private CAを中心とした新しいPKI階層を設計したいセキュリティアーキテクトにも参考になる内容を含めています。CA階層設計・テンプレート設定・マルチアカウントでのCA共有方法を詳述します。

ゼロトラストアーキテクチャを実装したい方

サービス間のすべての通信をmTLSで保護し、X.509証明書ベースのアイデンティティ基盤を整備したいプラットフォームチームを対象に、ALBのverifyモード・API GatewayのmTLS・EKS/ECS環境でのサービスメッシュ実装まで、実装レベルの手順を示します。

コスト管理に課題を感じている方

Private CAを本番導入してみたものの、CA月額料金が予想より高くなった、または複数アカウントでCAを乱立させてしまったというチームに向けて、コスト最適化パターンと適切なCA設計を解説します。

本記事では、PKIとTLS/SSLの基礎知識（証明書チェーン・CAの役割・CRLの概念）があることを前提としています。ACMパブリック証明書の基本的な使い方については既知として進めます。

1-3. エンタープライズPKIの課題と全体像

エンタープライズ環境でAWS上のPKIを本番運用しようとすると、複数の実務的な課題が浮かび上がります。代表的な課題を整理した上で、ACMとAWS Private CAがどのようにアーキテクチャとして組み合わさるかを俯瞰します。

PKIとは何か：エンタープライズ要件の整理

PKI（Public Key Infrastructure：公開鍵基盤）は、デジタル証明書を使って通信相手の正当性を確認し、通信内容を暗号化するための仕組みです。PKIの中核は認証局（CA：Certificate Authority）であり、CAが発行した証明書を持つエンティティを信頼する連鎖（トラストチェーン）がセキュリティの基盤になります。

エンタープライズPKIでは、以下の要件を同時に満たすことが求められます。

• 可用性: CA停止は証明書発行・更新の停止を意味し、サービス全体の障害に直結します
• スケーラビリティ: 証明書発行を人手に依存せず、数千〜数万スケールで自動化できる必要があります
• セキュリティ: ルートCAの秘密鍵保護とアクセス制御が徹底されている必要があります
• 監査可能性: 誰がいつどの証明書を発行・失効させたかを追跡できなければなりません
• コスト効率: CAの運用コストと証明書管理の人的コストを最小化する必要があります

AWS Private CAはこれらのエンタープライズ要件をマネージドサービスとして実現します。

課題1: 長期クレデンシャルのリスク

マイクロサービス間の認証やハイブリッド環境のワークロード認証に長期IAMアクセスキーを使い続けることは、現代のゼロトラスト要件のもとでは推奨されません。アクセスキーが漏洩した場合の影響範囲が広く、定期ローテーションの運用コストも積み重なります。

X.509証明書ベースの短期クレデンシャルへの移行は、この問題を根本から解決します。証明書の有効期間を数時間から数日に設定することで、漏洩時の影響を最小化し、失効処理の必要性も大幅に低減できます。AWS Roles Anywhereを利用すると、EC2外のオンプレミスサーバーやコンテナにもPrivate CA証明書を使った一時IAM認証情報を発行でき、長期アクセスキーを排除できます。

課題2: 証明書の有効期限管理とサイロ化

ACMパブリック証明書はAWSが自動更新してくれますが、内部サービス間で使うプライベート証明書やオンプレミス連携用の証明書は手動管理になりがちです。Excelや独自台帳で期限を管理し、失効を見落として本番障害を起こすという事案は珍しくありません。

証明書がACM・社内CA・サードパーティCAにサイロ化されると、有効期限の一元監視も困難になります。AWS Private CAとEventBridge/AWS Configを組み合わせることで、期限切れ検知の自動化が実現します。ACM経由で発行したPrivate CA証明書はACMの有効期限管理対象に組み込まれ、自動更新の恩恵も受けられます。

課題3: mTLSのスケール問題

ゼロトラストアーキテクチャでサービス間のすべての通信をmTLSで保護しようとすると、証明書の発行・配布・更新を大規模に管理する必要があります。数十から数百のマイクロサービスが存在する環境では、証明書の手動管理が現実的でなくなり、発行の自動化と有効期間の短縮が鍵になります。

AWS Private CAのIssueCertificate APIをアプリケーションコードから呼び出すことで、サービスデプロイ時に証明書を自動発行できます。EKSではcert-managerとACM PCA Issuerを組み合わせることで、KubernetesのCertificateリソース定義から証明書のライフサイクルを自動管理できます。

課題4: CAの可用性とHSM鍵保護

自前でオンプレミスCAを運用している場合、CAサーバーの可用性やルート鍵のハードウェア保護が課題になります。CAが停止すると証明書の発行・更新ができなくなり、サービス全体に影響が波及します。また、ルート鍵をソフトウェアで管理することはコンプライアンス上の問題を招く場合があります。

AWS Private CAはマネージドサービスとして高可用性・耐久性を提供します。さらにAWS CloudHSMと統合することで、ルートCAの秘密鍵をハードウェアセキュリティモジュールで保護し、FIPS 140-2 Level 3準拠の鍵管理を実現できます。CloudHSMはデータが失われない冗長構成でクラスターを組み、ルート鍵はAWS側もアクセスできない設計を採用しています。

ACMとAWS Private CAのアーキテクチャ上の位置づけ

ACMパブリック証明書とAWS Private CAは目的が異なる補完的なサービスです。ACMは外部公開エンドポイント向けのパブリック証明書を無料・自動更新で提供し、AWS Private CAは独自PKI基盤を必要とする内部通信・mTLS・コード署名向けの有料マネージドCAサービスです。

多くのエンタープライズ環境では、外部向けにACMパブリック証明書を使い、内部向けにAWS Private CAで発行したプライベート証明書を使うという2層構成を採用します。ACM経由でPrivate CA証明書を発行すると、自動更新の恩恵を内部証明書にも適用できます。

なお、AWS Private CAサービスは2022年9月28日に「AWS Certificate Manager Private CA」から「AWS Private Certificate Authority」に正式改称されています。本記事では正式名称「AWS Private CA」を統一して使用します。

本記事のスコープ

本記事のスコープは「PKIライフサイクル全体・Private CA階層設計・証明書失効管理・mTLS at scale」に特化しています。以下は本記事のカバー範囲と、関連記事に任せているトピックの整理です。

本記事を読んだ後、PKIの各コンポーネントの詳細については上記の関連記事を参照することで、エンタープライズセキュリティアーキテクチャ全体を体系的に理解できます。

1-4. ACMパブリック証明書 vs AWS Private CA 使い分けナビ

用途の違いを整理するため、ACMパブリック証明書とAWS Private CAを比較します。

ACMパブリック証明書を選ぶべき場合

エンドユーザー（ブラウザ・モバイルアプリ）が直接アクセスするサービスのTLS終端には、ACMパブリック証明書を選びます。Amazon Trust ServicesはほぼすべてのブラウザとOSで信頼済みのため、クライアント側にCA証明書を配布する必要がなく、運用コストが最小化されます。特にALB・CloudFront・API GatewayとのACMネイティブ統合により、証明書の設定・更新が完全に自動化されます。

AWS Private CAを選ぶべき場合

以下のいずれかに当てはまる場合は、AWS Private CAの利用を検討します。

1. 接続元が管理対象のAWSワークロード・オンプレミスサーバー・IoTデバイスであり、CA証明書を配布・信頼設定できる環境にある
2. mTLSを実装してクライアント証明書認証が必要です
3. 証明書の有効期間・拡張フィールド（EKU・SAN・カスタム拡張）を組織ポリシーに沿って細かく制御したい
4. コード署名や文書署名に用いる証明書を独自CAで発行・管理したい
5. AWS Roles Anywhereと統合して、IAMアクセスキーを使わないワークロード認証を実現したい

ACMパブリック証明書は外部トラストに依存するため、内部CA独自のポリシーやカスタム拡張を証明書に埋め込むことができません。Private CAを使うことで、証明書テンプレートを通じてこれらの要件に対応できます。

関連記事との棲み分け

本シリーズはPKIライフサイクル全体・Private CA階層設計・証明書失効管理・mTLS at scaleに特化した専編です。PKIと密接に関連する以下のAWSセキュリティサービスの詳細は、それぞれの記事を参照してください。

CloudHSMを使ってPrivate CAのルート鍵をハードウェアセキュリティモジュールで保護する方法を解説しています。CloudHSMクラスターの構築・Cryptographic Usersの権限設計・CloudHSMとPrivate CAの統合設定を詳述しています。

AWS Roles Anywhereを使って、EC2外のオンプレミスサーバー・コンテナ・GitHub Actionsなどのワークロードにも一時IAM認証情報を発行する手順を解説しています。Private CAで発行した証明書をTrust Anchorに設定する連携方法も取り上げています。

本記事を通じてAWS Private CAの全体像を把握した上で、CloudHSMによるルート鍵保護やRoles Anywhereとのセキュリティ統合を組み合わせることで、エンタープライズグレードのAWSセキュリティ基盤を構築できます。

それでは次節から、ACMパブリック証明書の基礎整理から始めて、順を追ってAWS Private CAの本番設計・運用まで解説していきます。

2. ACM基礎の整理

本節ではACMパブリック証明書の基本的な仕組みを整理します。ACMのパブリック証明書はDNS検証とRoute 53の組み合わせにより完全自動更新を実現できる点が最大のメリットです。ALB・CloudFront・API Gatewayとのネイティブ統合により、証明書の設定・更新がマネージドで処理されます。§3以降のPrivate CA詳解への橋渡しとして、ACMとPrivate CAの違いを理解するための基礎を固めます。

2-1. ACMの役割とAmazon Trust Services信頼チェーン

AWS Certificate Manager (ACM) は、TLS証明書のプロビジョニング・管理・デプロイを自動化するマネージドサービスです。ACMが提供するパブリック証明書は、Amazon Trust Services (ATS) という認証局が発行します。Amazon Trust Servicesのルート証明書は、主要なブラウザ・OS・モバイルプラットフォームに広くプレインストールされており、エンドユーザーが追加設定なく信頼できる状態になっています。

ACMのパブリック証明書の発行フローは以下のとおりです。

1. ACMでドメイン名を指定して証明書をリクエストします。
2. ACMがドメイン所有権を確認するためのDNS検証またはメール検証を実施します。
3. 検証完了後、Amazon Trust ServicesがTLS証明書を発行します。
4. 発行された証明書をAWSサービス（ALB・CloudFront等）に関連付けます。

証明書の種類

ACMでは、用途に応じて以下の3種類の証明書を発行できます。

• 単一ドメイン証明書: example.com のみを保護する標準的な証明書です。
• ワイルドカード証明書: *.example.com という形式で、同一レベルのサブドメインをまとめて保護します。ネストしたサブドメイン (sub.sub.example.com) には適用されません。ワイルドカード証明書はDNS検証を選択した場合のみ自動更新の対象になります。
• SAN (Subject Alternative Names) 証明書: 複数の異なるドメインを1枚の証明書でカバーします。ACMでは最大100のドメイン名をSANに設定できます。

鍵アルゴリズム

ACMはRSA 2048ビット・RSA 3072ビット・RSA 4096ビット・ECDSA P-256・ECDSA P-384のアルゴリズムをサポートします。ECDSA (楕円曲線暗号) はRSAより短い鍵長で同等のセキュリティ強度を実現でき、TLSハンドシェイクの計算コストを削減できます。パフォーマンスが重要な大規模環境ではECDSA P-256の採用が増えています。ECDSAとRSAを同一ドメインに並行して発行する「デュアルアルゴリズム」構成も可能で、古いクライアントとの互換性を保ちながら新しいクライアントには軽量なECDSAを提供できます。

秘密鍵の保護設計

ACMはパブリック証明書の秘密鍵をAWSが管理するHSM (Hardware Security Module) で保護します。秘密鍵はコンソール・APIを通じてエクスポートできない設計になっており、証明書の秘密鍵が組織外に漏洩するリスクを根本的に排除しています。秘密鍵を自前で管理する必要がないため、証明書管理の運用負荷を大幅に削減できます。

費用

ACMのパブリック証明書は無料で発行できます。証明書自体に費用はかかりませんが、証明書を利用するAWSサービス（ALB・CloudFrontなど）の利用料金は別途発生します。なお、AWS Private CAと連携して発行するプライベート証明書についてはCAの月額料金と証明書の従量課金が発生します（§6で詳解）。

有効期間と証明書ステータス遷移

ACMのパブリック証明書の有効期間は 13ヶ月固定 です。発行リクエスト後、証明書は以下のステータスを遷移します。

DNS検証で証明書をリクエストした後、CNAMEを設定してから ISSUED ステータスになるまでは通常数分〜数十分かかります。Route 53の場合はCNAME伝播の速さから、数分以内に完了するケースが多いです。他のDNSプロバイダーでは伝播に時間がかかります。

2-2. DNS検証とメール検証・自動更新の仕組み

ACMでパブリック証明書を発行する際、ドメイン所有者であることを証明する「ドメイン検証」が必要です。検証方式は DNS検証 と メール検証 の2種類があります。本番環境では自動更新に対応したDNS検証を選択することを強く推奨します。

DNS検証 (推奨)

DNS検証では、ACMが指定するCNAMEレコードをドメインのDNSゾーンに追加することでドメイン所有権を証明します。

名前: _abc123.example.com.
値: _def456.acm-validations.aws.

CNAMEレコードの名前と値はACMコンソールまたはCLI・APIから確認できます。Amazon Route 53を使用している場合、ACMコンソールの「Route 53でレコードを作成」ボタンをクリックするだけでCNAMEが自動挿入されます。Route 53以外のDNSプロバイダーを使用している場合は、各プロバイダーの管理画面から手動でCNAMEレコードを追加する必要があります。

ワイルドカード証明書 (*.example.com) のDNS検証では、ワイルドカードドメインと親ドメイン (example.com) の両方の検証が必要になる場合がありますが、ACMが同一のCNAMEで一括検証できるケースも多くあります。DNS検証の最大の利点は、証明書の自動更新 に対応している点です。CNAMEレコードが存在し続ける限り、ACMは有効期限が近づくと自動的に証明書を更新します。証明書の期限切れを気にする必要がなくなり、運用負担を大幅に削減できます。

自動更新のタイミング

ACMのパブリック証明書（DNS検証）の自動更新は以下のスケジュールで実行されます。

• 有効期限 60日前: 更新プロセスを開始します。
• 有効期限 30日前: 更新に失敗していた場合、再試行します。
• 更新完了後: 関連付けられたAWSリソース（ALB・CloudFrontなど）に即時反映されます（ダウンタイムなし）。

証明書の更新状況はACMコンソールで確認できます。Amazon EventBridgeを使用して証明書のライフサイクルイベントを検知し、有効期限が近い証明書の存在を通知するアラートを設定できます。DNS検証のCNAMEレコードを誤って削除してしまうと自動更新が失敗するため、CNAMEレコードは永続的に保持するよう設定してください。

メール検証

メール検証では、ACMがドメインに関連するメールアドレスへ承認メールを送信します。メール受信者が承認リンクをクリックすることでドメイン所有権が確認されます。対象となるメールアドレスは以下のとおりです。

• admin@example.com
• administrator@example.com
• hostmaster@example.com
• postmaster@example.com
• webmaster@example.com
• WHOISデータベースに登録されているドメイン所有者のメールアドレス

メール検証では証明書の自動更新ができません。 更新時に再度メールによる承認操作が必要になります。ドメイン移管・メールアドレス変更が重なると、承認の遅延リスクがあります。特別な理由がない限りDNS検証を選択することを推奨します。

2-3. 統合先サービス (ALB/CloudFront/API Gateway)

ACMで発行した証明書は、以下のAWSサービスに直接関連付けて使用します。証明書のエクスポートはできませんが、AWS統合サービスとの連携はコンソール・CloudFormation・Terraformなどのツールから数ステップで完了します。本節では主要な統合先を簡潔にまとめます。詳細な設定方法は各サービスの公式ドキュメントを参照してください。

Application Load Balancer (ALB) / Network Load Balancer (NLB)

ALBのHTTPSリスナーを作成する際、ACM証明書を選択します。1つのリスナーに複数の証明書を関連付けることが可能で、ALBはServer Name Indication (SNI) を利用してリクエストのホスト名に応じた証明書を動的に選択します。これにより1つのALBで複数のドメインを効率的にホストできます。

NLBでもTLSリスナーにACM証明書を使用できます。NLBはL4レベルで動作するため、クライアントIPのパススルーが可能で、バックエンドのアクセスログにクライアントIPを記録できます。ALBでのHTTP→HTTPSリダイレクトを設定する場合、ポート80のリスナーにリダイレクトルールを追加し、ポート443のリスナーにACM証明書を設定するという2段構成をとります。

Amazon CloudFront

CloudFrontのビューワー向けHTTPS設定でACM証明書を使用します。ここで重要な制約があります。CloudFront用のACM証明書は必ず us-east-1 (バージニア北部) リージョンで作成する必要があります。 CloudFrontはグローバルに分散したサービスのため、証明書の管理もグローバルの起点となるus-east-1に統一されています。東京リージョン (ap-northeast-1) など他のリージョンで作成した証明書はCloudFrontのコンソール上に表示されず、設定できません。

CloudFrontではOAC (Origin Access Control) と組み合わせてS3オリジンへのアクセスを制御しつつ、CloudFrontのビューワーにはHTTPSを強制するという構成が一般的です。

Amazon API Gateway

API Gatewayのカスタムドメイン名設定でACM証明書を使用します。REST APIとHTTP APIのどちらでもACM証明書を直接参照でき、カスタムドメインのHTTPS化が簡単に実現できます。API Gatewayのデフォルトエンドポイント (execute-api.region.amazonaws.com) を無効化し、カスタムドメインのみを公開する構成も推奨されます。

その他の統合先

• AWS Elastic Beanstalk: ロードバランサーのHTTPS設定でACM証明書を使用できます。Beanstalk環境の設定ファイル (.ebextensions) で証明書ARNを指定して管理できます。
• AWS CloudFormation: AWS::CertificateManager::Certificate リソースで証明書を定義し、IaCとして管理できます。DomainValidationOptions でRoute 53への自動検証設定も可能です。
• AWS Amplify: カスタムドメインのHTTPS化にACM証明書を自動プロビジョニングします。管理不要で証明書が自動発行・更新されます。
• AWS App Runner: カスタムドメインにACM証明書を自動発行して関連付けます。独自ドメインのHTTPS化が数ステップで完了します。

ACM証明書の発行・更新・デプロイはすべてAWSのマネージドサービスとして処理されます。アプリケーション間のmTLSや社内システムへのプライベート証明書配布など、より複雑なPKI要件については §3 以降で詳しく解説します。

2-4. ACM発行のプライベート証明書 (Private CA連携)

ACMはパブリック証明書の発行だけでなく、AWS Private CAと連携してプライベート証明書の発行・管理もできます。プライベート証明書はパブリックCAに信頼されていないため、アクセスするクライアントは発行元CAをトラストストアに登録する必要があります。

ACM経由のプライベート証明書発行手順

1. まずAWS Private CAでプライベートCAを作成・有効化します（§3で詳解）。
2. ACMコンソールで「証明書のリクエスト」→「プライベートCA発行の証明書」を選択します。
3. 使用するプライベートCAをリストから選択します。
4. ドメイン名（内部ドメインも指定可）と有効期間を設定します。
5. 証明書が即時発行されます（ドメイン検証は不要です）。
6. 発行された証明書をALB・NLB・API Gatewayなどに関連付けて使用します。

ACM経由発行の最大のメリット: 自動更新

ACM経由で発行したプライベート証明書は、有効期限の 11ヶ月前 から自動更新が試みられます（証明書の有効期間が13ヶ月の場合）。一方、AWS Private CA SDK/CLIを使って直接発行した証明書は自動更新の対象外となり、手動でのライフサイクル管理が必要です。有効期限のモニタリングや更新スクリプトを自前で整備する必要があります。

ACM経由発行 vs Private CA直接発行の比較

ACM経由発行はAWSサービスとの統合に最適化されており、自動更新の恩恵を受けられます。マイクロサービス間のmTLSやIoTデバイスへの証明書配布、コード署名など、ACM非対応のシステムに証明書を配布する場合はPrivate CA直接発行が必要です。AWS Private CAを使ったCA階層設計・証明書テンプレート・失効管理 (CRL/OCSP) の詳細については §3 以降で詳しく解説します。

3. AWS Private CA 階層設計

3-1. 改称経緯とサービス位置づけ

AWS Private Certificate Authority（AWS Private CA）は、2022年9月28日に「ACM Private CA」から現在の名称へ改称されたフルマネージドプライベートCA（認証局）サービスです。改称によってACM（パブリック証明書サービス）とは独立した製品として位置づけが明確化されました。

AWS Private CAは、社内システム・マイクロサービス間通信・コンテナワークロード・IoTデバイス・ハイブリッドワークロードなど、パブリックCAでは発行できないプライベートX.509証明書の大規模な発行・管理を目的として設計されています。

AWS Private CAの主な特徴は次のとおりです。

• フルマネージドCA基盤: HSMバックエンドによるCA秘密鍵保護・高可用性・自動バックアップが標準提供されます。
• API駆動の証明書発行: IssueCertificate APIで証明書を即時発行でき、自動化パイプラインとの統合に最適です。
• 証明書テンプレート: PathLenConstraint・keyUsage・extendedKeyUsageをテンプレートで宣言的に制御できます。
• CloudTrail統合: 全CA操作・証明書発行ログがCloudTrailに自動記録され、監査要件を満たせます。
• マルチアカウント対応: RAM（Resource Access Manager）によってCA発行権限を組織内の複数アカウントへ共有できます。

ACMパブリック証明書との使い分けにおける重要な違いとして、AWS Private CAは任意のDN（Distinguished Name）・有効期間・拡張フィールドを持つ証明書を発行できます。一方、CA稼働中は月額料金（汎用CA $400/月・短期CA $50/月）が継続的に発生するため、利用規模とコストのバランスを設計段階で見積もることが重要です。

3-2. ルートCA/下位CAの階層トポロジ設計

PKI階層の基本構造は「ルートCA（Trust Anchor）→ 下位CA → エンドエンティティ証明書」という信頼チェーンで構成されます。AWS Private CAでは、この階層構造をAWSのマネージドサービスとして実装できます。

2段階構成（推奨：一般的なエンタープライズ）

最もシンプルで運用しやすい構成は、ルートCAと下位CAによる2段階構成です。

ルートCA（AWS Private CA: DISABLED推奨）
  └── 下位CA（AWS Private CA: ACTIVE）
  ├── サーバー証明書（TLS/mTLS）
  ├── クライアント証明書
  └── コード署名証明書

この構成では、ルートCAを普段はDISABLEDにしてセキュリティを高め、下位CAのみをACTIVEにして証明書を発行します。ルートCAをDISABLEDにする主な目的は、ルートCAの秘密鍵への不正アクセスリスクを最小化することです。下位CAの証明書更新など必要なときのみルートCAをACTIVEへ戻す運用とすることで、オンプレミスのオフラインルートCAに近いセキュリティポスチャを実現できます。

3段階構成（大規模エンタープライズ・環境分離）

大規模エンタープライズや開発・本番環境の厳格な分離が必要な場合は、3段階構成が適しています。

ルートCA（DISABLED: 長期保護）
  └── 中間CA / ポリシーCA（ACTIVE: 用途別分岐点）
  ├── 発行CA-A（本番サーバー証明書担当）
  ├── 発行CA-B（開発・テスト担当）
  └── 発行CA-C（コード署名担当）

3段階構成では、中間CA（ポリシーCA）のPathLenConstraintが発行可能な下位CAの深さを制御します。発行CAを用途・環境・部門別に分けることで、セキュリティインシデントや証明書失効時の影響範囲を局所化できます。

CA状態遷移とオフラインルートCAパターン

エンタープライズPKIのベストプラクティスとして、ルートCAは証明書発行後、即座にDISABLED状態へ移行させます。AWS Private CAのCA状態は次のように遷移します。

ルートCAをDISABLEDにする主な操作タイミングは次のとおりです。

• 下位CAへのCA証明書署名が完了した直後
• セキュリティインシデント時の緊急停止
• 下位CA証明書の更新時（一時的にACTIVEへ戻す → 再度DISABLED）

CA有効期限の設計原則

CA階層を設計する際は、有効期限の包含関係を必ず検証します。

AWS Private CAでは、エンドエンティティ証明書の有効期限がCA証明書の有効期限を超えて発行しようとするとAPIエラーになります。ACM経由でPrivate CA発行証明書の自動更新を利用する場合、更新試行タイミング（期限切れ60日前から）もこの制約の範囲内に収まるよう設計してください。

3-3. 証明書テンプレート

AWS Private CAは証明書の用途・制約をテンプレートARNで制御します。テンプレートはCA証明書発行時とエンドエンティティ証明書発行時の双方で使用します。

CA証明書発行に使用する主要テンプレート

テンプレートARNは次の形式で指定します。

arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1

エンドエンティティ証明書発行に使用する主要テンプレート

IssueCertificate APIでTemplateArnパラメータを省略した場合はEndEntityCertificate/V1が自動適用されます。

カスタム拡張フィールド（Subject Alternative Names以外・カスタムOIDなど）が必要な場合はBlankEndEntityCertificate_CSRPassthrough/V1を使用します。このテンプレートはCSRに含まれる拡張フィールドをそのまま証明書に転写します。CSRパススルーテンプレートを使用する際は、CSRの提供元を信頼できるソース（ACM・Secrets Managerなど）に限定し、任意のCSRを受け付ける構成は避けてください。

3-4. 発行権限とRAM共有・マルチアカウント設計

単一アカウント構成での発行権限管理

単一アカウント内での証明書発行は、IAMポリシーでacm-pca:IssueCertificateアクションの許可対象を制御します。最小権限の原則に従い、特定のCA ARN（Resource）と証明書テンプレート（Condition）を組み合わせて制限することを推奨します。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": "acm-pca:IssueCertificate",
"Resource": "arn:aws:acm-pca:ap-northeast-1:123456789012:certificate-authority/ca-id",
"Condition": {
  "StringLike": {
 "acm-pca:TemplateArn": "arn:aws:acm-pca:::template/EndEntityCertificate/*"
  }
}
 }
  ]
}

マルチアカウント構成とRAM共有

AWS Organizations配下の複数アカウントにCA発行権限を共有する場合は、RAM（Resource Access Manager）を活用します。

RAM共有によるCA共有フロー:

1. CAを所有するアカウント（CA管理アカウント）でRAMリソース共有を作成します。
2. 共有対象のCA ARNをリソースとして指定します。
3. 共有先をAWS Organizationsの組織・OU・個別アカウントIDで指定します。
4. 共有先アカウントがIssueCertificate APIでCA ARNを指定して証明書を発行します。

# RAM共有作成例（CA管理アカウント側）
aws ram create-resource-share \
  --name "shared-subordinate-ca" \
  --resource-arns "arn:aws:acm-pca:ap-northeast-1:123456789012:certificate-authority/ca-id" \
  --principals "arn:aws:organizations::123456789012:organization/o-xxxx" \
  --region ap-northeast-1

RAM共有されたCAを使って証明書発行する際、共有先アカウントにはacm-pca:IssueCertificateとacm-pca:GetCertificateの権限が必要です。CA管理アカウント側ではRAMリソースポリシーにより共有先アカウントの発行アクションが自動で許可されます。

CAリソースベースポリシー

RAMに加えて、CA自体にリソースベースポリシー（PutPolicy API）を設定することで、より細粒度のアクセス制御を実現できます。「特定のOU配下アカウントにはEndEntityClientAuthCertificateテンプレートのみ許可」といった制御をCA側で一元管理できるのが特徴です。

3-5. 短期証明書モード (short-lived certificate mode)

AWS Private CAには証明書有効期限の設計に応じた2つのCA動作モードがあります。

短期証明書モードではCA費用が約87.5%削減（$400→$50）されます。証明書の有効期限を最大7日間に限定する代わり、CRL/OCSPによる失効管理が不要になります。7日以内に証明書が自動期限切れとなるため、失効機構なしでも証明書の悪用リスクを限定できます。

短期証明書モードが適するユースケース

• マイクロサービス間mTLS: コンテナ・Podが短命であり、証明書もサービスライフサイクルに合わせた短命設計が最適です。
• Roles Anywhere経由のワークロードID: IAMロール相当の認証に使用し、長期証明書の必要がないワークロードに向いています。
• CI/CDパイプライン: ジョブ実行中のみ有効な証明書による一時的な認証を実現できます。
• AWS IoT FleetProvisioning統合: デバイスの初期証明書として使用後、即時期限切れさせるユースケースに対応します。

短期証明書モードの制約事項

短期証明書モードのCAは作成後に汎用モードへ変更できません（逆も同様）。CRL設定が不要かつ設定不可なため、失効管理を要するユースケースでは汎用モードを選択してください。また、ACM経由の自動更新は汎用モードのみ対応しており、短期証明書モードのCAではACM経由の自動更新は利用できません。

4. 証明書ライフサイクル管理

証明書ライフサイクルとは、証明書の発行 → 配布 → 更新 → 失効 → 廃棄という一連の流れを指します。エンタープライズ環境では数千〜数万枚の証明書を管理するため、この全フェーズを自動化・可視化することが不可欠です。AWS Private CAとACMを組み合わせることで、証明書ライフサイクルの大部分を自動化できます。

4-1. 発行フローと有効期限管理

証明書の発行は CSR (Certificate Signing Request) 生成 → Private CAへの送信 → 証明書取得 という3ステップで完結します。AWS CLIを使った基本的な発行フローを以下に示します。

# 1. 秘密鍵とCSRを生成
openssl req -new -newkey rsa:2048 -keyout private.key -out csr.pem \
  -subj "/CN=app.internal.example.com"

# 2. IssueCertificate API で証明書を発行
CERT_ARN=$(aws acm-pca issue-certificate \
  --certificate-authority-arn arn:aws:acm-pca:ap-northeast-1:123456789012:certificate-authority/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --csr fileb://csr.pem \
  --signing-algorithm SHA256WITHRSA \
  --template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1 \
  --validity Value=365,Type=DAYS \
  --query CertificateArn --output text)

# 3. 証明書を取得
aws acm-pca get-certificate \
  --certificate-authority-arn <CA_ARN> \
  --certificate-arn $CERT_ARN \
  --query Certificate --output text > certificate.pem

テンプレートARNの選択は証明書の用途に応じて決まります。主要なテンプレートを以下に示します。

有効期間 (Validity) は DAYS / MONTHS / YEARS / ABSOLUTE / END_DATE の5種類で指定できます。エンタープライズ運用では、CA証明書の有効期限内に収まるよう設計する必要があります。一般的な設計指針として、ルートCA = 10年、下位CA = 3〜5年、エンドエンティティ証明書 = 1年 (最長13ヶ月) が推奨されます。

ACM経由で発行したPrivate CA証明書は、ACMが有効期限を追跡します。ACM管理下の証明書は有効期限の60日前から自動更新プロセスが開始され、担当者が手動で対応する必要はありません。一方、IssueCertificate APIを直接呼び出して発行した証明書はACMの管理外となるため、後述する独自の監視・更新ワークフローが必要です。

4-2. 自動更新とローテーション設計

ACM管理証明書の自動更新は、ACMがバックグラウンドで新しいCSRを生成し、Private CAの IssueCertificate APIを呼び出すことで実現されます。ALB・API Gateway・CloudFrontなどACM統合サービスでは証明書のデプロイも自動で行われ、アプリケーションを停止せずに透過的な更新が完了します。

手動管理証明書のローテーション設計では、Lambda + EventBridgeの組み合わせが一般的です。以下のアーキテクチャが推奨されます。

1. EventBridge Scheduler で毎日定時に監視Lambdaを起動します。
2. 監視LambdaがACM APIを呼び出し、有効期限が45日以内の証明書を検出します。
3. 更新対象が見つかった場合、更新Lambdaを起動してCSR生成 → IssueCertificate → 新証明書を配布します。
4. 更新完了後、SNS通知で担当者にアラートを送付します。

Secrets Managerとの統合により、アプリケーション側での証明書ローテーションをさらに透過化できます。証明書と秘密鍵をSecrets Managerに格納し、アプリケーションは起動時に最新の証明書を取得する設計にすることで、ローテーション時のデプロイ作業を不要にできます。Secrets Managerのローテーション機能と組み合わせると、更新・配布・失効の一連の流れを完全に自動化できます。

# 証明書をSecrets Managerに格納する例
aws secretsmanager put-secret-value \
  --secret-id /app/tls/certificate \
  --secret-string "{
 \"certificate\": \"$(cat certificate.pem | base64)\",
 \"private_key\": \"$(cat private.key | base64)\",
 \"ca_chain\": \"$(cat ca-chain.pem | base64)\"
  }"

4-3. 失効管理: CRL vs OCSP

証明書の失効は、鍵の漏洩・従業員の退職・システム廃止などの際に必要となります。AWS Private CAでは CRL (Certificate Revocation List) と OCSP (Online Certificate Status Protocol) の2種類の失効確認方式をサポートしています。

CRL (Certificate Revocation List)

CRLは失効した証明書の一覧をS3バケットに定期発行するリスト形式の方式です。

• 更新タイミング: マネージドCRLは証明書の失効後約30分以内にS3バケットへ反映されます。更新失敗時は15分間隔で再試行されます。
• クライアント動作: クライアントはCRL配布ポイント (CDP) URLからCRLをダウンロードし、ローカルにキャッシュして証明書の有効性を確認します。
• S3バケット要件: CRLを配置するS3バケットはパブリック読み取りを許可する必要があります。クライアントがCRLを取得するためのアクセス権が必要なためです。
• クライアントキャッシュの注意点: クライアントがCRLをキャッシュしている場合、失効直後は古いCRLを参照し続けることがあります。キャッシュのTTLを考慮した上で失効の即時性を評価してください。

CRLの有効化は、CA作成時または後から update-certificate-authority コマンドで設定できます。

aws acm-pca update-certificate-authority \
  --certificate-authority-arn <CA_ARN> \
  --revocation-configuration '{
 "CrlConfiguration": {
"Enabled": true,
"ExpirationInDays": 7,
"S3BucketName": "my-crl-bucket"
 }
  }'

OCSP (Online Certificate Status Protocol)

OCSPはクライアントがリアルタイムで証明書の有効性をレスポンダーに問い合わせるプロトコルです。AWS Private CAはマネージドOCSPを提供しており、OCSPレスポンダーの運用管理をAWSに委任できます。

• 反映遅延: マネージドOCSPの失効反映は最大60分かかります。
• 設定: CA証明書にAIA (Authority Information Access) 拡張が自動的に設定され、クライアントはOCSPエンドポイントURLを自動取得します。
• コスト: マネージドOCSPはリクエスト数に応じた従量課金です。

CRL vs OCSP の使い分け

Roles Anywhereとの統合ではCRLのみがサポートされており、OCSPは利用できません。Roles Anywhere環境のCA設計では必ずCRLを有効にしてください。

短期証明書 (Short-lived Certificates) による失効管理の簡素化

有効期間が7日以下の短期証明書は、CRL・OCSPによる明示的な失効管理が不要となる設計を採用できます。証明書の有効期限が実質的な失効手段として機能するため、失効リストの管理コストを大幅に削減できます。

短期CAモード (Short-lived certificate mode) は月額50ドル (汎用CA = 400ドル) で利用でき、コスト面でも優位性があります。Roles Anywhere統合では特に有効で、IAMロールへのアクセスを短期間の証明書により制御し、最小権限の原則を実現できます。

# 短期証明書の発行例 (有効期間7日)
aws acm-pca issue-certificate \
  --certificate-authority-arn <SHORT_LIVED_CA_ARN> \
  --csr fileb://csr.pem \
  --signing-algorithm SHA256WITHRSA \
  --template-arn arn:aws:acm-pca:::template/EndEntityClientAuthCertificate/V1 \
  --validity Value=7,Type=DAYS

4-4. 期限切れ検知と監視 (EventBridge/Config)

証明書の期限切れを防ぐための監視体制は、複数のレイヤーで構築することが重要です。

AWS Config ルール acm-certificate-expiration-check を使用すると、有効期限が指定した日数以内に迫った証明書を自動検出できます。検出された証明書はConfig Dashboardに表示され、Security Hubへの統合も可能です。

# AWS Config ルールの作成 (期限30日以内を検出)
aws configservice put-config-rule \
  --config-rule '{
 "ConfigRuleName": "acm-certificate-expiration-check",
 "Source": {
"Owner": "AWS",
"SourceIdentifier": "ACM_CERTIFICATE_EXPIRATION_CHECK"
 },
 "InputParameters": "{\"daysToExpiration\": \"30\"}"
  }'

EventBridge ルール を使用すると、ACMが自動的に発行する ACM Certificate Approaching Expiry イベントを受信できます。このイベントは有効期限の45日前・30日前・15日前に発行され、SNS経由で担当者へのメール通知やLambda起動に活用できます。

# EventBridge ルールの作成例
aws events put-rule \
  --name "acm-certificate-expiry-alert" \
  --event-pattern '{
 "source": ["aws.acm"],
 "detail-type": ["ACM Certificate Approaching Expiry"]
  }' \
  --state ENABLED

CloudWatch Alarm では、カスタムメトリクスを使用して証明書の有効期限までの残日数を監視できます。監視スクリプトをLambdaで定期実行し、残日数をメトリクスとして送信することで、アラートのしきい値を柔軟に設定できます。

Security Hub と連携することで、証明書の有効期限切れリスクをセキュリティの観点から一元管理できます。Security HubのFindingsとして証明書の期限切れ警告が表示され、他のセキュリティインシデントと同一のダッシュボードで管理できます。

複数のAWSアカウントにわたる証明書を管理するマルチアカウント構成では、Organizations + Config + Security Hubの組み合わせで全アカウントの証明書有効期限を一元監視する設計が推奨されます。

5. mTLS at Scale

mTLS (Mutual TLS: 相互TLS認証) は、通常のTLSがサーバー証明書のみを検証するのに対し、クライアント側も証明書を提示してサーバーが検証する双方向認証の仕組みです。ゼロトラストアーキテクチャの中核となる技術であり、「ネットワーク境界を信頼しない」原則に基づいてサービス間通信・外部クライアント・オンプレミス連携のすべてを証明書ベースで認証します。

AWS Private CAは、エンタープライズ環境におけるmTLSの証明書発行基盤として機能し、ALB・API Gateway・Roles Anywhere・IoT Coreなど複数のAWSサービスとネイティブに統合されています。大規模なクライアント証明書の発行・配布・失効管理をプログラマブルに運用できる点が、従来のオンプレミスPKIとの大きな差異です。

5-1. ALB mutual TLS (passthrough / verify with trust store)

Application Load Balancerは2023年11月のGA以降、ALBレイヤーでのmTLS検証をサポートしています。実装モードはpassthroughとverifyの2種類があり、ユースケースに応じて使い分けます。

passthroughモード

passthroughモードでは、ALBはTLSを終端せずにクライアント証明書をそのままバックエンドへ転送します。ALB自体はクライアント証明書を検証せず、バックエンドアプリケーション (ECSコンテナ・EC2等) がTLS終端とクライアント証明書検証の双方を担います。

このモードが適するのは、バックエンドで独自の証明書検証ロジック (組織固有のOIDチェック・証明書ピンニング等) が必要な場合や、ALBの信頼ストアが対応しない独自CA証明書を検証するケースです。バックエンドでTLS終端するためSSL/TLSオフロードの恩恵は受けられませんが、証明書検証の完全なコントロールが維持されます。

verifyモードとトラストストア

verifyモードでは、ALBがトラストストアを参照してクライアント証明書を検証し、その結果をバックエンドにヘッダで伝達します。ALBがTLSを終端するため、バックエンドはHTTPで通信しながらmTLSの恩恵を受けられます。

トラストストアはACMコンソール (Certificates Store) で管理します。設定手順は以下のとおりです。

1. AWS Private CAで発行したCA証明書チェーン (PEMフォーマット) をS3バケットにアップロードします。
2. ACMコンソールの「Trust stores」からトラストストアを作成し、S3のCAバンドルURIを指定します。
3. ALBリスナー (ポート443) の設定で「Mutual authentication」を有効化し、verifyモードとトラストストアARNを指定します。

クライアント証明書の検証に失敗した場合、ALBはデフォルトで503を返します。routing.http.x-amzn-mtls-clientcert-validity ヘッダを確認することで、バックエンドでも検証結果を参照できます。

CRL連携による失効遮断

トラストストアにはCRL (Certificate Revocation List) S3 URIを登録できます。Private CAが失効後約30分以内にCRLをS3へ反映するため、ALBはその失効情報を参照します。トラストストアのCRL有効化により、失効済みクライアント証明書による不正アクセスを遮断できます。

# トラストストア作成例 (AWS CLI)
aws elbv2 create-trust-store \
  --name my-mtls-trust-store \
  --ca-certificates-bundle-s3-bucket mybucket \
  --ca-certificates-bundle-s3-key ca-bundle.pem

# ALBリスナーにmTLS verifyモードを設定
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:... \
  --mutual-authentication Mode=verify,TrustStoreArn=arn:aws:elasticloadbalancing:...

5-2. API Gateway mutual TLS (REST/HTTP API・S3トラストストア)

API GatewayのmTLSはカスタムドメイン名に対して設定します。REST APIとHTTP APIの両方がサポートされており、S3にアップロードしたCA証明書バンドルをトラストストアとして参照します。

設定の基本フロー

まず、Private CAで発行したCA証明書チェーン (PEMファイル) をS3バケットに配置します。次にAPI Gatewayのカスタムドメイン名を作成または更新する際、mutualTlsAuthenticationオブジェクトにS3 URIを指定します。

# カスタムドメインへのmTLS設定
aws apigateway create-domain-name \
  --domain-name api.example.com \
  --regional-certificate-arn arn:aws:acm:... \
  --mutual-tls-authentication truststoreUri=s3://mybucket/ca-bundle.pem

重要な制約事項

API GatewayのmTLSにはいくつかの制約があります。トラストストアに登録できる証明書チェーンの深さは最大4段 (ルートCA + 中間CA最大2段 + エンドエンティティ) です。またプライベートエンドポイントはmTLSに対応していないため、mTLSを利用する場合はリージョナルエンドポイントまたはエッジ最適化エンドポイントを選択する必要があります。

CloudFront distributions でのオリジンmTLS

CloudFrontのオリジンとしてAPI GatewayやALBを配置する構成では、CloudFrontとオリジン間でもmTLSを構成できます。CloudFrontはOrigin Access Controlではなく、カスタムSSL証明書をオリジン設定に指定する方式でオリジンmTLSを実現します。CloudFrontからオリジンへの接続にクライアント証明書を提示させることで、CloudFront以外からのオリジン直接アクセスを防止できます。

トラストストアのバージョン管理

S3オブジェクトのバージョニングを有効にすることで、CA証明書バンドルの世代管理が可能になります。API Gatewayはバージョン指定のS3 URIも受け入れるため、ロールバックや段階的なCA更新が容易になります。古いCAと新しいCAを一時的にバンドルに共存させることでカットオーバー期間中の断絶を回避できます。

5-3. Roles Anywhere TrustAnchor連携

AWS IAM Roles Anywhereは、AWSの外部で動作するワークロード (オンプレミスサーバー・他クラウド・ハイブリッド環境) がX.509証明書を使用してAWSロールを引き受けられる仕組みです。Private CAとのネイティブ統合により、社内PKIからのシームレスな認証連携が可能になります。

TrustAnchorの設定

Roles Anywhereの設定は「Trust Anchor」「Profile」「Role」の3要素で構成されます。Trust AnchorにPrivate CAのARNを直接指定することで、そのCAが発行した証明書を持つワークロードがAWSを信頼できるようになります。

# Trust AnchorにPrivate CAを指定
aws rolesanywhere create-trust-anchor \
  --name my-trust-anchor \
  --source \
 sourceType=AWS_ACM_PCA,sourceData={acmPcaArn=arn:aws:acm-pca:...}
  --enabled

CRL必須化の背景

Roles AnywhereはOCSP (Online Certificate Status Protocol) をサポートしていません。CRLのみが失効確認手段となるため、Private CA構築時にCRL配布ポイントを必ず有効化する必要があります。CRLなしの構成では、秘密鍵漏洩時に証明書を失効させても即時反映されず、攻撃者が有効期限まで不正にAWSロールを引き受け続けるリスクがあります。

CRLの更新間隔はPrivate CAの設定で制御できます。デフォルトは7日ですが、高セキュリティ要件では1日以下の設定を推奨します。CRLの最大サイズは32MBのため、大規模な証明書失効が発生する環境では定期的にCRLサイズを監視してください。

iam_rolesanywhere_credential_helperによる認証フロー

オンプレミスワークロードは aws_signing_helper (credential helper) を使用して一時的なAWS認証情報を取得します。このヘルパーはX.509証明書と秘密鍵を指定して Roles Anywhereの CreateSession APIを呼び出し、STS一時クレデンシャルを取得します。取得した認証情報は ~/.aws/credentials や環境変数として設定し、通常のAWS CLIおよびSDKで利用できます。

Roles Anywhereの詳細なセットアップ手順については、IAM Roles Anywhere専門記事を参照してください。本セクションではPrivate CAとのTrustAnchor連携に焦点を当てています。

5-4. サービス間mTLS・IoTでの大規模証明書配布

マイクロサービス間mTLSの設計パターン

コンテナオーケストレーション環境 (ECS/EKS) では、サービス間の東西通信にmTLSを適用することでゼロトラストネットワークを実現できます。

ECS環境では、サービスごとにPrivate CAからクライアント・サーバー兼用の証明書を発行し、ECSタスク定義のenvironmentまたはSecrets Managerを通じて証明書をコンテナに提供します。証明書のローテーションはEventBridgeSchedulerとLambdaで自動化し、サービスの無停止での証明書更新を実現します。

EKS環境ではAWS ACM PCA Issuerプラグイン (cert-managerと連携) を使用することで、KubernetesのCertificateリソースからPrivate CA証明書を直接発行できます。サービスアカウントごとに証明書を発行し、Kubernetesシークレットとしてマウントすることで、Podレベルでのmutable identity管理が可能になります。

AWS App Mesh + Envoy によるmTLS自動化

AWS App Meshは、Envoyプロキシをサービス間通信のサイドカーとして注入し、アプリケーションコードを変更せずにmTLSを適用します。バーチャルノードの tls設定でPrivate CA ARNを指定すると、App MeshがEnvoyにSDS (Secret Discovery Service) 経由でクライアント証明書を自動配布します。証明書の更新もApp Mesh + Envoyのスタックが自律的に処理するため、運用負荷が大幅に軽減されます。

IoT Core での大規模デバイス証明書管理

IoT機器のような大量デバイスに個別証明書を配布する場合、JITR (Just-In-Time Registration) とJITP (Just-In-Time Provisioning) が有効です。

JITR (Just-In-Time Registration) は、デバイスがAWS IoT Coreへ初めて接続した際に、提示されたクライアント証明書をPrivate CAのCA証明書で検証し、自動登録する仕組みです。デバイス証明書をAWS IoTコンソールで事前登録することなく、証明書を持つデバイスが初回接続時に自動的にThingに関連付けられます。JITR後のポリシー付与はLambdaで実装し、デバイス証明書のCNやSANに基づいたきめ細かいIoTポリシーを適用できます。

JITP (Just-In-Time Provisioning) はJITRをさらに拡張し、初回接続時にThingの登録とIoTポリシーのアタッチ・Thing Groupへの追加までを自動実行します。プロビジョニングテンプレートをJSON形式で定義し、CA証明書に関連付けることで、証明書のSAN/CN値を使ったデバイス固有のリソース名生成が可能になります。

# CA証明書をIoT Coreに登録 (JITR/JITP有効化)
aws iot register-ca-certificate \
  --ca-certificate file://ca-cert.pem \
  --verification-certificate file://verification-cert.pem \
  --allow-auto-registration \
  --registration-config file://provisioning-template.json

大規模証明書配布の運用ポイント

数万台規模のデバイス・コンテナへの証明書配布では、以下の点に注意します。Private CAの証明書発行レートはデフォルトで25 TPS (Transactions per Second) です。大量発行が必要な場合はサービスクォータの引き上げをリクエストしてください。

失効管理では、CRLのサイズ肥大化を防ぐため、有効期限の短い短期証明書 (7日〜30日) を採用してローテーション頻度を上げる設計が有効です。Private CAの短期証明書モードを利用することで月額コストも削減 (月額400ドル→50ドル) できます。短期証明書はそもそも失効前に期限が切れる設計のため、CRLへの依存度が下がりオペレーショナルリスクも低減します。

mTLS証明書の可視化と監視

大規模なmTLS環境では、発行済み証明書の有効期限・失効状態・利用サービスの一覧を常時把握することが重要です。AWS Security Hubと連携し、有効期限30日以内の証明書をFindingとして自動検出する構成を推奨します。また、CloudTrailのIssueCertificateイベントを監視し、予期しない証明書発行を検知するアラートを設定してください。

証明書のライフサイクル全体をAWS Config集約から可視化し、マルチアカウント構成でも孤立した失効済み証明書を残存させないよう一元管理することが重要です。エンタープライズ規模のmTLS at Scaleを安全に運用するための基盤となります。

これらの仕組みを組み合わせることで、ALBからAPI Gateway・Roles Anywhere・IoT Coreまで、AWS上のすべての通信経路にゼロトラストmTLSを適用できます。

6. 運用・監査・コスト管理

6-1. 監査レポートとCloudTrail

AWS Private CAで発行した証明書の証跡を管理するには、監査レポートとCloudTrailの2つの仕組みを組み合わせます。

監査レポートの設定と活用

AWS Private CAの監査レポートは、CAが発行または失効した証明書のリストをS3バケットにエクスポートする機能です。監査レポートは随時生成でき、発行済み証明書の棚卸しやコンプライアンス監査に使用します。

aws acm-pca create-certificate-authority-audit-report \
  --certificate-authority-arn arn:aws:acm-pca:ap-northeast-1:123456789012:certificate-authority/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX \
  --s3-bucket-name my-pca-audit-reports \
  --audit-report-response-format JSON

レポートはJSON形式またはCSV形式で出力され、証明書のシリアル番号・発行日時・有効期限・失効状態を一覧で確認できます。S3バケットにはSSE-S3/SSE-KMSいずれかの暗号化を設定し、バケットポリシーでAWS Private CAサービスプリンシパル（acm-pca.amazonaws.com）からの書き込みを許可する必要があります。

監査レポートは四半期ごとの定期生成を推奨します。S3ライフサイクルポリシーと組み合わせてGlacierへのアーカイブを設定することで、長期保管コストを抑えながらコンプライアンス要件を満たせます。

CloudTrail統合による操作ログ

AWS Private CAはAWS CloudTrailと統合されており、CAの作成・削除・証明書発行・失効・CRL更新などのすべての管理操作がCloudTrailのイベントログに記録されます。主要なCloudTrailイベントは以下のとおりです。

特にIssueCertificateイベントは、どのIAMロールやユーザーが何のテンプレートで証明書を発行したかを確認できるため、不正発行の検知に活用できます。CloudTrailのイベントをAmazon EventBridgeにルーティングし、特定のCAから大量発行が行われた場合にAmazon SNSでアラートを送信する自動検知も構築できます。

期限切れアラートの設定

Certificate Managerはデフォルトで、有効期限が45日・30日・15日・7日・3日・1日前になるとAWS HealthダッシュボードとEventBridgeにACM Certificate Approaching Expirationイベントを送信します。EventBridgeルールでこのイベントを検知し、SNSトピックに転送することでメールやSlackへの通知を設定できます。

Private CA発行の証明書でACM管理対象でないものについては、AWS Configカスタムルールまたはシステムズマネージャーのインベントリを使って定期的に有効期限をチェックする独自の監視を組み込む必要があります。

Security Hubとの連携

AWS Security HubはACMのacm-certificate-expiration-checkマネージドルールに対応しており、有効期限が指定日数以内に迫った証明書をFindingとして報告します。Security Hubへの集約により、証明書の期限切れリスクを他のセキュリティインシデントと同一のダッシュボードで一元管理できます。マルチアカウント構成では、Organizations経由でSecurity Hubに全アカウントの証明書状態を集約できます。

6-2. 料金体系の整理

AWS Private CAの料金は「CA月額料金」と「証明書従量課金」の2層構造です。事前に料金体系を正確に把握しておかないと、予想外のコストが発生します。

CA月額料金

AWS Private CAではCAの稼働状態に応じて月額料金が発生します。

汎用CAと短期CAモードの大きな違いは、発行できる証明書の有効期間にあります。短期CAモードでは証明書の最大有効期間が7日に制限される代わり、CA月額料金が1/8になります。失効管理の手間を省くために証明書の有効期間を短くするアーキテクチャを採用する場合は、短期CAモードの利用が有効です。

CAは稼働しているだけで月額料金が発生するため、テスト用や開発用のCAを本番環境と同じアカウントで長期間稼働させないよう注意が必要です。不要になったCAは速やかに削除するか、無効化（DISABLED）状態に変更して証明書発行を停止させます。

証明書従量課金

発行する証明書の枚数に応じた従量課金が加算されます。料金は1ヶ月間の発行枚数に応じて3段階の逓減方式になっています。

最新の正確な料金はAWSの公式料金ページで確認してください。大量発行が見込まれる用途（IoTデバイス証明書・サービスメッシュの短期証明書など）では、月間発行枚数が第3段階に達するとコストが大幅に下がります。

マネージドOCSPの従量課金

マネージドOCSPを有効化している場合、OCSPリクエスト数に応じた追加料金が発生します。大量のクライアントがOCSPで証明書有効性を確認する環境では、OCSPリクエスト数も事前見積もりに含めてください。CRLのみを使用する場合、OCSPの従量課金は発生しません。

30日無料枠

AWS Private CAでCAを新規作成すると、30日間の無料試用期間が適用されます。この期間中はCA月額料金が無料となり、発行した証明書も最大1,000枚まで無料です。新しいPKI基盤の設計検証や本番移行前の動作確認にこの無料枠を活用できます。

ただし無料枠終了後は翌月初日から通常の月額料金が発生するため、テストが完了したCAは忘れずに削除します。複数のテストCAを作成した場合、それぞれで30日の無料枠が適用されますが、不要なCAを放置すると無料期間終了後に月額料金が積み重なります。

6-3. コスト最適化パターン

PKI規模が拡大すると、証明書発行コストは無視できない水準になります。以下のパターンを組み合わせることでコストを最小化できます。

パターン1: 短期証明書と短期CAモードの組み合わせ

サービスメッシュやIoTデバイスのように有効期間24時間以下の短期証明書を大量発行する用途では、汎用CA（$400/月）ではなく短期CAモード（$50/月）を利用します。月額コストを88%削減できます。

短期証明書を採用すると失効リストの管理が不要になる副次効果もあります。有効期間が短ければ証明書が漏洩しても影響時間が限定されるため、CRLやOCSPによる明示的な失効管理を省略できるケースがあります。

パターン2: RAM共有による複数アカウントへのCA共有

AWS Resource Access Manager（RAM）を使ってPrivate CAを複数のAWSアカウントに共有することで、アカウントごとにCAを作成するコストを排除できます。組織内の開発・ステージング・本番の各アカウントで同じ下位CAを共有し、CA月額料金を集約できます。

共有設定はCA作成後にRAMリソース共有を通じて実施し、受け側アカウントではIAMポリシーで発行権限を制御します。ルートCAは共有せず、下位CAのみを各アカウントに共有する設計が一般的なベストプラクティスです。

パターン3: CA数の最適化

用途別にCAを細分化しすぎると月額料金が積み重なります。次のCA分割基準を参考に、必要最小限のCA数に整理します。

• セキュリティドメインの境界（本番/非本番）でCAを分離する
• 証明書ポリシーが異なる用途（コード署名用・mTLS用）はCAを分ける
• 地理的要件（コンプライアンス上の国別分離）がある場合のみリージョン別CAを設ける
• 開発用は短期CAモードの1つのCAに集約する

本番運用チェックリスト

本番環境でAWS Private CAを運用する際の定期確認項目を以下に示します。

CA証明書自体の有効期限はデフォルト10年ですが、下位CAは3〜5年で設定するケースが多いです。CA証明書の失効・更新はサービス全体への影響が大きいため、有効期限管理を怠らないことが重要です。

不要CAの削除と無効化の手順

稼働が不要になったCAはすぐに削除するか、無効化します。削除前には必ず発行済み証明書がすべて失効または有効期限切れであることを確認します。

# CAを無効化（証明書発行を停止・月額料金は発生し続ける）
aws acm-pca update-certificate-authority \
  --certificate-authority-arn <CA_ARN> \
  --status DISABLED

# CAを削除（削除から30日以内なら復元可能）
aws acm-pca delete-certificate-authority \
  --certificate-authority-arn <CA_ARN> \
  --permanent-deletion-time-in-days 30

削除は30日の猶予期間後に永続的に実行されます。この猶予期間中は削除をキャンセルしてCAを復元できます。誤削除のリスクに備えるためにも、デフォルトの30日猶予期間を短縮せずに使うことを推奨します。

マルチリージョン構成でのコスト考慮点

高可用性要件からCA自体をマルチリージョンに展開する場合、リージョンごとに月額料金が発生します。ディザスタリカバリ目的でセカンダリリージョンにCAを配置するコストを正確に見積もった上で、必要性を判断することが重要です。多くの場合、プライマリリージョンのCA冗長性はAWS Private CAのマネージドSLAで担保されるため、DR用にセカンダリCAを設けなくてもリスク許容範囲に収まります。コスト最適化の観点では、不要なマルチリージョンCA展開を避け、単一リージョンのマネージド高可用性を活用することを推奨します。

7. 実戦統合パターン: PKI連環hub設計

7-1. PKI連環hubの全体設計

AWS Private CAをPKIの中心ハブとして機能させ、CloudHSM・Roles Anywhere・AWS Signerと組み合わせた「PKI連環hub」アーキテクチャは、エンタープライズ環境でのID管理とコード署名を統合的に実現します。

PKI連環hubを構成するコンポーネントとその役割は次のとおりです。

CloudHSM（FIPS 140-2 Level 3鍵保護）
  ↓ Custom Key Store（ルートCA秘密鍵をHSMで保護）
AWS Private CA（ルートCA: DISABLED状態で長期保護）
  ↓ CA証明書署名
AWS Private CA（下位CA: ACTIVE・証明書発行ハブ）
  ├──→ Roles Anywhere（Trust Anchor）→ ワークロードIDフェデレーション
  ├──→ AWS Signer（コード署名証明書）→ Lambda/コンテナ署名
  └──→ ALB / App Mesh（mTLS証明書）→ サービス間相互認証

この設計の思想は、「信頼のRoot of TrustをCloudHSMに集約し、AWS Private CAをPKIの中心ハブとして機能させ、各AWSサービスへ証明書ベースの認証を放射状に提供する」ことにあります。

PKI連環hubの設計原則

• 単一の信頼起点: ルートCA秘密鍵をCloudHSMで保護することで、組織全体のPKI信頼の起点が1箇所に集約されます。
• 下位CAによる役割分離: コード署名用・mTLS用・ワークロードID用と目的別に下位CAまたはテンプレートを使い分けます。
• 自動化による運用負荷低減: cert-manager・ACM統合・IAM Roles Anywhereの自動更新により、手動証明書管理をなくします。
• 監査の一元化: CloudTrailを通じて全証明書発行・失効・使用ログを一元的に記録します。

7-2. CloudHSM保護ルート鍵とPrivate CAの統合

Custom Key Storeの設定

AWS Private CAのルートCA秘密鍵をCloudHSMで保護するには、CloudHSMクラスターをAWS KMSのCustom Key Storeとして設定します。この構成でCA秘密鍵がCloudHSMのHSM境界外に平文で取り出されることを防げます。

Custom Key Storeを使用したCA構築の手順は次のとおりです。

1. CloudHSMクラスターを2台以上のHSMで構成し、KMS Custom Key Storeとの接続を確立します。
2. Custom Key Store上でCA秘密鍵に対応するKMSキーを作成します（RSA 2048/4096またはEC P256/P384）。
3. AWS Private CAのCA作成APIでKeyStorageSecurityStandard: CCPC_LEVEL_1とCloudHSM連携のKMSキーARNを指定します。
4. ルートCA用のCSRを生成し、RootCACertificate/V1テンプレートで自己署名証明書を発行します。
5. 下位CAのCSRをルートCAで署名し（SubordinateCACertificate_PathLen0/V1）、下位CA証明書をインポートします。
6. ルートCAをDISABLEDにして長期保護モードへ移行します。

# Custom Key Store連携のCA作成例
aws acm-pca create-certificate-authority \
  --certificate-authority-configuration \
 KeyAlgorithm=RSA_4096,SigningAlgorithm=SHA256WITHRSA,\
 Subject='{Country=JP,Organization=ExampleCorp,CommonName=ExampleRootCA}' \
  --certificate-authority-type ROOT \
  --key-storage-security-standard CCPC_LEVEL_1

CloudHSMによるCA鍵保護のメリット

• FIPS 140-2 Level 3認定のHSMで鍵が保護されます。
• 秘密鍵はCloudHSMクラスター外に平文で取り出せません。
• CloudTrailでKMS経由の鍵使用が全件記録され、監査証跡が完全に残ります。
• CloudHSMクラスターが停止するとCA操作が失敗するため、ルートCAをDISABLEDにする運用と組み合わせることで実質的なオフライン保護を実現できます。

高可用性の確保

本番環境ではCloudHSMクラスターを複数のAZに2台以上のHSMを配置して冗長化します。CloudHSMクラスターが全滅するとCA秘密鍵へのアクセスが不可能になり証明書更新も止まります。CloudHSMのバックアップポリシーとAZをまたいだクラスター冗長化を事前に設計してください。

7-3. Roles Anywhere信頼・Signer署名への連環

Roles Anywhere Trust Anchorとの統合

AWS IAM Roles Anywhereは、オンプレミスサーバー・コンテナ・VMなどAWS外のワークロードがX.509証明書を使ってAWSの一時的なIAM認証情報（STS）を取得できるサービスです。

Private CAをRoles AnywhereのTrust Anchorに設定する手順は次のとおりです。

1. Roles AnywhereのTrust Anchorを作成し、タイプ「AWS Private CA」を選択します。
2. Trust AnchorにPrivate CAのCA ARNを指定します（ルートCAまたは下位CA）。
3. IAMロールにRoles Anywhere用の信頼ポリシーを設定します。
4. ワークロードにPrivate CA発行のX.509証明書と秘密鍵をプロビジョニングします。
5. aws_signing_helper credential-processでSTSの一時認証情報を取得し、AWS CLIやSDKから利用します。

Roles AnywhereはCRLによる失効チェックに対応していますが、OCSPには対応していません。Private CAのCRL S3バケットを適切に設定し、Roles AnywhereがCRLを取得できるようS3バケットのパブリック読み取りアクセスを有効にしてください。

AWS Signerとの統合

AWS Signerはコード・コンテナイメージのデジタル署名と検証を管理するサービスです。Private CA発行のコード署名証明書をAWS Signerのプロファイルに紐づけることで、Lambda・コンテナイメージへの署名を組織内CA発行の証明書で一元管理できます。

Private CAとAWS Signerの統合フローは次のとおりです。

1. Private CAでCodeSigningCertificate/V1テンプレートを使用してコード署名証明書を発行します。
2. AWS Signerの署名プロファイルを作成し、発行した証明書のARNを設定します。
3. CI/CDパイプライン（CodePipeline等）からAWS SignerのStartSigningJob APIを呼び出してパッケージに署名します。
4. Lambda関数のコード署名設定（CodeSigningConfig）に署名プロファイルARNを設定し、署名検証を有効化します。

# Lambda コード署名設定を作成
aws lambda create-code-signing-config \
  --allowed-publishers SigningProfileVersionArns=arn:aws:signer:ap-northeast-1:123456789012:/signing-profiles/MyProfile/xxxx \
  --code-signing-policies UntrustedArtifactOnDeployment=Enforce

7-4. 実装パターン

パターンA: EKS/コンテナmTLS

EKSワークロード間のmTLS認証にPrivate CAを使用する構成です。

cert-manager（Kubernetes）
  ↓ CertificateRequest
AWS Private CA Issuer（cert-manager plugin）
  ↓ IssueCertificate API
AWS Private CA（下位CA）→ 証明書発行
Pod A（クライアント証明書） ←→ Pod B（サーバー証明書）: mTLS相互認証

cert-managerとAWS Private CA Issuerプラグインを組み合わせることで、Kubernetes CertificateリソースからPrivate CA証明書を自動発行・更新できます。ALBとの組み合わせでは、ALBのmTLS機能（Trust Store）にPrivate CAのCA証明書チェーンを登録することでクライアント証明書検証をALBレイヤーで実施できます。

パターンB: CI/CDパイプライン署名ゲート

CodePipelineとAWS Signerを組み合わせた署名ゲートを実装します。

CodeCommit → CodeBuild（ビルド・テスト）
  ↓ AWS Signer（Private CA証明書で署名）
CodePipeline（署名検証ゲート）
  ↓ 署名検証PASS
Lambda（コード署名設定: 署名必須）

Private CA発行の証明書で署名されていないLambdaデプロイパッケージはデプロイをブロックできます。サプライチェーン攻撃への防御とコード改ざん検知の両方を実現する有効なパターンです。

パターンC: ハイブリッドワークロードのIAM認証

オンプレミスサーバーやEC2以外の環境からAWSリソースにアクセスするワークロードに対し、Roles Anywhereを経由したIAM認証を実装します。

オンプレミスサーバー（X.509証明書: Private CA発行）
  ↓ aws_signing_helper + Roles Anywhere
STSの一時認証情報 → AWSリソース（S3・DynamoDB・SSM等）

証明書の有効期間は短め（1〜30日）に設定し、自動更新の仕組みをワークロード側に組み込むことを推奨します。短期証明書モード（月額 $50）のCAを使用すれば、失効管理コストを削減しながらセキュリティを維持できます。

7-5. 設計上の注意点

CRL S3バケットのアクセス制御

Private CAのCRLはS3バケットに格納されます。クライアント（Roles Anywhere・mTLSエンドポイントなど）からCRLを取得できるよう、S3バケットのパブリック読み取りアクセス設定が必要です。CRLを取得できない場合、クライアント実装によっては証明書検証に失敗する場合があります。

{
  "Statement": [
 {
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-crl-bucket/crl/*"
 }
  ]
}

Roles AnywhereはCRLのみ対応

Roles AnywhereはOCSPによるリアルタイム失効チェックに対応していません。証明書失効時にRoles Anywhereの認証を無効化するには、CAのCRLを更新し、Roles AnywhereがCRLを取得・反映するまで（最大1時間程度）待つ必要があります。インシデント対応時のCRL更新手順をRunbookに事前記載しておくことを推奨します。

ルートCA秘密鍵の長期保護

CloudHSMを使用しない構成でも、ルートCAはDISABLED状態を維持し、下位CAへの署名時のみACTIVEに一時復帰させる運用を徹底してください。ルートCAのCA証明書が失効した場合、そのCAが発行した全ての下位CA・エンドエンティティ証明書が信頼失効します。ルートCA更新は計画的なメンテナンスウィンドウで実施し、変更管理プロセスの対象に含めてください。

証明書発行レート制限

AWS Private CAには証明書発行のレート制限があります。汎用CAの場合は1秒あたり最大25件、短期証明書モードでは1秒あたり最大5件が上限です。大量のコンテナ・IoTデバイスへの証明書プロビジョニングでは、この制限を考慮したバッチ処理・リトライ設計が必要です。Service Quotasから引き上げリクエストも可能です。

マルチリージョン対応

AWS Private CAはリージョナルサービスであり、CA自体はリージョンをまたいでレプリケートされません。グローバルな証明書発行が必要な場合は、各リージョンに下位CAを個別に作成し、同一のルートCAから署名することでグローバルな信頼チェーンを維持できます。

8. よくある詰まりポイントと解決策

本記事で解説したACM・AWS Private CAを実際に本番導入する際に、多くのエンジニアが直面するつまずきポイントと解決策をまとめます。設計・実装・運用の各フェーズで発生しやすいパターンを網羅しました。

8-1. 詰まりポイント

[詰まり1] Private CA作成直後に証明書を発行しようとして「CA is not in ACTIVE state」エラー

プライベートCAを作成した直後は CREATING ステータスから ACTIVE ステータスに遷移するまで数秒〜数分かかります。コンソールでCAのステータスがACTIVEに達したことを確認してから証明書を発行してください。自動化スクリプトでは、CAのステータスをポーリングして確認する処理を組み込む必要があります。

# CA STATUSがACTIVEになったかを確認するコマンド
aws acm-pca describe-certificate-authority--certificate-authority-arn <CA_ARN>--query 'CertificateAuthority.Status'--output text
# 出力: ACTIVE になるまで待機

[詰まり2] CRL配布用S3バケットのパブリックアクセスブロックが有効のままでCRLを取得できない

AWS Private CAのCRL (Certificate Revocation List) はS3バケットに配置されます。しかしS3バケットのデフォルト設定はパブリックアクセスブロックが有効になっているため、TLSクライアントがCRLを取得できず証明書の失効確認に失敗します。

解決策:
– CRL配布用S3バケットのパブリックアクセスブロックを解除し、バケットポリシーでCRLオブジェクトの読み取り権限を付与します。
– またはOCSP (オンライン証明書状態プロトコル) をCRLの代替または補完として有効化します。ただしOCSPは最大60分の反映遅延があります。

[詰まり3] OCSP有効化後も証明書失効がすぐに反映されない

OCSPはリアルタイムで失効状態を返すプロトコルですが、AWS Private CAのマネージドOCSPレスポンダはレスポンスをキャッシュするため、失効後 最大60分 の遅延が発生します。即時の失効反映が必要な本番環境では、OCSPだけでなくCRLも併用することでフォールバックを確保してください。

なお、CRLの更新頻度も約30分（デフォルト）であり、こちらもリアルタイム反映ではありません。緊急時の証明書失効では、失効後60分〜数時間は証明書が有効と認識される可能性を事前に織り込んだインシデント対応計画を策定しておくことを推奨します。

[詰まり4] RAM共有でCA発行権限を別アカウントに付与したが証明書を発行できない

AWS Resource Access Manager (RAM) でPrivate CAを共有するだけでは、別アカウントからの証明書発行権限が自動付与されません。RAM共有に加えて、プライベートCAのリソースポリシー に別アカウントへの発行権限を明示的に追加する必要があります。

{
  "Version": "2012-10-17",
  "Statement": [{
 "Effect": "Allow",
 "Principal": {
"AWS": "arn:aws:iam::<別アカウントID>:root"
 },
 "Action": [
"acm-pca:IssueCertificate",
"acm-pca:GetCertificate",
"acm-pca:DescribeCertificateAuthority"
 ],
 "Resource": "*"
  }]
}

[詰まり5] ALB mutual TLSでクライアント証明書検証が失敗する

ALBのmTLS機能を有効化しても、クライアント証明書の検証に失敗するケースがあります。主な原因は以下のとおりです。

• トラストストアの設定ミス: ALBのトラストストアにはPEM形式でCA証明書バンドルを登録する必要があります。中間CAを含む証明書チェーンが不完全な場合、検証に失敗します。
• 証明書チェーンの不完全さ: ルートCAのみ登録し、中間CAを省略すると検証が通りません。エンドエンティティ証明書の発行元CAまでのフルチェーンを含めてください。
• ALBのmTLSモード選択ミス: verify モードはチェーン全体を検証し、passthrough モードはバックエンドにそのまま渡します。用途に応じて正しいモードを選択してください。

[詰まり6] CA証明書の有効期限よりエンドエンティティ証明書の有効期限を長く設定してしまう

PKIの基本原則として、CA証明書の有効期間はそのCAが発行するエンドエンティティ証明書より長くなければなりません。 CA証明書の有効期限が先に切れると、そのCAが発行した全証明書も信頼されなくなります。

設計のガイドライン:
– ルートCA証明書: 10〜20年
– 下位CA証明書: 5〜10年
– エンドエンティティ証明書: 1〜2年（または短期モードで数時間〜数日）

AWS Private CAはCA有効期限を超えた証明書発行をAPIエラーで拒否しますが、設計段階で確認しておくことが重要です。

[詰まり7] CloudFront用ACM証明書をus-east-1以外のリージョンで作成してアタッチできない

CloudFrontのディストリビューションに設定するACM証明書は、必ずus-east-1 (バージニア北部) リージョンで作成する必要があります。 CloudFrontはグローバルサービスのため、証明書の管理もグローバルの基点となるバージニア北部リージョンに限定されています。

東京リージョン (ap-northeast-1) など他のリージョンで作成した証明書を選択しようとしても、CloudFrontのコンソール上に表示されません。マルチリージョン構成の場合でも、CloudFront用証明書はus-east-1で一括管理してください。

[詰まり8] ACMのDNS検証CNAMEを削除してしまい自動更新が失敗する

DNS検証で発行したACM証明書は、CNAMEレコードが存在し続ける限り自動更新されます。ドメイン移管・DNS設定変更・誤削除などでCNAMEが失われると、自動更新時に検証できなくなります。

確認と復旧手順:
– dig _acm-validations.example.com CNAME でCNAMEの存在を確認します。
– Route 53を使用している場合、ACMコンソールから「Route 53でレコードを作成」を再実行します。
– メール検証で発行した証明書は更新時に再承認が必要なため、期限前に承認メールを確認してください。

[詰まり9] Roles Anywhere設定でOCSPを有効化しているCAを指定したがCRLが必要だとわかる

AWS Roles AnywhereのTrust Anchorに設定したPrivate CAが、OCSPのみ有効化してCRLを無効化している場合、Roles Anywhereは失効確認ができません。Roles Anywhereは現在OCSPをサポートしておらず、CRLのみが失効確認手段です。

確認と解決手順:
1. Private CAのCRL設定を確認します: aws acm-pca describe-certificate-authority --certificate-authority-arn <CA_ARN> --query 'CertificateAuthority.RevocationConfiguration'
2. CRLが無効な場合、update-certificate-authority コマンドでCRLを有効化します。
3. CRL用S3バケットのパブリックアクセスを許可します（詰まり2参照）。
4. Roles AnywhereのTrust AnchorでCRLチェックが有効になっていることを確認します。

これはPrivate CA構築時の初期設定ミスとして最も多いパターンの一つです。Roles Anywhere統合を予定している場合、CA作成時に必ずCRLを有効化してください。

8-2. アンチパターン → 正解

❌ アンチパターン1: ルートCAを直接使ってエンドエンティティ証明書を発行する

ルートCAは最も信頼の高い証明書であり、漏洩した場合の影響が最大です。ルートCAを直接使ってサーバー証明書やクライアント証明書を発行すると、ルートCAの秘密鍵が頻繁に使用されることになりリスクが高まります。また、CAの失効や更新時の影響範囲が全証明書に及びます。

✅ 正解: ルートCA → 下位CA → エンドエンティティの階層構造を使う

ルートCAはDISABLED状態に置き、下位CA（サブCA）を作成し、日常的に証明書を発行します。下位CAに問題が発生した場合でも、ルートCAは安全なままです。ルートCAをオフライン相当の保護状態に置くことで、PIK基盤全体のリスクを分散できます。

❌ アンチパターン2: CRLを無効化してコストと管理コストを削減しようとする

CRL配布のためのS3ストレージコストを削減するためにCRLを無効化すると、証明書が漏洩・侵害された場合でも失効手段がなくなります。また、Roles Anywhereと統合するCA設計ではCRLが必須であり、後から有効化しようとするとCA設定変更が必要になります。

✅ 正解: CRLとOCSPの両方を有効化してフォールバックを確保する

CRLはオフライン環境でも参照できるため、OCSPが応答しない場合のフォールバックとして機能します。Roles Anywhere統合ではCRLのみがサポートされているため、将来の統合拡張を考慮してもCRLは必ず有効化してください。

❌ アンチパターン3: メール検証でACM証明書を発行して自動更新を期待する

メール検証で発行した証明書は自動更新されません。更新時は再度のメール承認が必要です。担当者の長期不在などによる更新の遅延で、証明書の期限切れを招くリスクがあります。

✅ 正解: DNS検証を選択する（DNS検証のみが自動更新に対応）

Route 53と統合する場合はACMコンソールから自動でCNAMEを設定できます。CNAMEが存在し続ける限り、ACMが自動的に証明書を更新します。本番環境では必ずDNS検証を選択することで、証明書期限切れのリスクを排除できます。

❌ アンチパターン4: Private CA SDKで直接発行した証明書の自動更新をACMに期待する

AWS Private CA SDKやCLIで直接発行した証明書はACMによる自動更新の対象外です。有効期限切れまで手動で管理するか、自前の更新スクリプトを組み込む必要があります。

✅ 正解: AWSサービスに関連付ける証明書はACM経由で発行し自動更新を活用する

ALB・NLB・API Gatewayなどに使用する証明書はACM経由でプライベートCAから発行することで、自動更新の恩恵を受けられます。自動更新対象はACM管理の証明書のみであることを常に意識して設計してください。

❌ アンチパターン5: mTLS設定でクライアント証明書の有効期間を無制限に長く設定する

長期の有効期間を設定したクライアント証明書は、紛失・漏洩時の影響が長期間に及びます。失効処理を実施しても、OCSP・CRLの遅延により即時反映されないケースもあるため、長期証明書は実質的なリスク要因になります。

✅ 正解: 短い有効期間 + 自動ローテーションを設計する

Private CAの短期証明書モード（Short-lived Certificate）を活用し、時間〜数日単位の短期証明書を採用してリスクを最小化します。証明書漏洩時の影響範囲を時間単位に抑えられ、失効管理の必要性も大幅に低減できます。

具体的な有効期間の設計例として、EKSのPod間mTLSでは24時間・CI/CDパイプラインのジョブ認証では1時間・IoTデバイスのフリート初期プロビジョニングでは7日間など、ユースケースに応じた短期設計が推奨されます。Podやジョブが短命である環境では、証明書の有効期間をワークロードのライフサイクルに合わせることで、有効期限到来時に自然と証明書が失効する設計を実現できます。このパターンにより、CRLやOCSPによる明示的な失効管理の運用コストを大幅に削減できます。

8-3. まとめ

エンタープライズPKI構築チェックリスト

本番導入前に以下の設計・設定項目を確認してください。

本記事ではAWS Certificate Manager (ACM) とAWS Private CAを使ったエンタープライズPKIの基礎から実践的な設計・運用まで体系的に解説しました。

ACMのパブリック証明書はAWS統合サービスとのシームレスな連携と無料での自動更新により、Webアプリケーション・API公開の証明書管理を大幅に簡素化します。AWS Private CAを組み合わせることで、内部システム・マイクロサービス間のmTLSやIoTデバイスへの証明書配布など、エンタープライズ規模のPKI基盤を構築できます。

PKI基盤の価値は「設定して終わり」ではなく、証明書ライフサイクルの継続的な管理にあります。CA階層の適切な設計、CRL/OCSPによる失効管理、EventBridgeを活用した証明書期限の監視・自動アラート、RAM共有によるマルチアカウント展開など、本記事で解説した内容を実践することで、セキュアで運用効率の高いPKI連環hub基盤を実現できます。

AWS Private CAはCloudHSM・Roles Anywhere・AWS Signerなど関連セキュリティサービスと深く連携しています。これらのサービスを組み合わせることで、エンタープライズに求められるゼロトラスト・サプライチェーンセキュリティを実現するPKI連環hubとして機能します。本記事がAWS上のセキュアなPKI基盤構築の一助になれば幸いです。

よくある詰まりポイントを振り返ると、大多数の問題は「CA階層設計の初期ミス」「S3バケットの公開設定漏れ」「DNS検証CNAME削除」「CloudFront用証明書リージョン誤り」の4パターンに集約されます。これらを事前にチェックリストとして確認することで、本番導入後のトラブルを大幅に削減できます。

スモールスタートの推奨アプローチとして、最初は短期証明書モード（月額$50）のCA1台から始め、mTLSとRoles Anywhere連携の動作確認をした後、ユースケースの拡大に合わせて汎用CA（$400/月）への移行やCA階層の拡充を検討することをお勧めします。証明書発行量が少ない段階では証明書従量課金も限定的であり、AWS Private CAのコストパフォーマンスは中〜大規模になるほど向上します。

なお、運用開始後はCRLの約30分・OCSPの最大60分という失効反映遅延を前提として、緊急失効時の対応手順をあらかじめ文書化しておくとインシデント対応が迅速になります。

本記事で解説した設計・運用パターンをベースに、組織固有の要件（コンプライアンス・監査・マルチリージョン）に合わせてカスタマイズを加えることで、エンタープライズグレードのPKI基盤を実現できます。

8-4. 関連記事

AWS CloudHSM 専用HSMで実現するエンタープライズ鍵管理 Vol1
AWS IAM Roles Anywhere ハイブリッドID管理 Vol1
AWS Signer コード署名とサプライチェーンセキュリティ Vol1
AWS セキュリティ本番運用 Vol3 IAM Access Analyzer・KMS・Secrets Manager
AWS セキュリティ本番運用 Vol4 Macie・Inspector・Network Firewall