全般

Q: 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 統合サービスだけで使われるもの以外に対し、月額料金をお支払いただきます。

Q: SSL/TLS 証明書とは何ですか?

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

Q: プライベート証明書とは何ですか?

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

Q: パブリック証明書とプライベート証明書の違いは何ですか?

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

Q: AWS Certificate Manager (ACM) を使用する利点は何ですか?

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 ディストリビューションでプロビジョニングできます。

Q: ACM ではどのタイプの証明書を管理できますか?

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 メトリクスを使用することで、インポートされた証明書の有効期限を監視し、新しいサードパーティーの証明書をインポートして、期限が切れるものと置き換えられます。

Q: ACM の使用を開始するにはどうすればよいですか?

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 コンテナ、または任意の場所で使用できるようにエクスポートすることができます。

Q: ACM 証明書は、どの AWS のサービスで使えますか?

• パブリックとプライベートの ACM 証明書は、以下の AWS のサービスで使えます。
• 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 ドキュメントを参照してください。

Q: ACM はどのリージョンで利用できますか?

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

ACM 証明書

Q: ACM で管理される証明書の種類はどのようなものですか?

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

Q: ACM により提供される証明書に、複数のドメイン名を含めることはできますか?

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

Q: ワイルドカードドメイン名とは何ですか?

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

Q: ACM により提供される証明書にワイルドカードドメイン名を含めることができますか?

はい。

Q: ACM では、SSL/TLS 以外の証明書も提供していますか?

いいえ。

Q: ACM 証明書はコード署名や E メール暗号化に使えますか?

いいえ。

Q: E メールの署名と暗号化に使用される証明書 (S/MIME 証明書) は ACM で提供されますか?

いいえ。

Q: ACM 証明書の有効期間はどれくらいですか?

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

Q: ACM 発行証明書はどのようなアルゴリズムを使いますか?

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

Q: 証明書を取り消すにはどうすればよいですか?

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

Q: 複数の AWS リージョンで同じ ACM 証明書を使用できますか?

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

Q: 同じドメイン名について別のプロバイダーから証明書を既に取得している場合、ACM で証明書をプロビジョンできますか?

はい。

Q: Amazon EC2 インスタンスや自分のサーバーで、証明書を使用できますか?

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

Q: ACM では、ドメイン名に各地の言語の文字 (国際化ドメイン名 (IDN)) を使用できますか?

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

Q: ACM でドメイン名のラベルに使用できる文字形式はどれですか?

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

Q: サードパーティの証明書をインポートして、AWS のサービスで使用できますか?

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

ACM パブリック証明書

Q: パブリック証明書とは何ですか?

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

Q: ACM で提供されるパブリック証明書の種類はどのようなものですか?

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

Q: ACM パブリック証明書は、ブラウザ、オペレーティングシステム、モバイルデバイスで信頼されていますか?

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

Q: 私のブラウザが ACM パブリック証明書を信頼しているかどうか、どうすれば確認できますか?

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 証明書が信頼されます。Root CA の詳細については、Amazon Trust Services Repository を参照してください。

Q: 組織認証 (OV) や拡張認証 (EV) のパブリック証明書は、ACM で提供されますか?

いいえ。

Q: Amazon のパブリック証明書発行に関するポリシーと施策は、どこで説明されていますか?

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

Q: www.example.com 向けの証明書は、example.com でも機能しますか?

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

Q: ACM は、企業がコンプライアンスの要件を満たすのにどのように役立ちますか?

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

Q: ACM にサービスレベルアグリーメント (SLA) はありますか?

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

Q: ACM では、ウェブサイトで表示できるセキュアサイトシールやトラストロゴを利用できますか?

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

Q: Amazon の商標やロゴを、証明書バッジ、サイトシール、またはトラストロゴとして使用できますか?

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

 

パブリック証明書の提供

Q: ACM でパブリック証明書をプロビジョニングするにはどうすればよいですか?

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 のドキュメントを参照してください。

Q: なぜACM はパブリック証明書についてドメイン所有者を検証するのですか?

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

Q: ACM はドメインに対してパブリック証明書を発行する前に、どのようにしてドメイン所有者を検証するのですか?

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

Q.自分のパブリック証明書には、DNS、E メールどちらの検証方法を使えばよいですか?

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

Q.既存のパブリック証明書を E メール検証から DNS 検証に変更できますか?

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

Q: パブリック証明書が発行されるのに時間はどれくらいかかりますか?

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

Q: パブリック証明書をリクエストすると、どのように処理されますか?

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

Q: ACM は、パブリック証明書発行前に DNS Certificate Authority Authorization (CAA) レコードを確認しますか?

はい。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 ユーザーガイドの CAA レコードの設定 または CAAの問題のトラブルシューティング を参照してください。

Q: ACM はドメインの検証について他の方法もサポートしていますか?

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

DNS での検証

Q:DNS 検証とは何ですか?

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

Q:DNS 検証の利点は何ですか?

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

Q.誰が DNS 検証を使うべきですか?

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

Q.ACM は E メール検証にも対応していますか?

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

Q.ドメインを検証するには、DNS 設定にどのレコードを追加する必要がありますか?

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

Q.ドメインに対して DNS レコードを追加または変更するには、どうすればよいですか?

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

Q.ACM により、Amazon Route 53 DNS 顧客の DNS 検証が簡素化できますか?

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

Q.DNS 検証には特定の DNS プロバイダを使う必要がありますか?

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

Q.1 つのドメインに 2 つ以上の証明書が欲しい場合、DNS レコードはいくつ必要ですか?

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

Q.同じ CNAME レコードで複数のドメイン名を検証できますか?

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

Q.DNS 検証を使用して、ワイルドカードドメイン名を検証できますか?

はい。

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

Q.1 つの CNAME レコードを使用して、ドメインのすべてのサブドメインを検証できますか?

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

Q.ACM が DNS 検証に TXT レコードではなく CNAME レコードを使うのはなぜですか?

CNAME レコードを使うことで、ACM は CNAME レコードが存在する限り証明書を更新できます。CNAME レコードは、ACM が必要に応じて更新しドメイン名の検証や再検証ができる、AWS ドメイン (acm-validations.aws) の TXT レコードに転送されます。

Q.DNS 検証は AWS リージョン全体でできますか?

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

Q.同じ証明書に別の検証方法を選択できますか?

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

Q.DNS 検証で検証された証明書を更新するには、どうすればよいですか?

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

Q.ドメインに対する証明書発行の許可は取り消せますか?

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

Q.CNAME レコードを削除したらどうなりますか?

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

E メールでの検証

Q: E メール検証とは何ですか?

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

Q: 証明書をリクエストして E メール検証を選択した場合、証明書承認リクエストはどの E メールアドレスに送信されますか?

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 メールアドレスのリストを表示できます。

Q: 証明書の承認リクエストの送信先となる E メールアドレスを設定できますか?

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

Q: プロキシの連絡先情報があるドメイン (Privacy Guard、WhoisGuard など) を使用できますか?

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

Q: ACM では、AWS アカウントの技術担当者の連絡先を使用してアイデンティティを検証できますか?

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

Q: 承認の E メールが送られてこない場合、どうすればよいですか?

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

プライベートキーの保護

Q: ACM により提供される証明書のプライベートキーは、どのように管理されますか?

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

Q: ACM では、AWS リージョンをまたいで証明書をコピーできますか?

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

更新とデプロイの管理

Q: ACM により管理される更新とデプロイとは何ですか?

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

Q: ACM により管理される更新とデプロイを使用する利点は何ですか?

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

Q: 自動的に更新とデプロイができるのは、どの 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 が自動的に更新します。新しい証明書とプライベートキーの取得、アプリケーション中でのデプロイメントは、ご自身で行ってください。

Q: ACM による証明書の更新はいつ行われますか?

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

Q: 証明書の更新と新しい証明書のデプロイは事前に通知されますか?

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

Q: ACM では、"example.com" などのベアドメイン (Zone Apex またはネイキッドドメインとも呼ばれる) を含むパブリック証明書は、更新されますか?

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

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

Q: ACM で更新された証明書がデプロイされた場合、サイトの既存の接続は失われますか?

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

Q: 複数の Elastic Load Balancing ロードバランサーや複数の CloudFront ディストリビューションで、同じ証明書を使用できますか?

はい。

Q: パブリックなインターネットアクセスのない内部 Elastic Load Balancing ロードバランサーに、パブリック証明書を使用できますか?

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

ログ記録

Q: 証明書のプライベートキーの使用状況を監査できますか?

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

Q: AWS CloudTrail では、どのログ記録情報を利用できますか?

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

請求

Q: ACM 証明書の使用に対する課金と請求は、どのように行われますか?

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

AWS Private Certificate Authority

Q: AWS プライベート CAについての情報はどこで確認できますか?

AWS Private CA の使用に関するよくある質問については、AWS Private CA のよくある質問をご覧ください。

AWS Certificate Manager Private Certificate Authority の詳細

ページを見る。

詳細はこちら 
無料のアカウントにサインアップ

AWS 無料利用枠にすぐにアクセスできます。 

サインアップ 
AWS コンソールで構築を開始する

AWS マネジメントコンソールで AWS Certificate Manager を使った構築を始めましょう。

サインイン