はじめに
本ドキュメントの目的
このドキュメントは、AWS環境でルート証明書を取得・管理・運用するための実践的な手引きです。実例を通して、理解しやすく手順と考え方を示します。
対象読者
クラウドで証明書運用を担当するエンジニアや、セキュアな社内通信を構築したい開発者を想定しています。基礎的なAWS操作（コンソールや基本的なサービス理解）があると読みやすいです。
本書で扱う主なテーマ
- AWS Private CAを使ったプライベート認証局の構築例
- ALBでのmTLS（クライアント証明書）設定とルート証明書の役割
- Amazon Route 53を用いたドメインとACMの連携による証明書発行
- 証明書チェーンの仕組みと正しい配置方法
- プライベートCAの運用と更新手順
読み進め方の目安
各章は単独でも参照できる構成です。まず第2章で暗号化の考え方を掴み、第3〜5章で具体的な設定手順と注意点を順に確認すると実務で使いやすくなります。必要なコマンドや設定例は各章にまとめています。
AWSネットワーク内の通信を暗号化してみた
概要
AWS環境の内部通信を暗号化する実例を分かりやすく説明します。ここではAWS Private CA（プライベート証明書局）で発行した証明書を使い、内部ALBを通じてHTTPS化する手順を紹介します。
前提
- VPCとプライベートサブネットが作成済み
- Private CAでルート証明書をダウンロード済み
- Route 53にプライベートホストゾーンがあると設定が簡単です
手順（概要）
- 内部ALBの作成
- 内部（internal）のタイプで作成し、対象VPCとプライベートサブネットを指定します。
- セキュリティグループ設定
- ALBにはHTTPS(443)を許可し、通信元を必要な範囲に限定します。
- ACM証明書の用意
- Private CAで発行した証明書をACMにインポートするか、ACM Private CAと連携して証明書を発行します。ルート証明書はPrivate CAコンソールから入手します。
- HTTPSリスナー作成
- ALBにHTTPSリスナーを追加し、ACMの証明書を指定します。必要に応じてターゲットグループとの間もTLSにします。
- Route 53のAレコード変更
- 内部ホスト名をALBのDNS名に向けるAレコード（Alias）を作成します。これで内部ドメイン名でHTTPS接続できます。
注意点
- ALBとターゲット間も暗号化する場合、バックエンドに証明書を配置する必要があります。
- Private CAの信頼チェーンをクライアントに配布しておくと名前解決時や接続時の検証が正しく動作します。
- セキュリティグループやサブネットの設定ミスがないか必ず確認してください。
AWS ALBでのクライアント証明書認証の設定方法
概要
ALBでmTLS（相互TLS）を使うには、信頼する認証局（CA）チェーンと必要に応じてCRLを用意し、トラストストアとしてALBに指定します。ここでは実際の手順を分かりやすく説明します。
準備（CAチェーンとCRL）
- ルート証明書と中間証明書をPEM形式で用意します。順番はルート→中間の順に並べ、1つのファイルに結合します（例：cat root.pem inter.pem > ca-chain.pem）。
- 失効リスト（CRL）がある場合はPEM形式で用意します。
S3へアップロード
- 作成したca-chain.pem（とcrl.pem）をS3にアップロードします。
- ALBがアクセスできるようにS3バケットのアクセス権を設定してください。最小権限の原則で、ALBサービスが読み取れる設定にします。
トラストストア作成とALB設定
- AWSコンソールでトラストストアを作成し、S3上のCAチェーンとCRLのオブジェクトパスを指定します。
- ALBのHTTPSリスナーを編集して相互認証（mTLS）を有効にし、作成したトラストストアを選びます。
- 必要に応じてターゲットグループやルールを調整します。
動作確認とヘッダー情報
クライアント証明書で接続すると、ALBはリクエストにクライアント証明書関連の情報を追加して送信します。たとえば証明書のSubjectやIssuerなどが取得できます。アプリ側でこれらのヘッダーを確認して認可処理に利用してください。
注意点
- CAチェーンは正しい順序とPEM形式であることを再確認してください。
- CRLは更新が必要な場合があるため、運用での定期更新を考慮してください。
- S3の権限設定とALB設定変更の反映に時間がかかる場合があります。
Amazon Route 53で取得したドメインを使ってACM証明書を発行
概要
Route 53で管理しているドメインを使い、AWS Certificate Manager（ACM）で公開用のSSL/TLS証明書を発行する手順を分かりやすく説明します。DNS検証を使うと自動で検証レコードを作成できるため簡単です。
手順
- ACMコンソールを開く
- AWSマネジメントコンソールで「Certificate Manager」を選びます。
- 証明書をリクエスト
- 「Request a certificate」を押し、公衆（Public）証明書を選択します。
- ドメイン名を入力します（例: example.com と *.example.com を別々に入力してワイルドカードも可）。
- 検証方法でDNSを選択
- DNS検証を選びます。Route 53で取得したドメインなら自動でレコード作成できます。
- Route 53でレコードを作成
- ACM画面のオプションで「Create records in Route 53」を選ぶと、必要なCNAMEレコードを自動作成します。
- 検証完了と発行
- 通常数分で検証が完了し、状態が「Issued」になります。発行後、ALBやCloudFrontなどで利用できます。
注意点
- ドメインが同じAWSアカウントのRoute 53にあることを確認してください。
- ワイルドカード証明書はサブドメイン全体に有効ですがルートと併用するときは両方指定すると安心です。
- DNSの反映に時間がかかる場合がありますが、通常は数分〜数十分です。
AWS Certificate Managerを整理してみた
ACMとは
AWS Certificate Manager（ACM）は、SSL/TLS証明書を作成・保管・更新するマネージドサービスです。手動で証明書の更新やチェーン管理をする負担を減らせます。具体例として、ALB、CloudFront、API Gatewayなどで使います。
証明書チェーンの構造
ACMが発行するリーフ（サーバー）証明書は、複数の中間CAを介してAmazon Trust ServicesのルートCAから認証されます。流れは簡単で、リーフ → 中間CA（複数の場合あり）→ ルートCA、という階層です。証明書タイプに応じて割り当てられる中間CAが変わり、例えばRSA署名の証明書はRSA用の中間CA、ECDSA署名の証明書はECDSA用の中間CAを通ることが多いです。
パブリックとプライベートの違い
パブリック証明書はAmazon Trust Services発行で、ドメイン検証（DNSなど）を経て公開用途に使います。自動更新に対応し、AWS内の多くのサービスと自動連携します。プライベート証明書はACM Private CAで発行し、社内システムやサービス間のTLSに使えます。プライベートCAは自分で寿命やポリシーを管理できます。
運用上のポイント
・ACMはAWSサービス向けにチェーンを自動で扱います。外部で使う場合は中間証明書を含める必要があります。
・CloudFront用証明書はus-east-1で発行する点に注意してください。
・ACMで発行されたパブリック証明書は通常エクスポートできません。プライベート証明書はエクスポート可能です。
実務では、まず用途（公開サイトか内部向けか）を決め、対応するACMの機能を選ぶと管理が楽になります。
AWSにおけるSSL証明書の発行方法は？ACM活用のメリット
ACMとは
AWS Certificate Manager（ACM）は、SSL/TLS証明書とそのチェーンを管理するマネージドサービスです。ルート証明書からサーバー証明書までを扱い、手作業を減らして安全に運用できます。
発行方法（具体例）
- ドメイン所有の確認方法
- DNS検証：Route 53を使う場合、CNAMEレコードを自動で追加できます。例：example.comの証明書を申請すると、CNAMEを1つ追加して所有権を証明します。
- メール検証：ドメイン管理者宛に確認メールが送られます。
- 証明書の利用例
- ALB、CloudFront、API Gatewayなどに簡単に割り当てられます。CloudFrontは米国東部（us-east-1）での発行が必要です。
ACMを使うメリット
- 自動更新：期限切れの心配を減らせます。
- 無料（パブリック証明書）：AWSの各種サービスで追加料金なしで利用可能です。
- 統合の容易さ：ALBやCloudFrontと素早く連携できます。
- インポートも可能：既存の証明書をACMに取り込んで管理できます。
注意点
- ACMで発行したパブリック証明書はエクスポートできません。外部サーバーで使う場合は自分で発行するか、証明書をインポートしてください。
- プライベートCAが必要な場合は、ACM Private CAを利用する選択肢があります（有料）。
