AWS Certificate Manager よくある質問

全般

AWS Certificate Manager (ACM) は、AWS のサービスとお客様の内部接続リソースで使用するパブリックとプライベートの Secure Sockets Layer/Transport Layer Security (SSL/TLS) 証明書のプロビジョニング、管理、デプロイを簡単にします。SSL/TLS 証明書は、ネットワーク通信を保護し、プライベートネットワークのリソースと同様にインターネットで W ウェブサイトのアイデンティティを確立するために使用されます。ACM を使用すれば、SSL/TLS 証明書の購入、アップロード、および更新という時間のかかるプロセスを手動で行う必要がなくなります。ACM を使えば、証明書のリクエストや、Elastic Load Balancers、Amazon CloudFront ディストリビューション、Amazon API Gateway の API といった AWS のリソースでの証明書のデプロイを、すばやく簡単に行うことができます。また、証明書は自動的に更新されます。また内部リソースのためのプライベート証明書を作成し、証明書ライフサイクルを集中的に管理することも可能になります。ACM でプロビジョンされたパブリック、プライベート SSL/TLS 証明書で、Elastic Load Balancing、Amazon CloudFront、Amazon API Gateway などの ACM 統合サービスだけで使われるものは無料です。お支払いいただくのは、アプリケーションを実行するために作成した AWS リソースの料金です。各プライベート CA のオペレーションについて (これらが削除されるまで)、および ACM 統合サービスのみで使用されるもの以外のお客様が発行するプライベート証明書について、月額料金をお支払いただきます。

SSL/TLS 証明書により、Secure Sockets Layer/Transport Layer Security (SSL/TLS) プロトコルを使用した、ウェブブラウザからウェブサイトへの暗号化されたネットワーク接続の特定と確立が可能となります。証明書は、公開鍵基盤 (PKI) と呼ばれる暗号化システム内で使用されます。PKI では、双方が認証機関と呼ばれるサードパーティを信頼している場合に、証明書を使用して一方から他方のアイデンティティを確立する方法となります。その他の情報と定義については、「ACM ユーザーガイド」の「概念」のトピックにアクセスしてください。

プライベート証明書は、アプリケーション、サービス、デバイス、ユーザーなど、組織内のリソースを特定します。セキュアな暗号化通信チャネルを確立する際、各エンドポイントは証明書と暗号技術を使用して、そのアイデンティティを他方のエンドポイントに証明します。内部 API エンドポイント、ウェブサーバー、VPN ユーザー、IoT デバイス、その他多くのアプリケーションは、プライベート証明書を使って、安全なオペレーションに必要な暗号化された通信チャネルを確立します。

パブリック、プライベート両方の証明書は、ネットワークでリソースを特定し、これらのリソース間での通信を安全にするのに役立ちます。パブリック証明書はパブリックインターネットでリソースを特定し、プライベート証明書はこれをプライベートネットワークで行います。重要な違いは、アプリケーションとブラウザはデフォルトで自動的にパブリック証明書を信頼するのに対し、プライベート証明書を信頼するには管理者がアプリケーションを明示的に設定する必要があることです。パブリック証明書を発行するエンティティーであるパブリック CA は、厳格なルールに従い、オペレーションの可視性を提供する必要があります。また、ブラウザとオペレーティングシステムがどの CA を自動的に信頼するかを決める、ブラウザとオペレーティングシステムのベンダーによって課せられるセキュリティ基準を満たす必要があります。プライベート CA はプライベートな組織によって管理され、プライベート CA の管理者はプライベート証明書の発行について自身のルールを決めることができます。これには、証明書を発行する方法や、証明書にどの情報を入れるかなどがあります。 

ACM を使用すると、AWS プラットフォームで運用されているウェブサイトやアプリケーションに対して、SSL/TLS を簡単に有効にできます。ACM では、SSL/TLS 証明書の使用と管理に関連する多くのプロセスを手動で実行する必要がなくなります。また ACM は、更新を管理することで、証明書の設定ミス、失効、期限切れによるダウンタイムをなくすのにも役立ちます。ウェブサイトやアプリケーションが SSL/TLS で保護されるようになり、証明書の管理も簡単になります。インターネット向けのサイトに SSL/TLS を有効にすることは、サイトの検索ランキングを向上させ、転送中のデータの暗号化に関する規制やコンプライアンスの要件を満たすのにも役立ちます。

ACM を使用して証明書を管理する場合、証明書のプライベートキーは、強力な暗号化とキー管理に関するベストプラクティスによって安全に保護され、保存されます。ACM では、AWS マネジメントコンソール、AWS CLI、ACM API を使って、AWS リージョンでの SSL/TLS ACM 証明書すべてを集中管理できます。ACM は AWS の他のサービスと統合されているため、AWS マネジメントコンソール、AWS CLI コマンド、または API 呼び出しを使って、SSL/TLS 証明書をリクエストし、Elastic Load Balancing のロードバランサーや Amazon CloudFront ディストリビューションでプロビジョニングできます。

ACM では、パブリック証明書とプライベート証明書のライフサイクルを管理できます。ACM の機能は、証明書がパブリックかプライベートか、どのようにして得たか、どこでデプロイされたかによって異なります。

パブリック証明書 – Amazon 発行のパブリック証明書は、ACM にて申請することができます。ACM は、Amazon CloudFront、Elastic Load Balancing、Amazon API Gateway などの ACM 統合サービスで使われている、パブリック証明書の更新とデプロイを管理します。

プライベート証明書 – プライベート証明書の管理を ACM に委任するよう選択できます。この方法を使うと、ACM は、Amazon CloudFront、Elastic Load Balancing、Amazon API Gateway などの ACM 統合サービスで使われているプライベート証明書を、自動的に更新しデプロイします。これらの証明書は、AWS マネジメントコンソール、API、コマンドラインインターフェース (CLI) を使用して、簡単にデプロイできます。プライベート証明書を ACM からエクスポートして、EC2 インスタンス、コンテナ、オンプレミスサーバー、IoT デバイスで使用します。AWS プライベート CA は、これらの証明書を自動的に更新し、更新完了時に Amazon CloudWatch 通知を送信します。クライアント側コードを書いて、更新された証明書とプライベートキーをダウンロードし、お使いのアプリケーションでデプロイできます。

インポートされた証明書 – Amazon CloudFront、Elastic Load Balancing、Amazon API Gateway でサードパーティーの証明書を使用する必要がある場合は、AWS マネジメントコンソール、AWS CLI、ACM API を使って証明書を ACM にインポートできます。ACM は、インポートされた証明書を更新することはできませんが、更新プロセスの管理をサポートします。インポートした証明書について、有効期限の監視と期限切れ前の更新は、ご自身で行ってください。ACM CloudWatch メトリクスを使用して、インポートされた証明書の有効期限をモニタリングし、期限切れが近い証明書を置き換えるために新しいサードパーティーの証明書をインポートできます。

ACM の使用を開始するには、AWS マネジメントコンソールの [Certificate Manager] を開いてウィザードを実行し、SSL/TLS 証明書をリクエストします。プライベート CA が作成済みの場合は、パブリックとプライベートのどちらの証明書が必要かを選択し、サイト名を入力します。証明書リクエストに AWS CLI や AWS API を使用することもできます。証明書発行後、ACM に統合された他の AWS のサービスで使用できます。各統合サービスについて、AWS マネジメントコンソールのドロップダウンリストから、必要な SSL/TLS 証明書を選択するだけです。または、AWS CLI コマンドを実行するか AWS API を呼び出して、リソースに証明書を関連付けることもできます。その後、統合サービスが、選択したリソースに証明書をデプロイします。 ACM が提供する証明書のリクエストと使用に関する詳細については、「ACM ユーザーガイド」をご覧ください。プライベート証明書は、ACM 統合サービスのほか、EC2 インスタンス、ECS コンテナ、または任意の場所で使用できるようにエクスポートすることができます。

• Elastic Load Balancing – Elastic Load Balancing ドキュメントをご覧ください。
• Amazon CloudFront – CloudFront ドキュメントをご覧ください。
• Amazon API Gateway – API Gateway ドキュメントをご覧ください。
• AWS CloudFormation – 現時点では、ACM 発行のパブリック証明書およびプライベート証明書のみをサポートしています。AWS CloudFormation ドキュメントをご覧ください。
• AWS Elastic Beanstalk – AWS Elastic Beanstalk ドキュメントをご覧ください。
• AWS Nitro Enclaves – AWS Nitro Enclaves ドキュメントをご覧ください。

現在 AWS サービスを利用できるリージョンについては、AWS グローバルインフラストラクチャのページにアクセスしてください。Amazon CloudFront で ACM 証明書を使用するには、米国東部 (バージニア北部) リージョンでリクエストまたはインポートする必要があります。CloudFront ディストリビューションに関連付けられたこのリージョンでの ACM の証明書は、お客様のディストリビューションに設定されたすべての地理的場所に配信されます。

ACM 証明書

ACM は、パブリック証明書、プライベート証明書、インポートされた証明書を管理します。ACM の機能については、証明書の発行と管理のドキュメントを参照してください。

はい。各証明書には少なくとも 1 つのドメイン名が含まれている必要がありますが、必要な場合はさらにドメイン名を追加できます。例えば、両方のドメイン名でサイトにアクセスできるなら、"www.example.com" の証明書に "www.example.net" というドメイン名を追加できます。証明書リクエストに含まれるドメイン名すべてを所有または制御している必要があります。 

ワイルドカードドメイン名のワイルドカードは、ファーストレベルサブドメインまたはドメインのホスト名に一致します。ファーストレベルサブドメインは単一のドメイン名ラベルで、ピリオド (ドット) は含みません。例えば、*.example.com というドメイン名を使用すると、www.example.com、images.example.com、また .example.com で終わるその他あらゆるホスト名またはファーストレベルサブドメインを保護できます。詳細については、「ACM ユーザーガイド」をご覧ください。

はい。

いいえ。

いいえ。

いいえ。

ACM で発行された証明書は 13 か月間 (395 日間) 有効です。プライベート CA から直接プライベート証明書を発行し、証明書管理に ACM を使わずにキーと証明書を管理した場合は、任意の有効期間を選択できます。これは絶対終了日でも、日、月、年で指定する現時点からの相対時間でも構いません。

ACM で発行されるアルゴリズムは、デフォルトで RSA キーを 2048 ビットモジュールと SHA-256 で使用します。さらに、楕円曲線デジタル署名アルゴリズム (ECDSA) 証明書は、P-256 または P-384 のいずれかをリクエストすることができます。アルゴリズムの詳細については、「ACM ユーザーガイド」をご覧ください。

AWS サポートセンターにアクセスしてサポートケースを作成することで、パブリック証明書の取り消しを ACM にリクエストできます。AWS プライベート CA で発行したプライベート証明書を取り消すには、AWS プライベート CA ユーザーガイドをご覧ください。

いいえ。ACM 証明書は、使用するリソースと同じリージョンにある必要があります。グローバルサービスである Amazon CloudFront は唯一の例外で、米国東部 (バージニア北部) 地域の証明書を必要とします。CloudFront ディストリビューションに関連付けられたこのリージョンでの ACM の証明書は、お客様のディストリビューションに設定されたすべての地理的場所に配信されます。

はい。

プライベート CA で発行されたプライベート証明書は、EC2 インスタンス、コンテナ、ご自身のサーバーでお使いいただけます。現時点では、パブリック証明書は特定の AWS のサービス (AWS Nitro Enclaves など) に限り、お使いいただけます。ACM のサービスの統合をご覧ください。

ACM では、ドメイン名に Unicode でエンコードされた各地の言語の文字を使用することができませんが、ASCII でエンコードされた各地の言語の文字を使用することはできます。

ACM でドメイン名に使用できる文字形式は、UTF-8 でエンコードされた ASCII のみです。一般に Punycode と呼ばれる "xn–" が付くラベルも使用できます。ACM では、ドメイン名に Unicode 入力 (U ラベル) を使用することはできません。

はい。Amazon CloudFront や Elastic Load Balancing、Amazon API Gateway でサードパーティの証明書を使用する必要がある場合は、AWS マネジメントコンソール、AWS CLI、ACM API を使って証明書を ACM にインポートできます。インポートされた証明書の更新プロセスは、ACM で管理されません。AWS マネジメントコンソールを使ってインポートされた証明書の有効期限をモニタリングし、新しいサードパーティーの証明書をインポートして、期限が切れるものと置き換えられます。

ACM パブリック証明書

パブリック、プライベート両方の証明書は、ネットワークでリソースを特定し、これらのリソース間での通信を安全にするのに役立ちます。パブリック証明書はインターネット上のリソースを特定します。

ACM で提供されるのは、SSL/TLS の終端となるウェブサイトやアプリケーションで使用する、ドメイン検証済み (DV) パブリック証明書です。ACM 証明書の詳細については、「Certificate Characteristics」をご覧ください。

ACM パブリック証明書は、最新のブラウザ、オペレーティングシステム、モバイルデバイスのほとんどで信頼されています。ACM により提供される証明書は、Windows XP SP3 以降、Java 6 以降を含む、99% のブラウザとオペレーティングシステムで利用されています。

ACM 証明書を使用して SSL/TLS 経由で (例えば HTTPS を使用して) サイトに接続した場合、ACM 証明書を信頼するのブラウザの中にはロックアイコンが表示され、証明書の警告は表示されないものがあります。

ACM のパブリック証明書は、Amazon の認証機関 (CA) で検証されます。Amazon Root CA 1、Amazon Root CA 2、Amazon Root CA 3、Amazon Root CA 4、Starfield サービスルート認証機関証明書 - G2 を含むブラウザ、アプリケーション、OS では、ACM 証明書が信頼されます。ルート CA の詳細については、Amazon Trust Services Repository にアクセスしてください。

いいえ。

Amazon Trust Services Certificate Policies と Amazon Trust Services Certification Practices のドキュメントで説明されています。最新バージョンについては、Amazon Trust Services リポジトリをご覧ください。

いいえ。www.example.com と example.com の両方のドメイン名によってサイトが参照されるようにするには、両方のドメイン名が含まれる証明書をリクエストする必要があります。

ACM を使用すると、PCI、FedRAMP、HIPAA といった多くのコンプライアンスプログラムで一般的な要件である安全な接続を促進しやすくなり、企業が規制要件に準拠するのに役立ちます。コンプライアンスに関する具体的な情報については、http://aws.amazon.com/compliance を参照してください。

いいえ。ACM には SLA はありません。

いいえ。サイトシールが必要な場合は、サードパーティベンダーから入手できます。サイトのセキュリティやビジネス慣行またはその両方を評価し、それについて証言してくれるベンダーを選択するようお勧めします。

いいえ。このようなシールやバッジは、ACM サービスを使用していないサイトにコピーされたり、虚偽の信頼を確立するため不当に使用されたりするおそれがあります。Amazon のお客様と評価を保護するため、このような方法でロゴを使用することは禁止されています。

パブリック証明書の提供

AWS マネジメントコンソール、AWS CLI、ACM API/SDK を使用できます。AWS マネジメントコンソールを使用するには、[Certificate Manager] を開いて [証明書のリクエスト] を選択し、[パブリック証明書のリクエスト] を選択し、サイトのドメイン名を入力してから、画面の指示に沿ってリクエストを実行します。サイトにアクセスする際に使用できる別のドメイン名がある場合は、リクエストにそのドメイン名を追加できます。リクエストされた証明書のドメイン名を所有または管理していることが確認されると、ACM で証明書を発行できます。証明書をリクエストするとき、DNS 検証か、E メール検証を選択できます。DNS 検証では、ドメインのパブリック DNS 設定にレコードを書き込み、そのドメインを所有または管理していることを立証します。DNS 検証を使用してドメインの管理を立証した後、レコードがあって証明書が使用中である限り、さらに証明書を得て ACM で既存の証明書を更新できます。ドメインの管理を再度検証する必要はありません。DNS 検証の代わりに E メール検証を選択する場合は、証明書発行の承認をリクエストするドメイン所有者に E メールが送信されます。リクエストした各ドメインを所有または管理していることが検証された後、証明書が発行され、Elastic Load Balancing や Amazon CloudFront といった他の AWS のサービスでプロビジョニングできるようになります。詳細については、ACM のドキュメントをご覧ください。

証明書は、サイトのアイデンティティ、ブラウザやアプリケーションとサイトとの間の接続を確立するのに使用します。公的に信頼できる証明書を発行するため、Amazon では証明書をリクエストする人が、リクエストしている証明書のドメイン名を管理していることを検証する必要があります。

証明書発行の前に、ACM はリクエストされた証明書のドメイン名が所有または管理されているかを検証します。証明書をリクエストするとき、DNS 検証か、E メール検証を選択できます。DNS 検証では、ドメインの所有権は CNAME レコードを DNS 設定に追加することで検証できます。詳細については、「DNS での検証」をご覧ください。ドメインに対してパブリック DNS 設定にレコードを書き込めない場合は、DNS 検証に代わって E メール検証を使用できます。E メール検証では、ACM は登録されたドメインの所有者に E メールを送り、所有者または権限を受けた代理人が、証明書のリクエスト内にある各ドメインの発行を承認します。詳細については、「E メールでの検証」をご覧ください。

ドメインに対して DNS 設定の変更ができる場合は、DNS 検証をお勧めします。ACM からの検証 E メールを受け取れないお客様と、WHOIS でドメイン所有者のメールアドレスを公開していないドメインレジストラーを使用しているお客様は、DNS 検証を使用してください。DNS 設定を変更できない場合、E メールでの検証を使ってください。

できません。しかし、無料の証明書を新たに ACM からリクエストして、この新しいものに対して DNS での検証を選択できます。

証明書のリクエスト中にあるすべてのドメイン名が検証された後に証明書を発行する時間は、数時間以上になることがあります。

ACM では、リクエストの際に選ばれた DNS または E メール検証方法に従って、証明書のリクエストにある各ドメイン名の所有権や管理していることの検証を試みます。ACM がドメインの所有または管理を検証している間、証明書リクエストのステータスは Pending validation となります。検証プロセスの詳細については、以下の「DNS での検証」と「E メールでの検証」のセクションをご覧ください。証明書のリクエスト内にあるすべてのドメイン名が検証された後、証明書を発行する時間は、数時間以上になることがあります。証明書が発行されると、証明書リクエストのステータスは Issued に変わり、ACM に統合されている他の AWS サービスで使用開始できます。

はい。DNS Certificate Authority Authorization (CAA) レコードによって、ドメイン所有者は、ドメインに証明書を発行する権限を持つ認証機関を特定できます。ACM 証明書をリクエストすると、AWS Certificate Manager によってドメインの DNS ゾーン設定内の CAA レコードが検索されます。CAA レコードが存在しない場合は、Amazon がドメインに証明書を発行できます。ほとんどのお客様はこのカテゴリに属しています。

お客様の DNS 設定に CAA レコードが存在する場合、Amazon でドメインに証明書を発行する前に、そのレコードが amazon.com、amazontrust.com、awstrust.com、または amazonaws.com のいずれかの CA を指定している必要があります。詳細については、「AWS Certificate Manager ユーザーガイド」の「Configure a CAA Record」または「Troubleshooting CAA Problems」をご覧ください。

現時点では使用できません。

DNS での検証

DNS 検証では、ドメインの所有権は CNAME レコードを DNS 設定に追加することで検証できます。DNS 検証によって、ACM からパブリック SSL/TLS 証明書をリクエストする際にドメインの所有を立証しやすくなります。

DNS 検証は、ドメインの所有または管理の検証を簡単にすることで、SSL/TLS 証明書を得られるようにします。DNS 検証では、DNS 設定に CNAME レコードを書き込むだけで、ドメイン名の管理を立証できます。DNS 検証プロセスを簡単にするため、Amazon Route 53 で DNS レコードを管理している場合には、ACM 管理コンソールで DNS レコードを設定できます。この場合は、マウスを数回クリックするだけでお使いのドメイン名の管理を立証できます。CNAME レコードの設定後、DNS 検証レコードがある限り、ACM は自動的に使用中の (AWS リソースに関連付けられている) 証明書を更新します。更新は完全に自動化されており、何も触る必要はありません。

ACM に証明書をリクエストし、リクエストしているドメインに対して DNS 設定の変更ができる人は DNS での検証を検討してください。

はい。ACM では、DNS 設定の変更ができないお客様のために E メールでの検証にも対応しています。

検証したいドメインに CNAME レコードを追加してください。例えば、www.example.com の名前を検証するには、example.com に対するゾーンに CNAME レコードを追加します。追加するレコードは、ドメインと AWS アカウントに対して特別に ACM が生成した、ユニークなトークンを含みます。CNAME レコードの 2 箇所 (名前とラベル) は ACM から得られます。詳細については、「ACM ユーザーガイド」をご覧ください。

DNS レコードの追加または変更の詳細については、お使いの DNS プロバイダにお問い合わせください。Amazon Route 53 DNS ドキュメントには、Amazon Route 53 DNS をご利用のお客様向けに詳細情報が記載されています。

はい。DNS レコードの管理に Amazon Route 53 DNS をご利用のお客様は、証明書をリクエストする際に ACM コンソールで DNS 設定にレコードを追加できます。ドメインに対して Route 53 DNS がホストするゾーンは、リクエストしているのと同じ AWS アカウントで設定されている必要があり、リクエストする方は Amazon Route 53 設定を変更できる権限を持っている必要があります。詳細については、ACM ユーザーガイドを参照してください。

いいえ。プロバイダが CNAME レコードを DNS 設定に追加することを許す限り、どのような DNS プロバイダでも DNS 検証に使用できます。

1 つです。1 つの CNAME レコードを使用して、同じ AWS アカウントでの同じドメイン名に対し、複数の証明書を得られます。例えば、同じドメイン名に対する同じ AWS アカウントから 2 つの証明書をリクエストする場合、必要な DNS CNAME レコードはひとつだけです。

いいえ。各ドメイン名には固有の CNAME レコードが必要です。

はい。

DNS CNAME レコードには、名称とラベルの 2 つのコンポーネントがあります。ACM が生成した CNAME の名称のコンポーネントは、下線文字 (_) と、それに続いて、お使いの AWS アカウントとドメイン名に関連付けられた文字列であるトークンで構成されています。ACM は、ドメイン名の前に下線とトークンを加えて名称コンポーネントを構成します。ACM は、同じく AWS アカウントとドメイン名に関連付けられた別のトークンの前に付加された下線から、ラベルを作成します。ACM は、AWS が検証に使用する DNS ドメイン名 (acm-validations.aws) の前に、下線とトークンを付加します。次の例では www.example.com、subdomain.example.com、および *.example.com に対する CNAME の構成を示します。

_TOKEN1.www.example.com         CNAME     _TOKEN2.acm-validations.aws
_TOKEN3.subdomain.example.com CNAME     _TOKEN4.acm-validations.aws
_TOKEN5.example.com                 CNAME      _TOKEN6.acm-validations.aws

ワイルドカード名に対して CNAME レコードを生成するときに、ACM がワイルドカードラベル (*) を削除していることに注意してください。そのため、ACM がワイルドカード名 (例えば *.example.com) に対して生成した CNAME レコードは、ドメイン名にワイルドカードラベルが無いもの (example.com) に対して返されるレコードと同じになります。

いいえ。ホスト名とサブドメイン名を含む各ドメイン名は、固有の CNAME レコードで個別に検証する必要があります。

CNAME レコードを使うことで、ACM は CNAME レコードが存在する限り証明書を更新できます。CNAME レコードは AWS ドメイン (acm-validations.aws) での TXT レコードに転送しますので、ACM は必要に応じてお客様から何もやっていただかなくてもドメイン名を検証、再検証できます。

はい。ACM がオファーされているどのような AWS リージョンでも、1 つの DNS CNAME レコードを生成し、これを使用して同じ AWS アカウントで証明書を得られます。CNAME レコードを一度設定すると、別のレコードを作成することなく、その名称に対して ACM から発行、更新される証明書を得られます。

いいえ。各証明書に使える検証方法は 1 つのみです。

DNS 検証レコードがある限り、ACM は自動的に使用中 (AWS リソースに関連付けられている) の証明書を更新します。

はい。CNAME レコードを削除するだけです。CNAME レコードを削除した後は、ACM が DNS 検証を使用してドメインに証明書を発行したり更新したりすることはなく、この変更は DNS 全体に適用されます。レコードの削除を全体に適用する時間はお客様の DNS プロバイダによります。

CNAME レコードを削除されると、ACM では DNS での検証を用いてお客様のドメインに証明書を発行または更新できなくなります。

E メールでの検証

E メール検証では、証明書リクエストにある各ドメイン名について、登録されているドメイン所有者に承認リクエストの E メールが送信されます。ドメイン所有者か権限を受けた代理人 (承認者) は、E メールに記載された指示に沿って、証明書リクエストを承認できます。承認者は、指示に沿って E メールに記載されているリンクをクリックするか、E メールからリンクをコピーしてブラウザ貼り付けて、承認ウェブサイトを開きます。その後、ドメイン名、証明書 ID (ARN)、リクエスト実行元の AWS アカウントの ID など、証明書リクエストに関連する情報を確認し、情報が正確であればリクエストを承認します。

E メール検証を使用して証明書をリクエストすると、証明書リクエストに記載された各ドメイン名に対して WHOIS ルックアップが実行され、そのドメインの連絡先情報が取得されます。E メールは、記載されているそのドメインの登録者、管理者、技術担当者の連絡先に送信されます。リクエストされたドメイン名の前に admin@、administrator@、hostmaster@、webmaster@、postmaster@ を付加して生成された 5 つの特別なメールアドレスにも、E メールが送られます。例えば、server.example.com の証明書をリクエストした場合、E メールの送信先は、その example.com ドメインに対する WHOIS クエリで返された連絡先情報を使用するそのドメインの登録者、技術担当者、管理者の連絡先、admin@server.example.com、administrator@server.example.com、hostmaster@server.example.com、postmaster@server.example.com、および webmaster@server.example.com となります。

5 つの特別な E メールアドレスは、「www」で始まるドメイン名またはアスタリスク (*) で始まるワイルドカード名については、別に構成されます。ACM によって先頭の「www」またはアスタリスクは除去され、E メールは残りのドメイン名の先頭に admin@、administrator@、hostmaster@、postmaster@、webmaster@ を付加して生成された管理アドレスに送信されます。例えば www.example.com の証明書をリクエストした場合、E メールは前述のとおり WHOIS の連絡先と、admin@www.example.com ではなく admin@example.com に送信されます。残りの 4 つの特別な E メールアドレスも同様に構築されます。

証明書をリクエストした後、ACM コンソール、AWS CLI、AWS API を使用して、各ドメインに関する E メールの送信先となった E メールアドレスのリストを表示できます。

いいえ。ただし、検証メールの送信先とするベースドメイン名は設定できます。ベースドメイン名は、証明書リクエストに記載されたドメイン名のスーパードメインである必要があります。例えば server.domain.example.com の証明書をリクエストする場合、AWS CLI や AWS API を使用して、承認メールを admin@domain.example.com に転送するよう設定できます。詳細については、ACM CLI リファレンスACM API リファレンスをご覧ください。

はい。ただし、プロキシにより E メールの配信が遅れる可能性があります。また、プロキシ経由で送信される E メールは、迷惑メールフォルダに分類される可能性があります。トラブルシューティングのアドバイスについては、ACM ユーザーガイドを参照してください。

いいえ。ドメイン所有者のアイデンティティを検証するための手順とポリシーは非常に厳格で、公的に信頼されている認証機関のポリシー基準を設定する CA/ブラウザフォーラムにより決定されています。詳細については、Amazon Trust Services Repository にある最新の Amazon Trust Services Certification Practices を参照してください。

トラブルシューティングのアドバイスについては、ACM ユーザーガイドを参照してください。

プライベートキーの保護

ACM により提供される証明書ごとに、キーペアが作成されます。ACM は、SSL/TLS 証明書で使用されるプライベートキーを保護し管理するよう設計されています。プライベートキーを保護および保存する際には、強力な暗号化とキー管理に関するベストプラクティスが使用されます。

いいえ。各 ACM 証明書のプライベートキーは、証明書をリクエストしたリージョンで保存されます。例えば米国東部 (バージニア北部) リージョンで新しい証明書を取得した場合、ACM はプライベートキーをバージニア北部リージョンに保存します。ACM 証明書がリージョンをまたいでコピーされるのは、証明書が CloudFront ディストリビューションと関連付けられている場合に限られます。この場合、CloudFront により、ディストリビューションの対象として設定されている地理的場所に ACM 証明書が配信されます。

更新とデプロイの管理

ACM が管理する更新とデプロイでは、SSL/TLS ACM 証明書の更新処理と、更新後の証明書のデプロイを管理します。

ACM では、SSL/TLS 証明書の更新とデプロイを管理できます。ACM により、安全なウェブサービスやアプリケーションに対する SSL/TLS の設定と維持が自動化されるため、エラーが発生しやすい手動プロセスと比較して、運用の信頼性が高まります。更新とデプロイが自動的に管理されることは、証明書の期限切れによるダウンタイムをなくすのにも役立ちます。ACM は、他の AWS のサービスと統合されたサービスとして動作します。つまり、AWS マネジメントコンソール、AWS CLI、AWS API を使用して、証明書を AWS プラットフォームで集中的に管理およびデプロイできることになります。プライベート CA では、プライベート証明書を作成し、エクスポートできます。エクスポートした証明書は ACM が更新するため、クライアント側の自動化コードでこれらの証明書をダウンロードし、デプロイできます。

パブリック証明書

ACM では、パブリック ACM 証明書を、ドメイン所有者から追加の検証なしで更新、デプロイできます。追加の検証がないと更新できない証明書については、ACM は証明書に記載された各ドメイン名のドメイン所有者を検証して更新プロセスを管理します。証明書に記載された各ドメイン名が検証されると、証明書が更新され、AWS リソースに自動的にデプロイされます。ACM がドメインの所有を検証できない場合はお客様 (AWS アカウントの所有者) にお知らせします。

証明書のリクエストで DNS 検証を選択した場合、ACM では証明書が使用中で (AWS リソースに関連付けられていて)、CNAME レコードがある限り、お客様からは何らの追加介入もなくその証明書を無期限で更新します。証明書をリクエストする際に E メールでの検証を選択された場合、その証明書が使用中であり、証明書に記載されたすべてのドメイン名がお客様のサイトに解決でき、すべてのドメイン名がインターネットから到達可能であることを示して、ACM 証明書が自動的に更新、デプロイできる可能性を向上できます。

プライベート証明書

ACM では、AWS プライベート CA で発行するプライベート証明書の管理に 2 つのオプションがあります。ACM は、プライベート証明書の管理方法に応じて、様々な更新の機能を提供します。発行される各プライベート証明書に対して最上の管理オプションを選択してください。

1) ACM は、お使いの AWS プライベート CA が発行するプライベート証明書で、Elastic Load Balancing や API Gateway などの ACM 統合サービスで使われるものを、完全に自動的に更新、デプロイします。ACM で発行されたプライベート証明書は、証明書を発行したプライベート CA がアクティブなステートである限り、ACM での更新とデプロイが可能です。
2) ACM からエクスポートし、オンプレミスリソース、EC2 インスタンス、IoT デバイスで使用するプライベート証明書については、ACM が自動的に更新します。新規証明書とプライベートキーの取得、アプリケーション中でのデプロイメントはお客様が行ってください。

ACM は、証明書の有効期限切れの最大 60 日前に更新プロセスを開始します。現在、ACM 証明書の有効期間は 13 か月 (395 日) です。マネージド更新の詳細については、「ACM ユーザーガイド」をご覧ください。

いいえ。ACM による証明書の更新やキーの再設定、古い証明書の差し替えは、事前の通知なしに行われる可能性があります。

パブリック証明書に対する証明書のリクエストで DNS での検証を選択された場合、ACM では証明書が使用中で (AWS リソースに関連付けられている)、お客様の CNAME レコードがある限り、お客様からは何らの追加介入もなくその証明書を更新します。

ベアドメインのパブリック証明書をリクエストする際に E メール検証を選択した場合は、ベアドメインの DNS ルックアップがその証明書に関連付けられた AWS リソースに解決されるようにしておいてください。Route 53 や、ベアドメインを AWS リソースにマッピングするエイリアスリソースレコード (または同等の機能) をサポートするその他の DNS プロバイダーを使用しないと、ベアドメインから AWS リソースへの解決が困難な場合があります。詳細については、Route 53 開発者ガイドを参照してください。

いいえ。新しい証明書がデプロイされた後に確立された接続では、新しい証明書を使用しているため、既存の接続に影響はありません

はい。

はい。しかし AWS プライベート CA でプライベート証明書を発行すると、ACM は検証なしでこれを更新できます。インターネットから到達できないパブリック証明書と、プライベート証明書について、ACM が更新をどのように取り扱うのかの詳細については、「更新とデプロイの管理」をご覧ください。

ログ記録

はい。AWS CloudTrail を使用してログを確認すると、証明書のプライベートキーがいつ使用されたかを確認できます。

AWS CloudTrail をサポートするサービスで AWS API を呼び出したユーザーやアカウント、呼び出し元であるソース IP アドレス、呼び出しが発生した時間を特定できます。例えば、ACM により提供された証明書を Elastic Load Balancing と関連付ける API 呼び出しを行ったユーザーや、Elastic Load Balancing service で KMS API 呼び出しを使ってキーが暗号化された時間を特定できます。

請求

Elastic Load Balancing、Amazon CloudFront、Amazon API Gateway サービスなどの ACM 統合サービスで使用される、AWS Certificate Manager を通じてプロビジョニングされたパブリック証明書とプライベート証明書は無料です。お支払いいただくのは、アプリケーションを実行するために作成した AWS リソースの料金です。AWS プライベート CA は従量制料金です。詳細と例については、AWS プライベート CA の料金ページにアクセスしてください。

AWS Private Certificate Authority

AWS プライベート CA の使用に関するよくある質問については、「AWS Private CA FAQs」をご覧ください。