Q: AWS Certificate Manager (ACM) とは何ですか?

AWS Certificate Manager により、AWS の各種サービスとお客様の内部接続リソースで使用するパブリックとプライベートの Secure Sockets Layer/Transport Layer Security (SSL/TLS) 証明書のプロビジョニング、管理、およびデプロイを簡単に行えます。SSL/TLS 証明書は、ネットワーク通信を保護し、インターネットと、それにプライベートネットワーク上のリソースでウェブサイトのアイデンティティを確立するために使用されます。AWS Certificate Manager を使用すれば、SSL/TLS 証明書の購入、アップロード、および更新という時間のかかるプロセスを手動で行う必要がなくなります。AWS Certificate Manager を使えば、証明書のリクエスト、および Elastic Load Balancing、 Amazon CloudFront ディストリビューション、Amazon API Gateway の API といった AWS のリソースでの証明書のデプロイをすばやく簡単に行うことができます。また、証明書は自動的に更新されます。また内部リソースのためのプライベート証明書を作成し、証明書ライフサイクルを中央で管理することも可能になります。AWS Certificate Manager でプロビジョンされたパブリック、プライベート SSL/TLS 証明書で、Elastic Load Balancing、Amazon CloudFront、Amazon API Gateway だけで使われるものは無料です。お支払いいただくのは、アプリケーションを実行するために作成した 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 の管理者はプライベート証明書を発行する自身のルールを決めることができ、これには証明書を発行する方法と、証明書にどの情報を入れるかなどがあります。プライベート証明書とプライベート CA についての詳細は、下の ACM プライベート CA をご覧ください。

Q: AWS Certificate Manager (ACM) と ACM プライベート認証機関 (CA) を使う利点は何ですか?

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

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

ACM プライベート CA はマネージド型のプライベート CA サービスで、プライベート証明書のライフサイクルを容易で安全に管理するのに役立ちます。ACM プライベート CA では、高可用性のプライベート CA を、自社のプライベート CA をオペレーションするための先行投資や継続的なメンテナンスコストなしに得られます。ACM プライベート CA は ACM の証明書管理機能をプライベート証明書に拡張し、パブリックおよびプライベート証明書を中央で管理できるようにします。ACM プライベート CA では、デベロッパーの方は API を用いてプログラムでプライベート証明書を作成、デプロイできるようになり、迅速性が向上します。また、カスタム証明書ライフタイムまたはリソース名を要するアプリケーションのためのプライベート証明書を作成する柔軟性も得られます。ACM プライベート CA では、接続されたリソースに対して、中央から安全で、従量課金制の、マネージド型 CA サービスを用いて、プライベート証明書を作成、管理、追跡できます。 

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

ACM ではパブリック、プライベート証明書のライフサイクルを管理できます。ACM の機能は証明書がパブリックかプライベートか、証明書をどのようにして得られたか、どこでデプロイされたかによって異なります。パブリック証明書についての詳細は ACM パブリック証明書を、またプライベート証明書とプライベート CA についての詳細は下の ACM プライベート CA セクションをご覧ください。

パブリック証明書 – ACM は ACM 組み込みのサービスで使われているパブリック証明書の更新とデプロイメントを管理し、これらのサービスには Amazon CloudFront、Elastic Load Balancing、Amazon API Gateway などがあります。

プライベート証明書 – ACM プライベート CA は次の 3 つの方法でプライベート証明書を作成、管理します。1) プライベート証明書の管理を ACM に委任するよう選択できます。この方法を使うと、ACM は ACM 組み込みのサービスで使われているプライベート証明書を自動的に更新、デプロイし、これらのサービスには Amazon CloudFront、Elastic Load Balancing、Amazon API Gateway などがあります。これらの証明書は AWS マネジメントコンソール、API、コマンドラインインターフェース (CLI) を用いて容易にデプロイできます。2) プライベート証明書を ACM からエクスポートして EC2 インスタンス、コンテナ、オンプレミスサーバー、IoT デバイスで使用します。ACM プライベート CA はこれらの証明書を自動的に更新し、更新完了時に Amazon CloudWatch 通知を送信します。お客様はクライアント側コードを書いて、更新された証明書とプライベートキーをダウンロードし、お使いのアプリケーションでデプロイできます。3) ACM プライベート CA は、お客様の ACM プライベート CA から自分自身のプライベートキーを作成し、証明書署名リクエスト (CSR) を生成し、プライベート証明書を発行し、これらのキーと証明書をお客様自身で管理する柔軟性を提供します。これらのプライベート証明書の更新とデプロイはお客様が行われます。

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

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

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

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

パブリック、プライベート ACM 証明書は次の AWS サービスで使えます。
• Elastic Load Balancing – Elastic Load Balancing のドキュメントを参照してください。
• Amazon CloudFront – CloudFront のドキュメントを参照してください。
Amazon API Gateway – API Gateway のドキュメントを参照してください。
• AWS Elastic Beanstalk – AWS Elastic Beanstalk のドキュメントを参照してください。
• AWS CloudFormation – 現時点では、E メールでの検証を使うパブリック証明書のみをサポートしています。AWS CloudFormation のドキュメントを参照してください。  

加えて、ACM プライベート CA で発行されたプライベート証明書は EC2 インスタンス、コンテナ、IoT デバイス、またご自身のサーバーでお使いいただけます。

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

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

Q: ACM プライベート CA とは何ですか?

プライベート証明書は、サーバー、モバイルおよび IoT デバイス、アプリケーションなどのプライベートネットワーク上で接続されたリソースの間の通信を特定し、セキュリティを確保するために使われます。ACM プライベート CA はマネージド型のプライベート CA サービスで、プライベート証明書のライフサイクルを容易で安全に管理するのに役立ちます。ACM プライベート CA では、高可用性のプライベート CA を、自社のプライベート CA をオペレーションするための先行投資や継続的なメンテナンスコストなしに得られます。ACM プライベート CA は ACM の証明書管理機能をプライベート証明書に拡張し、パブリックおよびプライベート証明書を中央で作成、管理できるようにします。お使いの AWS リソース用のプライベート証明書は、AWS マネジメントコンソールまたは ACM API を使って容易に作成、デプロイできます。EC2 インスタンス、コンテナ、IoT デバイス、オンプレミスリソースに対しては、プライベート証明書を容易に作成、追跡し、自身のクライアント側自動化コードを使ってこれらをデプロイできます。また、カスタム証明書ライフタイム、キーアルゴリズム、またはリソース名を要するアプリケーションのためのプライベート証明書を作成し、自分で管理する柔軟性も得られます。プライベート CA について詳細をご覧ください。

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

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

Q: プライベート認証機関 (CA) とは何ですか?

プライベート CA はプライベートネットワーク (パブリックインターネットではなく) でのプライベート証明書の発行、検証、取り消しを取り扱います。CA には次の 2 つの主なコンポーネントがあります。1 つは CA 証明書で、証明書の発行される元となる暗号化ビルディングブロックです。2 つ目は証明書取り消しリスト (CRL) で取り消し情報を保持するラインタイムサービス群です。リソースが互いに接続しようとすると、これらのリソースは CRL で、各エンティティが提示する証明書の状況を確認します。証明書が有効であれば、リソース間でハンドシェイクが行われて、これが各エンティティのアイデンティティを他方に暗号的に証明し、暗号化された通信チャネル (TLS/SSL) をリソース間に作成します。

Q: プライベート証明書とプライベート CA は、パブリック証明書とパブリック CA とはどのように違うのですか?

プライベート CA のコンポーネントはパブリック CA のものと同じです。しかし、パブリック CA はパブリックインターネット上のリソースに対して証明書を発行、検証しなければならないのに対し、プライベート CA は同じことをプライベートネットワーク上で行います。ひとつの重要な違いは、アプリケーションとブラウザはデフォルトで自動的にパブリック証明書を信用するのに対し、プライベート CA の発行した証明書を信用するには管理者がアプリケーションを明示的に設定する必要があります。パブリック CA は厳格なルールに従い、オペレーションの可視性を提供し、それにどの CA がブラウザとオペレーティングシステムを自動的に信用するかを決めるブラウザとオペレーティングシステムベンダーによって課せられるセキュリティ標準を満たす必要があります。プライベート CA の管理者はプライベート証明書を発行する自身のルールを決めることができ、これには証明書を発行する方法と、証明書にどの情報を入れるかなどがあります。

Q: 組織がパブリック証明書ではなく、プライベート証明書を使うのはなぜですか?

プライベート証明書は、組織内のほとんどあらゆるものを、名前を公開することなく特定する柔軟性があります。プライベート証明書に使える名前の例には、Wiki.internal、IP address 192.168.1.1、fire-sensor-123、user123 などがあります。これに対し、パブリック証明書では www.example.com などのパブリック DNS 名でリソースを特定するという厳しい制限があります。プライベート証明書はパブリック証明書では禁止されている情報を含むことができます。エンタープライズアプリケーションの中にはプライベート証明書に追加の情報を加えられることを活用したものがあり、これらはパブリック証明書では機能できません。

Q: 自己署名証明書とは何ですか、また組織はなぜプライベート CA からの証明書を代わりに使うのですか?

自己署名証明書とは、CA なしで発行されるものです。CA が維持するセキュアなルートから発行された証明書と異なり、自己署名証明書は自身のルートで動作しますので、大きな制限があります。それは自己署名証明書がオンザワイヤー暗号化の提供には使用できますが、アイデンティティの確認はできず、取り消しもできないことです。セキュリティの点からは許容できませんが、生成が容易で、専門知識やインフラストラクチャが不要で、多くのアプリケーションが受け付けることができるため、組織で使用されています。自己署名証明書の発行には何もコントロールはありません。有効期限を確認する方法は無いため、これを使う組織は証明書の有効期限切れによる使用不能におちいるリスクが大きくなります。ACM プライベート CA はこうした問題を解決します。

Q: ACM プライベート CA の使用を開始するにはどうすればよいですか?

ACM プライベート CA の使用を開始するには、AWS マネジメントコンソールのCertificate Manager に移動し、画面左側のプライベート CA を選択します。[今すぐ始める] を選択して、プライベート認証機関の作成を開始してください。詳細は ACM プライベート CA ユーザーガイドのご利用開始にあたってをご覧ください。

Q: ACM プライベート CA についてどこで詳細を確認できますか?

詳細は、ACM プライベート CA 詳細ページACM プライベート CA ユーザーガイドACM プライベート CA API リファレンスAWS CLI リファレンス内の ACM をご覧ください。

                                                                 先頭に戻る >>

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

ACM はパブリック、プライベート、およびインポートされた証明書を管理します。各種 証明書に対する ACM の管理機能の詳細は、[Q: 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: SSL/TLS 以外の証明書は ACM で提供されますか?

ACM で管理される証明書は SSL/TLS での使用を意図しています。ACM プライベート CA から直接プライベート証明書を発行して、証明書管理に ACM を使用せずにキーと証明書を管理する場合、これらのプライベート証明書のサブジェクト、有効期間、キーアルゴリズム、署名アルゴリズムは自分で設定でき、またこれらの証明書は SSL/TLS およびその他のアプリケーションで使えます。

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

いいえ。

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

現時点では提供されません。

Q: ACM 証明書の有効期間は何ですか?

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

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

ACM で管理されるアルゴリズムは RSA キーを、2048 ビットモジュールと SHA-256 とで用います。ACM プライベート CA から直接プライベート証明書を発行し、証明書管理のためには ACM を使わずにキーと証明書を管理する場合、楕円曲線 (ECDSA) 証明書も発行、使用できます。ACM は現時点ではこれらの証明書を管理する機能はありません。 

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

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

Q: AWS リージョン間で証明書をコピーできますか?

ACM が管理する証明書は現時点ではリージョン間でコピーできません。ACM からエクスポートしたプライベート証明書と、ACM プライベート CA から直接発行して、証明書とプライベートキーの管理には ACM を使わないものははコピーできます。

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

Elastic Load Balancing または Amazon CloudFront の使用の有無によって異なります。証明書を異なるリージョンにある同じサイト (完全修飾ドメイン名、つまり 1 つまたは一連の FQDN が同じ) に対して Elastic Load Balancing とともに使用する場合、使用するリージョンごとに新しい証明書をリクエストすることが必要になります。Amazon CloudFront で ACM の証明書を使用するには、米国東部 (バージニア北部) リージョンでリクエストする必要があります。CloudFront ディストリビューションに関連付けられたこのリージョンでの ACM の証明書は、お客様のディストリビューションに設定されたすべての地理的場所に配信されます。

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

はい。

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

ACM プライベート CA で発行されたプライベート証明書は EC2 インスタンス、コンテナ、またご自身のサーバーでお使いいただけます。現時点では、パブリック証明書は特定の AWS サービスと共にのみお使いいただけます。ACM 証明書はどの AWS サービスと使えますか?をご覧ください。

 

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

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

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

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

                                                                 先頭に戻る >>

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

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

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

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

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

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

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

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

パブリック証明書は Amazon の認証機関 (CA) で検証されます。Amazon Root CA 1、Starfield サービスルート認証機関証明書 – G2 または Starfield クラス 2 ルート認証機関証明書がインストールされているブラウザ、アプリケーション、OS では、ACM 証明書が信頼されます。

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

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

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

Amazon Trust Services 証明書ポリシーと Amazon Trust Services 認定施策書のドキュメントで説明されています。最新バージョンについては、Amazon Trust Services リポジトリを参照してください。

Q: パブリック証明書の情報が変更された場合、AWS に通知するにはどうすればよいですか?

validation-questions[at]amazon.com に E メールを送信してください。

                                                                 先頭に戻る >>

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

AWS マネジメントコンソール、AWS CLI、ACM API/SDK を使用できます。AWS マネジメントコンソールを使用するには、コンソールの Certificate Manager の部分を開いて [証明書のリクエスト] を選択し、[パブリック証明書のリクエスト] を選択し、サイトのドメイン名を入力してから、画面の指示に沿ってリクエストを実行します。サイトにアクセスする際に使用できる別のドメイン名があれば、リクエストにそのドメイン名を追加できます。ACM が証明書を発行するには、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 証明書認証機関 (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 ユーザーガイドの Configure a CAA Record または Troubleshooting CAA Problems を参照してください。

Q: ACM はドメインの検証に他の方法にも対応していますか?

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

 

                                                                 先頭に戻る >>

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 レコードのふたつの部分 (名前とラベル) は ACM から得られます。詳細方法は、ACM ユーザーガイドを参照してください。

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

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

Q. ACM は Amazon Route 53 DNS の顧客に対して DNS での検証を簡単にしますか?

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

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

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

Q. ひとつのドメインに 2 つ以上の証明書が欲しい場合、DNS レコードはいくついりますか?

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

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

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

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

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

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

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

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

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

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

いいえ。各証明書にはひとつの検証方法しか使えません。

Q. DNS での検証で検証された証明書は、どのようにして更新できますか?

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

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

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

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

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

先頭に戻る >>

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

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

Q: 証明書をリクエストして 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 リポジトリにある最新の Amazon Trust Services 認定施策書を参照してください。

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

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

先頭に戻る >>

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

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

Q: ACM では、証明書が別 のAWS リージョンでもコピーされますか?

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

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

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

先頭に戻る >>

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

AWS Certificate Manager でプロビジョンされたパブリック、プライベート証明書で、Elastic Load Balancing、Amazon CloudFront、Amazon API Gateway サービスなどの ACM 組み込みサービスだけで使われるものは無料です。お支払いいただくのは、アプリケーションを実行するために作成した AWS リソースの料金のみです。AWS Certificate Manager プライベート認証機関には従量制料金があります。各 ACM プライベート CA のオペレーションには、削除するまで月額料金をお支払いただきます。また ACM から作成、エクスポートするプライベート証明書にもお支払いただき、これには EC2 やオンプレミスサーバーで使うもの、またお使いのプライベート CA から直接、プライベートキーを自分で作成して発行するものがあります。詳細と例については、料金のページをご覧ください。

先頭に戻る >>

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

はい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

先頭に戻る >>

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

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

先頭に戻る >>

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

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

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

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

Q: 自動的に更新およびデプロイできるのは、どの ACM 証明書ですか?

パブリック証明書

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

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

プライベート証明書

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

1) ACM は、お使いの ACM プライベート CA が発行するプライベート証明書で、Elastic Load Balancing や API Gateway などの ACM 組み込みのサービスで使われるものを完全に自動的に更新、デプロイします。ACM は ACM で作成、管理されるプライベート証明書を、これらを発行したプライベート CA がアクティブなステートにとどまる限り更新、デプロイできます。

2) ACM からエクスポートして、オンプレミスリソース、EC2 インスタンス、IoT デバイスで使うプライベート証明書については、ACM プライベート CA は自動的に更新します。新規証明書とプライベートキーの取得、アプリケーション中でのデプロイメントはお客様が行ってください。

3) ACM プライベート CA から直接証明書を発行し、証明書の管理に ACM を使わずご自分でキーと証明書を管理される場合は、ACM はお客様の証明書を更新しません。これらのプライベート証明書の更新とデプロイはお客様が行われます。

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

ACM では、早い場合、証明書の有効期限切れの 60 日前に更新プロセスが開始されます。ACM 証明書の有効期間は現時点では 13 か月です。更新の自動管理の詳細については、ACM ユーザーガイドを参照してください。

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

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

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

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

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

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

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

先頭に戻る >>