AWS Certificate Manager（ACM）でTLS証明書を管理する

WebブラウザーとWebサイト、モバイルアプリとAPI、ロードバランサーとアプリケーションサーバーがネットワーク越しに通信するとき、TLSを使うと通信内容の暗号化、改ざんの検出、接続先サーバーの認証を実現できます。TLSのサーバー認証には証明書が必要です。証明書の準備だけでなく、秘密鍵の保護、証明書を使うAWSリソースへの関連付け、有効期限の管理、更新後の反映までが運用上の課題になります。

**AWS Certificate Manager（ACM）**は、AWSワークロードのパブリック証明書・プライベート証明書を発行、管理し、対応するAWSサービスへ関連付けるためのサービスです。統合サービス向けの証明書では、秘密鍵を利用者が直接扱わずにTLSを有効化し、証明書の更新をマネージドにできます。用途によっては、外部CAの証明書をインポートしたり、エクスポート可能な証明書をサーバーへ配備したりします。

ACMが扱う証明書と利用形態

証明書は、ドメイン名などの識別情報と公開鍵を結び付け、認証局（Certificate Authority、CA）が署名したデータです。TLSサーバーは証明書と対応する秘密鍵を使って接続相手に身元を示します。秘密鍵は公開鍵と対になる機密情報であり、漏えいや無断複製を防がなければなりません。

ACMでは、要件に合わせて次の形で証明書を利用できます。

利用形態	発行・保管の方法	主な利用先と鍵の扱い	更新上の注意
ACM発行の通常のパブリック証明書	ACMがパブリック証明書を発行し、秘密鍵を管理	CloudFront、Elastic Load Balancing（ALB/NLB）、API GatewayなどのACM統合サービスに関連付ける。秘密鍵をファイルとしてダウンロードする方式ではない	DNS検証などの条件を満たし、統合サービスに関連付けられている場合はACMのマネージド更新が可能
ACM発行のエクスポート可能なパブリック証明書	発行時にエクスポートを許可して証明書を作成	統合サービスでの利用に加え、証明書と秘密鍵をエクスポートしてEC2、コンテナ、オンプレミスサーバー等へ配備できる	ACMは証明書を更新するが、更新後の証明書を利用先へ配備する処理は利用者側で行う。エクスポート可能な証明書には追加料金がある
外部CAから取得してACMへインポートした証明書	外部で発行された証明書・秘密鍵・証明書チェーンをACMへ取り込む	ACM統合サービスへ関連付けられる。ACMから秘密鍵を取り出す目的ではない	ACMによるマネージド更新の対象外。更新済み証明書を取得し、ACMへ再インポートする
AWS Private CAが発行するプライベート証明書	AWS Private CAをプライベートCAとして構成し、ACM経由で発行する方法などがある	組織内部のサービスや端末間のTLS、クライアント認証などに利用する。ACM統合サービスに関連付けるほか、発行方式により証明書をエクスポートして独自サーバーへ配置できる	ACM経由で発行した証明書は条件に応じてマネージド更新可能。Private CA APIで直接発行した証明書はACMの自動更新とは別に管理する

通常のACM発行パブリック証明書とエクスポート可能なパブリック証明書は別の選択肢です。従来の「ACM発行証明書はEC2に置けない」という説明は通常の証明書についてのものです。エクスポート可能なパブリック証明書を新たに作成すれば、秘密鍵と証明書を取り出してEC2等に配置できます。この場合、秘密鍵の保管・アクセス制御は利用者の責任となり、証明書の更新後の配布も別途自動化しなければなりません。なお、以前に発行された通常の証明書を後からエクスポート可能に変更できるわけではありません。

ACM統合サービスにはElastic Load Balancing、CloudFront、API Gatewayなどがあります。統合サービスを使う場合、サービスに証明書を関連付けるとTLS終端をそのサービスに任せ、秘密鍵をサーバー上で手作業で扱わずに運用できます。統合先・証明書タイプによって要件が異なるため、対象サービスが証明書の発行元・鍵アルゴリズム・証明書種別に対応しているかを確認します。

TLSは通信区間ごとに設計する

TLSは「アプリケーション全体を一度設定すれば経路の全区間が暗号化される」機能ではありません。TLS接続は、証明書を提示するサーバーとそのクライアントの間で成立します。ロードバランサーなどがTLSを終端すると、その先に別の接続が開始されます。したがって、利用者からエッジ、エッジからオリジン、ロードバランサーからバックエンドの各区間について、暗号化の要否と証明書を個別に決めます。

以下はCloudFront、Application Load Balancer（ALB）、EC2上のアプリケーションで構成する例です。証明書をどこへ関連付けるか、各区間のTLSをどこで終端するかを区別してください。

1. ブラウザーからCloudFront

ビューワー（ブラウザー）とCloudFront間をHTTPSにするには、CloudFrontディストリビューションにTLS証明書を関連付けます。独自ドメインの証明書はACMで発行またはインポートできますが、CloudFront用のACM証明書は米国東部（バージニア北部、us-east-1）リージョンに存在する必要があります。CloudFrontはグローバルなエッジネットワークで動作しますが、ACM証明書自体はリージョナルリソースであるため、この配置要件が生じます。

ビューワープロトコルポリシーではHTTP接続を許可するかを選びます。HTTPをHTTPSへリダイレクトすれば、HTTPで到着したブラウザーを暗号化された接続へ誘導できます。HTTPSのみを要求する構成では、HTTPリクエストを処理させず、クライアントにHTTPSを使わせます。リダイレクトは後続の接続をHTTPSにする設定であって、リダイレクト前のHTTPリクエスト自体を暗号化するものではありません。

2. CloudFrontからALB

CloudFrontからオリジンのALBまで暗号化する場合、CloudFrontのオリジンプロトコルポリシーでHTTPS接続を要求します。ALBにはオリジンのホスト名と一致する有効なサーバー証明書が必要です。ACMのリージョン証明書をALBに関連付ける場合、その証明書はALBと同じリージョンに用意します。CloudFront用にus-east-1で取得した証明書を、別リージョンのALBにもそのまま使うという考え方ではなく、それぞれの統合先の配置要件に従って証明書を管理します。

CloudFrontのオリジンをHTTPに設定すると、ビューワーからCloudFrontまでHTTPSであっても、CloudFrontからALBまでは暗号化されません。オリジンのHTTPS設定を有効にするだけでなく、CloudFrontが検証できる信頼された証明書をオリジンが提示すること、証明書の名前が接続先に合うこと、有効期限内であることも確認します。自己署名証明書を配置するだけでは公開信頼された証明書の代わりにはならず、検証上のエラーにつながる構成があります。

3. ALBからEC2上のアプリケーション

ALBのHTTPSリスナーでTLSを終端し、EC2上のターゲットへHTTPで転送する構成は可能です。この場合、ブラウザーからALBまでは暗号化されますが、ALBからEC2までは暗号化されません。セキュリティグループでターゲットへの接続元をALBに限定することはネットワークアクセス制御として重要ですが、HTTP通信そのものを暗号化する対策とは異なります。

ALBからEC2までの通信にもTLSが必要なら、ターゲット側にもTLSサーバーを構成し、ALBからHTTPSで接続します。EC2へ証明書を直接配備する場合、次のいずれかを選びます。

• エクスポート可能なACMパブリック証明書を発行し、証明書と秘密鍵を安全な方法でEC2へ配備する。
• AWS Private CAでプライベート証明書を発行し、信頼する内部クライアント／サーバーへ配布する。
• 外部CAから取得した証明書を、必要なサーバー上で利用する。
• 検証用など限定された状況で自己署名証明書を使う。ただし、接続側がその発行者を信頼しない場合、証明書検証に失敗する可能性がある。

通常のACM証明書ではACMが秘密鍵を保護し、統合先サービスがその証明書を利用します。秘密鍵ファイルをダウンロードしてEC2のWebサーバーへ直接インストールすることはできません。エクスポート可能なパブリック証明書やPrivate CAから取得する証明書はこの制約と区別してください。

証明書のリージョンと関連付け

ACM証明書はリージョナルリソースです。証明書を使うAWSリソースの配置先と、CloudFrontの特別な要件を整理します。

利用先	ACM証明書の配置	覚えておくこと
CloudFrontディストリビューション	米国東部（バージニア北部、us-east-1）	エッジはグローバルでも、関連付けるACM証明書のリージョンは固定
ALBなどリージョナルなElastic Load Balancing	対象ロードバランサーと同じリージョン	別リージョンで発行したACM証明書はそのまま関連付けできない。同じ証明書を複数リージョンで使う場合は各リージョンに証明書を用意する
API Gatewayなどのリージョナルエンドポイント	対象APIの要件に沿った同一リージョン	APIのエンドポイント種類やカスタムドメイン設定の条件を確認
EC2インスタンス上のWebサーバー	インスタンスへ配置する証明書ファイル	通常のACM統合証明書ではなく、エクスポート可能証明書や外部で管理する証明書を使う

CloudFrontの証明書とALBの証明書は、同じACM証明書を使う場合でもリージョン要件が異なります。複数のリージョンにALBを配置するシステムでは、各リージョンで証明書を用意し、更新と関連付けを個別に確認します。

ACM証明書の発行、ドメイン検証、更新

ACMのパブリック証明書をリクエストする際、証明書に含めるドメイン名を指定します。ACMは証明書を発行する前に、そのドメインを申請者が管理していることを検証します。主な検証方法はDNS検証とEメール検証です。DNS検証ではACMが提示するCNAMEレコードをドメインのDNSへ登録します。DNSレコードを維持できれば、更新時の再検証を円滑にしやすいため、一般にDNS検証が推奨されます。

ACM発行のパブリック証明書は**ドメイン認証（DV: Domain Validation）**です。検証されるのは証明書に含まれるドメインを制御できることです。企業や申請組織の法的実在性・運営主体を証明するものではありません。そのため、組織認証（OV: Organization Validation）や拡張認証（EV: Extended Validation）など、DVより強い組織確認を伴う証明書が必要なら、該当する証明書を発行する第三者CAを利用し、必要に応じてACMへインポートします。DVでもTLSによる通信暗号化と、ドメイン名に対するサーバー認証を実現できます。

ACMはパブリック証明書のほか、ACM経由でAWS Private CAに要求するプライベート証明書も管理できます。マネージド更新には証明書の発行方法、関連付け・エクスポート状態、検証方法などの条件があります。たとえば、ACM管理のパブリック証明書ではDNS検証を使い、統合サービスに関連付けるか、発行後にエクスポートすると自動更新の対象になり得ます。更新時には通常同じ証明書ARNが維持され、統合サービスへの更新反映はサービス連携の範囲で管理されます。一方、エクスポートして独自サーバーに配置した証明書は、更新後の新しい証明書をサーバーへ配備する責任が残ります。

外部CAから取得した証明書をACMへインポートする場合、証明書本体に加えて、対応する秘密鍵と証明書チェーンを用意します。チェーンには通常、中間CAの証明書を含め、クライアントが信頼の連鎖をたどれるようにします。秘密鍵が証明書の公開鍵と対になっていること、証明書の期限・形式・暗号アルゴリズムが利用先の要件を満たすことも必要です。

インポート証明書はACMのマネージド更新対象ではありません。期限切れを防ぐため、外部CAで更新証明書を取得し、期限を監視してACMへ再インポートします。再インポートで既存の証明書ARNとサービス関連付けを維持できる場合があるため、利用中証明書を置き換える際はACMの再インポート手順に従います。自動で更新されると想定せず、担当者・通知・更新期限・配布手順を明確にします。

AWS Private CAとプライベート証明書

パブリック証明書の信頼チェーンは、一般にOSやブラウザーに登録された公開CAへつながります。社内システムやIoT機器など、インターネット利用者に公開しない通信では、組織内で管理するCAが発行したプライベート証明書を使う選択肢があります。

**AWS Private Certificate Authority（AWS Private CA）**は、プライベートCA階層をAWS上で作成・運用し、内部用途の証明書を発行するサービスです。たとえば、各工場のセンサーデバイスが社内のテレメトリーAPIへ接続する際、機器やサービスへ個別の証明書を発行し、TLS通信や相互認証に利用できます。ACMからAWS Private CAにプライベート証明書を要求すると、その証明書をACM統合サービスで利用する設計も可能です。独自アプリケーションへ直接配備する場合は、発行方式と証明書のエクスポート可否を確認します。

プライベートCAの証明書は、公開CAの証明書のように一般のブラウザーやOSが自動的に信頼するとは限りません。接続するクライアントへ信頼するルートCA証明書を安全に配布し、発行者・有効期限・失効状態を検証できるようにします。また、プライベートCAは作成して稼働させている期間の料金が発生し、証明書の発行にも料金がかかります。ACM統合サービスで使う一部のプライベート証明書が無料でも、Private CA自体が無料になるとは限りません。内部証明書の発行量、CAを保持する期間、複数リージョンの要否を見積もります。

料金と運用上の選択

ACM統合サービスで利用する通常のACMパブリック証明書には追加料金がかかりません。エクスポート可能なパブリック証明書には追加料金があり、料金は証明書に含むドメイン名の種類・数などに基づきます。AWS Private CAでは、CAの稼働に対する料金と発行した証明書に対する料金を考慮します。外部CAから証明書を購入する場合は、そのCAの契約料金も別に発生します。料金は変更される可能性があるため、導入時にはAWS公式料金ページと利用するリージョンの条件を確認してください。

設計時には「秘密鍵をどこで使うか」を最初に決めます。

• CloudFrontやALBなどACM統合サービスにTLSを終端する：通常のACM証明書を関連付ける。鍵を直接サーバーに置かず、ACMの管理を活用する。
• EC2上のWebサーバーへ証明書ファイルを配置する：エクスポート可能なACM証明書、Private CA発行証明書、または外部CA証明書を使う。秘密鍵の安全な配布・保管と、更新後の配備処理を設計する。
• 外部CAの契約や組織確認済み証明書を継続利用する：ACMへインポートして統合AWSサービスで利用できるが、期限監視と更新・再インポートは自動化の対象として別途構築する。
• 内部利用者・機器だけが信頼する証明書を多数発行する：Private CAを検討する。CAの稼働費・証明書発行費用、信頼アンカーの配布、失効確認を含めて運用負荷を見積もる。

DVA試験での判断ポイント

• ACMは証明書のライフサイクル管理を支援し、CloudFront、Elastic Load Balancing、API Gatewayなどの統合先へ関連付けられる。TLS証明書によって転送中データを保護する。
• CloudFrontのビューワー用証明書はus-east-1に置く。ALBなどリージョナルサービスへ関連付ける証明書は、そのサービスと同じリージョンに置く。ACM証明書自体はリージョナルリソースである。
• CloudFront、ALB、EC2の各区間は個別のTLS接続として考える。CloudFrontからALBをHTTPSにする設定と、ALBからEC2をHTTPSにする設定は別である。
• 通常のACM証明書では秘密鍵をダウンロードしてEC2へ直接設置しない。EC2上でTLSを終端する場合、エクスポート可能なパブリック証明書、Private CA証明書、または外部CA証明書を使う。エクスポート可能証明書は通常証明書と異なり追加料金が発生し、更新後の配備は利用者が行う。
• 外部証明書のインポートでは証明書、秘密鍵、証明書チェーンをそろえる。インポート証明書はACMが自動更新しないため、利用者が期限を監視して更新・再インポートする。
• ACMのパブリック証明書はDVであり、ドメインの管理権限を確認する。DVは組織の実在性を証明するOV/EVと同じではないが、TLS通信の暗号化に利用できる。
• 内部サービスやIoT機器用に組織独自の証明書を発行する用途ではAWS Private CAを検討する。プライベートCAの料金と、クライアントへ信頼するCAを配布する運用を忘れない。
• 「ACMの証明書は無料」「ACMの証明書はEC2で使えない」と一律に判断しない。通常の統合サービス用パブリック証明書、エクスポート可能なパブリック証明書、Private CA、インポート証明書の違いで、料金・秘密鍵の扱い・更新責任が変わる。

AWS公式ドキュメント

• AWS Certificate Managerの統合サービス
• ACMでのパブリック証明書のリクエスト
• エクスポート可能なACMパブリック証明書
• ACMへの証明書のインポート
• ACMによる証明書のマネージド更新
• AWS Private CAとは
• AWS Certificate Managerの料金