翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS Certificate Manager パブリック証明書 パブリック証明書をリクエストしたら、「[AWS Certificate Manager パブリック証明書のドメイン所有権を検証する](domain-ownership-validation.md)」の説明に従ってドメインの所有権を検証する必要があります。 パブリック ACM 証明書は X.509 標準に準拠しており、次の制約事項が適用されます。 + **名前:** DNS に準拠するサブジェクト名を使用する必要があります。詳しくは、[ドメイン名](acm-concepts.md#concept-dn) を参照してください。 + **アルゴリズム:** 暗号化の場合、証明書のプライベートキーのアルゴリズムは 2048 ビット RSA、256 ビット ECDSA、または 384 ビット ECDSA のいずれかである必要があります。 + **有効期限:** 各証明書は 198 日間有効です。 + **更新:** ACM は、有効期限の 45 日前にパブリック証明書を自動的に更新しようとします。 **注記** パブリック ACM 証明書は、[Nitro Enclave](acm-services.md#acm-nitro-enclave) に接続されている Amazon EC2 インスタンスにインストールできます。任意の Amazon EC2 インスタンスで使用する[[export a public certificate]](export-public-certificate.md) (パブリック証明書をエクスポート) することもできます。Nitro Enclave に接続されていない Amazon EC2 インスタンスでのスタンドアロンウェブサーバーのセットアップについては、「[チュートリアル: Amazon Linux 2 に LAMP ウェブサーバーをインストールする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-lamp-amazon-linux-2.html)」または「[チュートリアル: Amazon Linux AMI を使用した LAMP ウェブサーバーのインストール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-LAMP.html)」を参照してください。 管理者は ACM [条件付きキーポリシー](https://docs.aws.amazon.com/acm/latest/userguide/acm-conditions.html)を使用して、エンドユーザーによる新しい証明書の発行方法を制御します。これらの条件付きキーにより、証明書リクエストに関連するドメイン、検証方法、およびその他の属性に制限を設けることができます。証明書をリクエストするときに問題が発生した場合は、[証明書のリクエストのトラブルシューティング](troubleshooting-cert-requests.md) を参照してください。 を使用してプライベート PKI の証明書をリクエストするには AWS Private CA、「」を参照してください[でプライベート証明書をリクエストする AWS Certificate Managerプライベート証明書のリクエスト](gs-acm-request-private.md)。 **Topics** + [AWS Certificate Manager パブリック証明書の特性と制限](acm-certificate-characteristics.md) + [でパブリック証明書をリクエストする AWS Certificate Manager](acm-public-certificates.md) + [AWS Certificate Manager エクスポート可能なパブリック証明書](acm-exportable-certificates.md) + [AWS Certificate Manager パブリック証明書のドメイン所有権を検証する](domain-ownership-validation.md) # AWS Certificate Manager パブリック証明書の特性と制限 ACM が提供するパブリック証明書には、次の特性と制限があります。これらは ACM によって提供される証明書にのみ適用されます。これらの特徴は、[インポートした証明書](import-certificate.md)には適用されない場合があります。 ** ブラウザとアプリケーションの信頼** ACM 証明書は、Google Chrome、Microsoft Edge、そして Mozilla Firefox および Apple Safari を含むすべての主要なブラウザから信頼されています。ACM 証明書を使用しているサイトに TLS で接続すると、ブラウザにロックアイコンが表示されます。Java は ACM 証明書も信頼します。 ** 認証機関と階層** ACM を通じてリクエストしたパブリック証明書は、Amazon が管理するパブリック[認証局 (CA)](https://docs.aws.amazon.com/acm/latest/userguide/acm-concepts.html#concept-ca) である [Amazon Trust Services](https://www.amazontrust.com/repository/) から取得されます。Amazon ルート CA 1 ～ 4 は、Starfield G2 Root Certificate Authority - G2 によってクロス署名されています。Starfield ルートは、Android (Gingerbread 以降のバージョン) および iOS (バージョン 4.1 以降) で信頼されています。Amazon ルートは iOS 11 以降で信頼されています。Amazon または Starfield ルートを含むブラウザ、アプリケーション、または OS は、ACM パブリック証明書を信頼します。 ACM は、証明書タイプ (RSA または ECDSA) に基づいてランダムに割り当てられた中間 CA を通じて、お客様にリーフ証明書またはエンドエンティティ証明書を発行します。ACM は、このランダム選択のため、中間 CA 情報を提供しません。 ** ドメイン検証 (DV)** ACM 証明書はドメイン検証され、ドメイン名のみを識別します。ACM 証明書をリクエストする場合、指定されたすべてのドメインの所有権またはコントロールを証明する必要があります。E メールまたは DNS を使用して所有権を検証できます。詳しくは、[AWS Certificate Manager DNS 検証DNS での検証](dns-validation.md) または [AWS Certificate Manager E メール検証](email-validation.md) を参照してください。 ** HTTP 検証** ACM は、CloudFront で使用するパブリック TLS 証明書を発行する際に、ドメイン所有権の検証のための HTTP 検証をサポートします。この方法では、HTTP リダイレクトを使用してドメインの所有権を証明し、DNS 検証と同様の自動更新を提供します。HTTP 検証は現在、CloudFront Distribution Tenants 機能を通じてのみ使用できます。 ** HTTP リダイレクト** HTTP 検証の場合、ACM は `RedirectFrom` URL と `RedirectTo` URL を提供します。ドメイン制御を実証するには、`RedirectTo` から `RedirectFrom` へのリダイレクトを設定する必要があります。`RedirectFrom` URL には検証済みドメインが含まれ、`RedirectTo` は一意の検証トークンを含む CloudFront インフラストラクチャ内の ACM 制御のロケーションを指します。 ** によって管理されます** 別のサービスによって管理される ACM の証明書は、`ManagedBy` フィールドでサービスの ID を示します。CloudFront で HTTP 検証を使用する証明書の場合、このフィールドには「CLOUDFRONT」と表示されます。これらの証明書は CloudFront を通じてのみ使用できます。`ManagedBy` フィールドは、**DescribeCertificate** と **ListCertificates** API、および ACM コンソールの証明書インベントリと詳細ページに表示されます。 `ManagedBy` フィールドは、「使用できる」属性と相互に排他的です。CloudFront マネージド証明書の場合、他の AWS サービスを通じて新しい使用状況を追加することはできません。これらの証明書は、CloudFront API を通じて追加のリソースでのみ使用できます。 ** 中間 CA とルート CA のローテーション** Amazon は、復元力のある証明書インフラストラクチャを維持するために、事前の通知なしに中間認証機関を廃止することがあります。これらの変更は、お客様には影響しません。詳細については、[「Amazon introduces dynamic intermediate certificate authorities」](https://aws.amazon.com/blogs/security/amazon-introduces-dynamic-intermediate-certificate-authorities/)(Amazon が動的中間認証機関を導入) を参照してください。 Amazon がルート CA を中止すると、変更は必要に応じて速やかに行われます。Amazon は、利用可能なすべての方法を使用して、、E メール Health Dashboard、テクニカルアカウントマネージャーへの連絡など、 AWS お客様に通知します。 ** 失効時のファイアウォールアクセス** 取り消されたエンドエンティティ証明書は、OCSP と CRL を使用して失効情報を検証し、発行します。一部のお客様のファイアウォールでは、これらのメカニズムを許可するために追加のルールが必要になる場合があります。 失効トラフィックを特定するには、次の URL ワイルドカードパターンを使用します。 + **OCSP** `http://ocsp.?????.amazontrust.com` `http://ocsp.*.amazontrust.com` + **CRL** `http://crl.?????.amazontrust.com/?????.crl` `http://crl.*.amazontrust.com/*.crl` アスタリスク (\$1) は 1 つ以上の英数字、疑問符 (?) は単一の英数字を表し、ハッシュマーク (\$1) は数字を表します。 **キーアルゴリズム** 証明書では、アルゴリズムやキーサイズを指定する必要があります。ACM は、以下の RSA および ECDSA パブリックキーアルゴリズムをサポートしています。 + RSA 1024 ビット (`RSA_1024`) + RSA 2048 ビット (`RSA_2048`)\$1 + RSA 3072 ビット (`RSA_3072`) + RSA 4096 ビット (`RSA_4096`) + ECDSA 256 ビット (`EC_prime256v1`)\$1 + ECDSA 384 ビット (`EC_secp384r1`)\$1 + ECDSA 521 ビット (`EC_secp521r1`) ACM は、アスタリスク (\$1) でマークされたアルゴリズムを使用して新しい証明書をリクエストできます。他のアルゴリズムは、[インポートされた](import-certificate.md)証明書でのみサポートされます。 AWS Private CA CA によって署名されたプライベート PKI 証明書の場合、署名アルゴリズムファミリー (RSA または ECDSA) は CA のシークレットキーアルゴリズムファミリーと一致する必要があります。 ECDSA キーは同等のセキュリティの RSA キーよりも小さく計算効率も優れていますが、すべてのネットワーククライアントが ECDSA をサポートしているわけではありません。この表は、[NIST](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) から適用され、同等のセキュリティ強度における RSA と ECDSA のキーサイズ (ビット単位) を比較しています。 **アルゴリズムとキーのセキュリティ比較** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/acm/latest/userguide/acm-certificate-characteristics.html) セキュリティの強度は 2 の累乗で、暗号化をを解読するために必要な推測回数に関係します。例えば、3072 ビットの RSA キーと 256 ビットの ECDSA キーはどちらも、2128 回以下の推測で取得できます。 アルゴリズムの選択については、 AWS ブログ記事[「How to evaluate and use ECDSA certificates in AWS Certificate Manager](https://aws.amazon.com/blogs/security/how-to-evaluate-and-use-ecdsa-certificates-in-aws-certificate-manager/)」を参照してください。 [統合されたサービス](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) では、リソースへの関連付けがサポートされているアルゴリズムとキーサイズのみが許可されます。サポートは、証明書が IAM にインポートされているか ACM にインポートされているかによって異なります。詳細については、各サービスののドキュメントを参照してください。 + Elastic Load Balancing については、「[Application Load Balancer の HTTPS リスナー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)」を参照してください。 + CloudFront の場合は、[「サポートされる SSL/TLS プロトコルと暗号」を参照してください](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html)。 **マネージド型更新とデプロイ** ACM は、ACM 証明書の更新とプロビジョニングを管理します。自動更新は、証明書の設定ミス、失効、期限切れによるダウンタイムを防止することができます。詳しくは、[でのマネージド証明書の更新 AWS Certificate Manager](managed-renewal.md) を参照してください。 **複数のドメイン名** 各 ACM 証明書には、少なくとも 1 つの完全修飾ドメイン名 (FQDN) が含まれる必要があり、追加の名前を付けくわえることができます。たとえば、`www.example.com` の証明書には `www.example.net` を含めることもできます。これは、ベアドメイン (Zone Apexまたは裸ドメイン) にも適用されます。つまり、www.example.com に証明書をリクエストし、example.com という名前を追加できます。詳しくは、[AWS Certificate Manager パブリック証明書](gs-acm-request-public.md) を参照してください。 **プーニーコード** [国際化ドメイン名](https://www.icann.org/resources/pages/idn-2012-02-25-en) については、次の [Punycode](https://datatracker.ietf.org/doc/html/rfc3492) 要件を満たす必要があります。 1. パターン「—」で始まるドメイン名は「xn—」と一致する必要があります。 1. 「xn—」で始まるドメイン名も有効な国際化ドメイン名である必要があります。 **Punycode の例** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/acm/latest/userguide/acm-certificate-characteristics.html) **有効期間** ACM 証明書は 198 日間有効です。 **ワイルドカード名** ACM は、ドメイン名にアスタリスク (\$1) を使うことで、同じドメイン内の複数のサイトを保護するワイルドカード証明書を作成できます。たとえば、`*.example.com` は、`www.example.com` と `images.example.com` を保護します。 ワイルドカード証明書では、アスタリスク (`*`) はドメイン名の左側に付ける必要があり、1 つのサブドメインレベルのみを保護できます。たとえば、`*.example.com` は `login.example.com` と `test.example.com` を保護しますが、`test.login.example.com` は保護しません。また、`*.example.com` は、サブドメイン*のみ*を保護し、ベアドメインまたは apex ドメイン (`example.com`) は保護しないことに注意してください。ベアドメインとそのサブドメインの両方の証明書をリクエストするには、`example.com` や `*.example.com` などの複数のドメイン名を指定します。 CloudFront を使用する場合、HTTP 検証ではワイルドカード証明書がサポートされないことにご注意ください。ワイルドカード証明書の場合は、DNS 検証または E メール検証のいずれかを使用する必要があります。自動証明書更新をサポートしているため、DNS 検証をお勧めします。 # でパブリック証明書をリクエストする AWS Certificate Manager AWS Certificate Manager パブリック証明書は、ACM コンソール AWS CLI、または API からリクエストできます。これらの証明書は、統合して使用すること AWS のサービス も、外部で使用するためにエクスポートすることもできます AWS クラウド。 次のリストでは、パブリック証明書とエクスポート可能なパブリック証明書の違いを説明します。 **パブリック証明書** Elastic Load Balancing、Amazon CloudFront、Amazon API Gateway AWS のサービス などの統合 で ACM パブリック証明書を使用します。詳細については、「[サービスと ACM の統合](acm-services.md)」を参照してください。 2025 年 6 月 17 日より前に作成された ACM パブリック証明書は、エクスポートできません。 **エクスポート可能なパブリック証明書** エクスポート可能なパブリック証明書は と統合 AWS のサービス されており、外部でも使用できます AWS クラウド。詳細については、「[AWS Certificate Manager エクスポート可能なパブリック証明書](acm-exportable-certificates.md)」および「[サービスと ACM の統合](acm-services.md)」を参照してください。パブリック証明書をエクスポートできるようにするには、新しい ACM パブリック証明書を作成し、エクスポートを有効にする必要があります。 以下のセクションでは、パブリック ACM 証明書をリクエスト、エクスポート、および取り消す方法を説明します。 **Topics** + [コンソールを使用してパブリック証明書をリクエストする](#request-public-console) + [CLI を使用してパブリック証明書をリクエストする](#request-public-cli) ## コンソールを使用してパブリック証明書をリクエストする **ACM パブリック証明書をリクエストするには (コンソール)** 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/acm/home](https://console.aws.amazon.com/acm/home) で ACM コンソールを開きます。 **[Request a certificate]** (証明書のリクエスト) を選択します。 1. [**Domain names**] (ドメイン名) セクションで、ドメイン名を入力します。 **www.example.com** のような完全修飾ドメイン名 (FQDN) や **example.com** のようなネイキッドドメインあるいは apex ドメイン名を使用できます。また、同じドメインで複数のサイト名を保護するために、最左位置にアスタリスク (**\$1**) をワイルドカードとして使用できます。たとえば、**\$1.example.com** は、**corp.example.com** と **images.example.com** を保護します。ワイルドカード名は、ACM 証明書の **[Subject]** (件名) フィールドと **[Subject Alternative Name]** (サブジェクト代替名) 拡張子に表示されます。 ワイルドカード証明書をリクエストする場合、アスタリスク (**\$1**) はドメイン名の左側に付ける必要があり、1 つのサブドメインレベルのみを保護できます。たとえば、**\$1.example.com** は **login.example.com** および **test.example.com** を保護できますが、**test.login.example.com** を保護することはできません。また、**\$1.example.com**は、**example.com** のサブドメインのみを保護し、ネイキッドドメインまたは apex ドメイン (**example.com**) は保護しないことに注意してください。両方を保護するには、次のステップを参照してください。 **注記** [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) に準拠している場合、この手順で入力するドメイン名 (技術的には Common Name) の長さは、ピリオドを含む 64 オクテット (文字) を超えることはできません。ただし、後続の各サブジェクト代替名 (SAN) は、次の手順で、長さが最大 253 オクテットまで指定できます。 1. 別の名前を追加するには、**[Add another name to this certificate]** (この証明書に別の名前を追加) を選択し、テキストボックスに名前を入力します。これは、ネイキッドドメインまたは apex ドメイン (**example.com** など) の両方とそのサブドメイン (**\$1.example.com** など) を保護するために役立ちます。 1. ACM エクスポート可能なパブリック証明書を作成する場合は、**[Enable export]** (エクスポートを有効にする) オプションを選択します。証明書のプライベートキーにアクセスして、 AWS クラウドの外部で使用できます。詳細については、「[AWS Certificate Manager エクスポート可能なパブリック証明書](acm-exportable-certificates.md)」を参照してください。 1. **[Validation method]** (検証方法) セクションで、必要に応じて **[DNS validation – recommended]** (DNS 検証 - 推奨) または **[Email validation]** (E メール検証) を選択します。 **注記** DNS 設定を編集できる場合は、E メール検証ではなく DNS ドメイン検証を使用することをお勧めします。DNS 検証には E メール検証と比べていくつかの利点があります。「[AWS Certificate Manager DNS 検証DNS での検証](dns-validation.md)」を参照してください。 ACM は証明書を発行する前に、証明書リクエストのドメイン名の所有者または管理者を検証します。E メール検証または DNS 検証のいずれかを使用できます。 1. E メール検証を選択すると、ACM はドメイン名フィールドで指定したドメインに検証 E メールを送信します。検証ドメインを指定すると、ACM はその検証ドメインに E メールを送信します。E メール検証の詳細については、[AWS Certificate Manager E メール検証](email-validation.md) を参照してください。 1. DNS 検証を使用する場合は、ACM から提供される CNAME レコードを DNS 設定に追加するだけです。DNS 検証の詳細については、[AWS Certificate Manager DNS 検証DNS での検証](dns-validation.md) を参照してください。 1. **[Key algorithm]** (キーアルゴリズム) セクションで、アルゴリズムを選択します。 1. **[Tags]** (タグ) ページで、オプションで証明書にタグを付けることができます。タグは、 AWS リソースを識別して整理するためのメタデータとして機能するキーと値のペアです。ACM タグパラメータのリスト、および証明書作成後にタグを追加する方法については、[AWS Certificate Manager リソースにタグを付ける](tags.md) を参照してください。 タグの追加が完了したら、**[Request]** (リクエスト) を選択します。 1. リクエストが処理されると、コンソールは証明書リストに戻り、リストには新しい証明書の情報が表示されます。 トラブルシューティングのトピック「[証明書のリクエストの失敗](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-cert-requests.html#troubleshooting-failed)」に記載されているいずれかの理由で失敗しない限り、リクエストされると証明書のステータスが **[Pending validation]** (検証保留中) になります。ACM が証明書の検証を 72 時間繰り返し、タイムアウトします。証明書のステータスが **[Failed]** (失敗) または **[Validation timed out]** (検証タイムアウト) の場合、リクエストを削除し、[DNS での検証](https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html) または [E メール検証](https://docs.aws.amazon.com/acm/latest/userguide/email-validation.html) で問題を修正してから、再度お試しください。検証が成功すると、証明書のステータスは **[Issued]** (発行済み) になります。 **注記** リストの配列方法によっては、探している証明書がすぐには表示されない場合があります。右側の黒い三角形をクリックすると、配列を変更できます。また、右上のページ番号を使用して、証明書の複数のページを検索することもできます。 ## CLI を使用してパブリック証明書をリクエストする [request-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html) コマンドを使用して、コマンドラインに新しいパブリック ACM 証明書をリクエストします。検証方法のオプション値は DNS と EMAIL です。キーアルゴリズムのオプション値は、RSA\$12048 (パラメータが明示的に指定されていない場合のデフォルト)、EC\$1prime256v1、および EC\$1secp384r1 です。 ``` aws acm request-certificate \ --domain-name www.example.com \ --key-algorithm EC_Prime256v1 \ --validation-method DNS \ --idempotency-token 1234 \ --options CertificateTransparencyLoggingPreference=DISABLED,Export=ENABLED ``` このコマンドは、新しいパブリック証明書の Amazon リソースネーム (ARN) を出力します。 ``` { "CertificateArn": "arn:aws:acm:Region:444455556666:certificate/certificate_ID" } ``` # AWS Certificate Manager エクスポート可能なパブリック証明書 AWS Certificate Manager エクスポート可能なパブリック証明書を使用すると、Amazon EC2 インスタンス、コンテナ、オンプレミスホストなど、どこでも [SSL/TLS 証明書](acm-concepts.md#concept-sslcert)をプロビジョニング、管理、デプロイできます。この機能は、ACM が発行したパブリック証明書を統合以上に拡張し AWS のサービス、インフラストラクチャ全体で証明書を一元的に制御できるようにします。 ## 利点 ACM エクスポート可能なパブリック証明書の利点を以下に示します。 + *証明書管理の簡素化*: ACM を使用してすべてのリソースの証明書を一元管理します。 + *証明書発行の高速化*: 証明書に短時間でアクセスして使用します。 + *自動更新*: ACM は証明書の更新を自動的に処理し、新しい証明書をデプロイする準備ができたら通知します。詳しくは、[ACM の Amazon EventBridge サポート](supported-events.md) を参照してください。 + *コスト効率*: 作成したエクスポート可能なパブリック証明書に対してのみ支払います。 + *柔軟なデプロイ*: 標準の [SSL/TLS 証明書をサポートするサーバーまたはアプリケーションで証明書](acm-concepts.md#concept-sslcert) を使用します。 ## ACM エクスポート可能なパブリック証明書の仕組み ACM エクスポート可能なパブリック証明書の仕組みを以下に示します。 1. ドメインの ACM を使用して、エクスポート可能な証明書をリクエストします。 1. DNS または E メールの検証を使用してドメインの所有権を検証します。 1. 証明書、秘密キー、および証明書チェーンをエクスポートします。 1. 証明書をサーバー、またはアプリケーションにデプロイします。 1. ACM は更新を管理し、新しい証明書が利用可能になったときに通知を送信します。 ## セキュリティに関する考慮事項 以下は、ACM エクスポート可能なパブリック証明書を使用する際のセキュリティ上の考慮事項です。詳しくは、[でのデータ保護 AWS Certificate Manager](data-protection.md) を参照してください。 + 安全なストレージとアクセスコントロールを使用して、エクスポートされたプライベートキーを保護します。 + キーの侵害が疑われる場合は、ACM の失効機能を使用します。 + 更新された証明書をデプロイするときに、適切なキーローテーション手順を実装します。 ## 制限事項 ACM 証明書の制限事項を次に示します。 + 証明書の有効期間は 198 日間です。 + ACM は、有効期限の 45 日前に失効するように設定された証明書を更新します。 + エクスポートされた証明書のデプロイプロセスを管理する必要があります。 ## 料金 で作成したエクスポート可能なパブリック SSL/TLS 証明書には追加料金がかかります AWS Certificate Manager。最新の ACM 料金情報については、 AWS ウェブサイトの[AWS Certificate Manager 「サービス料金](https://aws.amazon.com//certificate-manager/pricing/)」ページを参照してください。 ## ベストプラクティス ACM 証明書を使用する際のベストプラクティスを以下に示します。 + 証明書が更新されたら、すぐに使用を開始する必要があります。 + 更新された証明書の自動デプロイプロセスをテストして実装します。 + [Amazon EventBridge メトリクスとアラーム](supported-events.md)　を使用して証明書のデプロイをモニタリングします。 # AWS Certificate Manager パブリック証明書をエクスポートする 次の手順では、ACM コンソールで ACM パブリック証明書をエクスポートする方法を説明します。または、 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/export-certificate.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/export-certificate.html) AWS CLI または [ExportCertificate](https://docs.aws.amazon.com//acm/latest/APIReference/API_ExportCertificate.html) API アクションを使用することもできます。 **注記** 2025 年 6 月 17 日より前に作成された ACM パブリック証明書は、エクスポートできません。 ## パブリック証明書のエクスポート (コンソール) 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/) で ACM コンソールを開きます。 1. **[List certificates]** (証明書を一覧表示する) を選択し、エクスポートする証明書のチェックボックスをオンにします。 1. あるいは、証明書を選択することもできます。証明書の詳細ページで、**[Export]** (エクスポート) を選択します。 1. **[More actions]** (その他のアクション) を選択し、 **[Export]** (エクスポート) を選択します。 1. プライベートキーのパスフレーズを入力して確定します。 1. 証明書ファイルは、ダウンロードまたはコピーできます。 **注記** ACM コンソールでは、.pem 証明書ファイルをエクスポートできます。.pem ファイルを .ppk などの別のファイル形式に変換できます。詳細については、「[re:Post の記事](https://repost.aws/knowledge-center/ec2-ppk-pem-conversion)」を参照してください。 ## パブリック証明書のエクスポート (AWS CLI) [https://docs.aws.amazon.com/cli/latest/reference/acm/export-certificate.html](https://docs.aws.amazon.com/cli/latest/reference/acm/export-certificate.html) AWS CLI コマンドまたは [ExportCertificate](https://docs.aws.amazon.com//acm/latest/APIReference/API_ExportCertificate.html) API アクションを使用して、パブリック証明書とプライベートキーをエクスポートします。コマンドを実行するときにパスフレーズを割り当てる必要があります。セキュリティを強化するには、ファイルエディタを使用してパスフレーズをファイルに保存し、ファイルを指定することでパスフレーズを指定します。これにより、パスフレーズがコマンド履歴に格納されるのを防ぎ、入力時に他のユーザーがパスフレーズを見るのを防ぎます。 **注記** パスフレーズを含むファイルは、ラインターミネータで終了してはなりません。パスワードファイルは、次のように確認できます。 ``` $ file -k passphrase.txt passphrase.txt: ASCII text, with no line terminators ``` 次の例では、コマンド出力を `jq` にパイプして PEM 形式を適用しています。 ``` [Windows/Linux]$ aws acm export-certificate \ --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/certificate_ID \ --passphrase fileb://path-to-passphrase-file \ | jq -r '"\(.Certificate)\(.CertificateChain)\(.PrivateKey)"' ``` これにより base64 でエンコードされた PEM 形式の証明書が出力されます。これには、次の省略された例のように、証明書チェーンと暗号化されたプライベートキーも含まれます。 ``` -----BEGIN CERTIFICATE----- MIIDTDCCAjSgAwIBAgIRANWuFpqA16g3IwStE3vVpTwwDQYJKoZIhvcNAQELBQAw EzERMA8GA1UECgwIdHJvbG9sb2wwHhcNMTkwNzE5MTYxNTU1WhcNMjAwODE5MTcx NTU1WjAXMRUwEwYDVQQDDAx3d3cuc3B1ZHMuaW8wggEiMA0GCSqGSIb3DQEBAQUA ... 8UNFQvNoo1VtICL4cwWOdLOkxpwkkKWtcEkQuHE1v5Vn6HpbfFmxkdPEasoDhthH FFWIf4/+VOlbDLgjU4HgtmV4IJDtqM9rGOZ42eFYmmc3eQO0GmigBBwwXp3j6hoi 74YM+igvtILnbYkPYhY9qz8h7lHUmannS8j6YxmtpPY= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIC8zCCAdugAwIBAgIRAM/jQ/6h2/MI1NYWX3dDaZswDQYJKoZIhvcNAQELBQAw EzERMA8GA1UECgwIdHJvbG9sb2wwHhcNMTkwNjE5MTk0NTE2WhcNMjkwNjE5MjA0 NTE2WjATMREwDwYDVQQKDAh0cm9sb2xvbDCCASIwDQYJKoZIhvcNAQEBBQADggEP ... j2PAOviqIXjwr08Zo/rTy/8m6LAsmm3LVVYKLyPdl+KB6M/+H93Z1/Bs8ERqqga/ 6lfM6iw2JHtkW+q4WexvQSoqRXFhCZWbWPZTUpBS0d4/Y5q92S3iJLRa/JQ0d4U1 tWZyqJ2rj2RL+h7CE71XIAM//oHGcDDPaQBFD2DTisB/+ppGeDuB -----END CERTIFICATE----- -----BEGIN ENCRYPTED PRIVATE KEY----- MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUMrZb7kZJ8nTZg7aB 1zmaQh4vwloCAggAMB0GCWCGSAFlAwQBKgQQDViroIHStQgNOjR6nTUnuwSCBNAN JM4SG202YPUiddWeWmX/RKGg3lIdE+A0WLTPskNCdCAHqdhOSqBwt65qUTZe3gBt ... ZGipF/DobHDMkpwiaRR5sz6nG4wcki0ryYjAQrdGsR6EVvUUXADkrnrrxuHTWjFl wEuqyd8X/ApkQsYFX/nhepOEIGWf8Xu0nrjQo77/evhG0sHXborGzgCJwKuimPVy Fs5kw5mvEoe5DAe3rSKsSUJ1tM4RagJj2WH+BC04SZWNH8kxfOC1E/GSLBCixv3v +Lwq38CEJRQJLdpta8NcLKnFBwmmVs9OV/VXzNuHYg== -----END ENCRYPTED PRIVATE KEY----- ``` すべてをファイルに出力するには、前出の例に `>` リダイレクトを追加し、次の結果を得ます。 ``` $ aws acm export-certificate \ --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/certificate_ID \ --passphrase fileb://path-to-passphrase-file \ | jq -r '"\(.Certificate)\(.CertificateChain)\(.PrivateKey)"' \ > /tmp/export.txt ``` # ACM 証明書を使用して Kubernetes ワークロードを保護する AWS Controllers for Kubernetes (ACK) で AWS Certificate Manager エクスポート可能なパブリック証明書を使用して、ACM から Kubernetes ワークロードにパブリック TLS 証明書を発行およびエクスポートできます。この統合により、Amazon Elastic Kubernetes Service (Amazon EKS) ポッドを保護し、Kubernetes Ingress で TLS を終了できます。開始するには、GitHub の[「ACM Controller for Kubernetes](https://github.com/aws-controllers-k8s/acm-controller)」を参照してください。 AWS Controllers for Kubernetes (ACK) は、Kubernetes API を拡張して、ネイティブ Kubernetes マニフェストを使用して AWS リソースを管理します。ACM 用 ACK サービスコントローラーは、Kubernetes ワークフロー内で証明書のライフサイクル管理を自動化します。Kubernetes で ACM 証明書リソースを作成すると、ACK コントローラーは次のアクションを実行します。 1. 証明書署名リクエスト (CSR) を生成する ACM から証明書をリクエストします。 1. ドメイン検証が完了し、ACM が証明書を発行するのを待ちます。 1. `exportTo` フィールドが指定されている場合、 は発行された証明書とプライベートキーをエクスポートし、指定した Kubernetes シークレットに保存します。 1. `exportTo` フィールドが指定され、証明書が更新対象である場合、 は有効期限が切れる前に更新された証明書で Kubernetes シークレットを更新します。 パブリックに発行された証明書は、ACM が発行する前に[ドメイン検証](https://docs.aws.amazon.com//acm/latest/userguide/dns-validation.html)が必要です。[Amazon Route 53 の ACK サービスコントローラー](https://github.com/aws-controllers-k8s/route53-controller)を使用して、ホストゾーンに必要な DNS 検証 CNAME レコードを自動的に作成できます。 ## 証明書の使用オプション Kubernetes では、いくつかの方法で ACM 証明書を使用できます。 ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/acm/latest/userguide/images/kubernetes-acm.png) 1. *ロードバランサーの終了 (エクスポートなし)*: ACK を介して証明書を発行し、それらを使用して AWS ロードバランサーで TLS を終了します。証明書は ACM に残り、[AWS Load Balancerコントローラー](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.1/guide/ingress/cert_discovery/)によって自動的に検出されます。この方法では、証明書をエクスポートする必要はありません。 1. *イングレス終了 (エクスポートあり)*: ACM から証明書をエクスポートし、イングレスレベルで TLS 終了のために Kubernetes シークレットに保存します。これにより、Kubernetes ワークロード内で証明書を直接使用できます。 **注記** プライベート証明書を必要とするユースケースについては、「証明書マネージャープラグインである [AWS Private CA Connector for Kubernetes](https://docs.aws.amazon.com//privateca/latest/userguide/PcaKubernetes-concepts.html)」を参照してください。 ## 前提条件 ACM 用の ACK サービスコントローラーをインストールする前に、以下があることを確認してください。 + Kubernetes クラスター。 + Helm がインストールされました。 + クラスターと通信できるように `kubectl` が設定されている。 + `eksctl` EKS でポッド ID の関連付けを設定するためにインストールされている。 ## ACM 用の ACK サービスコントローラーをインストールする Helm を使用して、ACM 用の ACK サービスコントローラーを Amazon EKS クラスターにインストールします。 1. ACK コントローラーの名前空間を作成します。 ``` $ kubectl create namespace ack-system --dry-run=client -o yaml | kubectl apply -f - ``` 1. ACK コントローラーのポッド ID 関連付けを作成します。*CLUSTER\$1NAME* をクラスター名に、*REGION* を AWS リージョンに置き換えます。 ``` $ eksctl create podidentityassociation --cluster CLUSTER_NAME --region REGION \ --namespace ack-system \ --create-service-account \ --service-account-name ack-acm-controller \ --permission-policy-arns arn:aws:iam::aws:policy/AWSCertificateManagerFullAccess ``` 1. Amazon ECR Public レジストリにログインします。 ``` $ aws ecr-public get-login-password --region us-east-1 | helm registry login --username AWS --password-stdin public.ecr.aws ``` 1. ACM 用の ACK サービスコントローラーをインストールします。*REGION* を自分の AWS リージョンに置き換えます。 ``` $ helm install -n ack-system ack-acm-controller oci://public.ecr.aws/aws-controllers-k8s/acm-chart --set serviceAccount.create=false --set serviceAccount.name=ack-acm-controller --set aws.region=REGION ``` 1. コントローラーが実行されていることを確認します。 ``` $ kubectl get pods -n ack-system ``` ポッド ID の関連付けの詳細については、*「Amazon* [EKS ユーザーガイド」の「EKS Pod Identity](https://docs.aws.amazon.com//eks/latest/userguide/pod-identities.html)」を参照してください。 ## 例: Ingress で TLS を終了する 次の例は、ACM 証明書をエクスポートし、それを使用して Kubernetes Ingress レベルで TLS を終了する方法を示しています。この設定では、ACM 証明書を作成し、Kubernetes シークレットにエクスポートし、TLS 終了に証明書を使用するように Ingress リソースを設定します。 この例では、以下のようになっています： + エクスポートされた証明書を保存するためにシークレットが作成されます (`exported-cert-secret`) + ACK Certificate リソースは、ドメインの ACM に証明書をリクエストし、シー`exported-cert-secret`クレットにエクスポートします。 + Ingress リソースは を参照して`exported-cert-secret`、受信トラフィックの TLS を終了します。 `${HOSTNAME}` を独自のドメイン名に置き換えます。 ``` apiVersion: v1 kind: Secret type: kubernetes.io/tls metadata: name: exported-cert-secret namespace: demo-app data: tls.crt: "" tls.key: "" --- apiVersion: acm.services.k8s.aws/v1alpha1 kind: Certificate metadata: name: exportable-public-cert namespace: demo-app spec: domainName: ${HOSTNAME} options: certificateTransparencyLoggingPreference: ENABLED exportTo: namespace: demo-app name: exported-cert-secret key: tls.crt --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-traefik namespace: demo-app spec: tls: - hosts: - ${HOSTNAME} secretName: exported-cert-secret ingressClassName: traefik rules: - host: ${HOSTNAME} http: paths: - path: / pathType: Prefix backend: service: name: whoami port: number: 80 ``` デプロイされると、ACM の ACK サービスコントローラーは更新を含む証明書のライフサイクルを自動的に管理します。ACM が証明書を更新すると、コントローラーはシー`exported-cert-secret`クレットを新しい証明書で更新し、Ingress が手動で介入することなく有効な証明書を使用し続けます。 # AWS Certificate Manager パブリック証明書を取り消す AWS Certificate Manager エクスポート可能なパブリック証明書は、ACM コンソール AWS CLI、または API アクションを使用して取り消すことができます。 **警告** 証明書が取り消された後は、その証明書を再利用することはできません。証明書の取り消しは永久に有効です。 組織のポリシーに準拠したり、キーの侵害を軽減するために、証明書を取り消す必要がある場合があります。証明書を取り消す場合は理由が必要です。次の理由を使用できます。 + 未指定 + 所属が変更されました + 優先 + オペレーションの停止 詳細については、[Amazon Trust Services Certificate Subscriber Agreement](https://www.amazontrust.com/repository/sa-1.3.pdf) および[Amazon Trust Service](https://www.amazontrust.com/repository/) を参照してください。 AWS には、証明書失効をチェックするための 2 つのサービスがあります。オンライン証明書ステータスプロトコル (OCSP) と証明書失効リストです。OCSP では、クライアントは権限のある失効データベースをクエリして、リアルタイムでステータスを返します。OCSP は、証明書に埋め込まれた検証情報に依存します。 ## 考慮事項 証明書を取り消す前に考慮すべき事項を次に示します。 + 取り消すことができるのは、以前にエクスポートされた証明書のみです。 + [エクスポート不可能なパブリック証明書](acm-exportable-certificates.md) を取り消すことはできません。これらの証明書が不要になった場合は、[削除](gs-acm-delete.md)する必要があります。 + 証明書が不要になった場合は、証明書を取り消す代わりに[証明書を削除](gs-acm-delete.md)する必要があります。 + 証明書の失効プロセスはグローバルです。取り消すことを選択したすべての有効な証明書は、関連付けられている ARN とともに取り消されます。 + 証明書の失効は永久に有効です。失効した証明書を取得して再利用することはできません。 + 証明書の失効が有効になるまでに、最大 24 時間かかる場合があります。 ## 証明書の取り消し (コンソール) 次の手順では、ACM パブリックまたはプライベート証明書を取り消す方法について説明します。 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/) で ACM コンソールを開きます。 1. **[List certificates]** (証明書を一覧表示する) を選択し、取り消す証明書のチェックボックスを選択します。 1. あるいは、証明書を選択することもできます。証明書の詳細ページで、**取り消し**を選択します。 1. **[More actions]** (その他のアクション) を選択し、**[Revoke]** (取り消し)を選択します。 1. 取り消し理由を入力し、**revoke** と入力して、**取り消し** を選択する必要があるダイアログボックスが表示されます。 ## 証明書の取り消し (AWS CLI) [https://docs.aws.amazon.com//cli/latest/reference/acm-pca/revoke-certificate.html](https://docs.aws.amazon.com//cli/latest/reference/acm-pca/revoke-certificate.html) AWS CLI コマンドまたは [https://docs.aws.amazon.com/acm/latest/APIReference/API_RevokeCertificate.html](https://docs.aws.amazon.com/acm/latest/APIReference/API_RevokeCertificate.html) API アクションを使用して、ACM パブリック証明書またはプライベート証明書を取り消します。[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/list-certificates.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/list-certificates.html) コマンドを呼び出すことで証明書の ARN を取得できます。 ``` $ aws acm revoke-certificate \ --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/12345678-1234-1234-1234 \ --revocation-reason "UNSPECIFIED" ``` **警告** 証明書が取り消された後は、その証明書を再利用することはできません。証明書の取り消しは永久に有効です。 以下は `revoke-certificate` コマンドの出力です。 ``` arn:aws:acm:us-east-1:111122223333:certificate/12345678-1234-1234-1234 ``` # 自動更新イベントを設定する AWS Certificate Manager エクスポート可能なパブリック証明書と Amazon EventBridge を使用すると、証明書の自動更新イベントを設定できます。 1. 証明書の更新を監視するために Amazon EventBridge イベントを設定します。詳細については、「[ACM の Amazon EventBridge サポート](https://docs.aws.amazon.com//acm/latest/userguide/cloudwatch-events.html)」を参照してください。 1. 更新が発生したときに証明書のデプロイを処理する自動化を作成します。詳しくは、[ACM での Amazon EventBridge を使用してアクションを開始](example-actions.md) を参照してください。 1. 更新またはデプロイの失敗を警告するように、EventBridge イベントを設定します。 # 証明書の更新を強制する ACM パブリック証明書とプライベート証明書は、ACM コンソール、[更新証明書](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/renew-certificate.html) AWS CLI、または [https://docs.aws.amazon.com/acm/latest/APIReference/API_RenewCertificate.html](https://docs.aws.amazon.com/acm/latest/APIReference/API_RenewCertificate.html) API アクションを使用して更新できます。更新できるのは、以前にエクスポートされた証明書のみです。 **重要** ACM エクスポート可能なパブリック証明書を更新すると、追加料金が発生します。最新の ACM 料金情報については、 AWS ウェブサイトの[AWS Certificate Manager 「サービス料金](https://aws.amazon.com//certificate-manager/pricing/)」ページを参照してください。 ## 証明書を更新するには (コンソール) 次の手順では、ACM パブリックまたはプライベート証明書を強制的に更新する方法について説明します。 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/) で ACM コンソールを開きます。 1. **[List certificates]** (証証明書を一覧表示する) を選択し、更新する証明書のチェックボックスをオンにします。 1. あるいは、証明書を選択することもできます。証明書の詳細ページで、**[Renew]** (更新) を選択します。 1. **[More actions]** (その他のアクション) を選択し、**[Renew]** (更新) を選択します。 1. ダイアログボックスが表示されるので、**renew** と入力して **[Renew]** (更新) を選択します。 ## 証明書を更新するには (AWS CLI) [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/renew-certificate.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/renew-certificate.html) AWS CLI コマンドまたは [https://docs.aws.amazon.com/acm/latest/APIReference/API_RenewCertificate.html](https://docs.aws.amazon.com/acm/latest/APIReference/API_RenewCertificate.html) API アクションを使用して、ACM パブリック証明書またはプライベート証明書を更新します。[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/list-certificates.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm/list-certificates.html) コマンドを呼び出すことで証明書の ARN を取得できます。`renew-certificate` コマンドはレスポンスを返しません。 ``` $ aws acm renew-certificate \ --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/12345678-1234-1234-1234-123456789012 ``` # AWS Certificate Manager パブリック証明書のドメイン所有権を検証する Amazon 認証局 (CA) がサイトの証明書を発行する前に、 AWS Certificate Manager (ACM) は、ユーザーがリクエストで指定したすべてのドメイン名の所有者または管理者であることを証明する必要があります。所有権を証明するには、ドメインネームシステム (DNS) 検証、E メール検証、または HTTP 検証を使用して所有権を証明することを選択できます。 **注記** 検証は、ACM によって発行されたパブリックに信頼できる証明書にのみ適用されます。ACM は、[インポートされた証明書](import-certificate.md)の、またはプライベート CA によって署名された証明書のドメインの所有権を検証しません。ACM は Amazon VPC [プライベートホストゾーン](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones)または他のプライベートドメインのリソースを検証できません。詳しくは、[証明書の検証のトラブルシューティング](certificate-validation.md) を参照してください。 次の理由により、E メール検証よりも DNS 検証を使用することをお勧めします。 + Amazon Route 53 を使用してパブリック DNS レコードを管理する場合、ACM を使用してレコードを直接更新できます。 + 証明書は使用中で DNS レコードが残っている状態であれば、DNS で検証済みの証明書は ACM によって自動的に更新されます。 + E メール検証された証明書は、ドメイン所有者によるアクションが必要です。ACM は、有効期限切れの 45 日前に更新通知の送信を開始します。これらの通知は、ドメインの 5 つの一般的な管理者アドレスの 1 つまたは複数に送信されます。通知には、ドメイン所有者が簡単に更新するためにクリックできるリンクが含まれています。リストされているすべてのドメインが検証されると、ACM は同じ ARN で更新された証明書を発行します。 ドメインの DNS データベースを編集できない場合は、代わりに [E メール検証](email-validation.md)を使用する必要があります。 HTTP 検証は、CloudFront で使用される証明書で使用できます。この方法では、HTTP リダイレクトを使用してドメインの所有権を証明し、DNS 検証と同様の自動更新を提供します。 **注記** E メール検証を使用して証明書を作成した後は、DNS による検証に切り替えることはできません。DNS 検証を使用するには、証明書を削除し、DNS 検証を使用する新しい証明書を作成します。 **Topics** + [AWS Certificate Manager DNS 検証](dns-validation.md) + [AWS Certificate Manager E メール検証](email-validation.md) + [AWS Certificate Manager HTTP 検証](http-validation.md) # AWS Certificate Manager DNS 検証 ドメインネームシステム (DNS) は、ネットワークに接続されているリソースのディレクトリサービスです。DNS プロバイダーは、ドメインを定義するレコードを含むデータベースを維持します。DNS 検証を選択すると、このデータベースに追加する必要がある 1 つ以上の CNAME レコードが ACM から提供されます。これらのレコードには、ドメインを制御する証拠となる一意のキーと値のペアが含まれています。 **注記** E メール検証を使用して証明書を作成した後は、DNS による検証に切り替えることはできません。DNS 検証を使用するには、証明書を削除し、DNS 検証を使用する新しい証明書を作成します。 例えば、追加の名前として `example.com` を使用して `www.example.com` ドメインの証明書をリクエストする場合、ACM によって 2 つの CNAME レコードが作成されます。各レコードは、ユーザーのドメインおよびアカウントに固有のものとして作成され、名前と値が含まれます。値は、ACM が証明書を自動的に更新するために使用する AWS ドメインを指すエイリアスです。CNAME レコードを DNS データベースに追加できるのは 1 回のみです。証明書は使用中で CNAME レコードが残っている状態であれば、証明書は ACM によって自動的に更新されます。 **重要** パブリック DNS レコードを管理するために Amazon Route 53 を使用しない場合は、レコードの追加方法について DNS プロバイダーに問い合わせてください。ドメインの DNS データベースを編集する権限がない場合は、代わりに [E メール検証](email-validation.md)を使用する必要があります。 検証を繰り返さなくても、CNAME レコードが残っている限り、完全修飾ドメイン名 (FQDN) で追加の ACM 証明書をリクエストできます。つまり、同じドメイン名を持つ置換証明書、または異なるサブドメインを対象とする証明書を作成できます。CNAME 検証トークンはどの AWS リージョンでも機能するため、複数のリージョンで同じ証明書を再作成できます。また、削除された証明書を置き換えることもできます。 自動更新を停止するには、関連付けられている AWS サービスから証明書を削除するか、CNAME レコードを削除します。DNS プロバイダーが Route 53 ではない場合は、レコードを削除する方法をプロバイダーに問い合わせてください。Route 53 がプロバイダーである場合は、Route 53 開発者ガイドの「[リソースレコードセットの削除](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-deleting.html)」を参照してください。証明書のマネージド型更新の詳細については、[でのマネージド証明書の更新 AWS Certificate Manager](managed-renewal.md) を参照してください。 **注記** DNS 構成で 5 つを超える CNAME が連結されている場合、CNAME 解決は失敗します。より長いチェーンが必要な場合は、[E メール検証](email-validation.md)を使用することをお勧めします。 ## ACM の CNAME レコードの 仕組み **注記** このセクションは、Route 53 を DNS プロバイダーとして使用していないユーザーを対象としています。 Route 53 を DNS プロバイダーとして使用していない場合は、ACM から提供された CNAME レコードを、プロバイダーのデータベースに (通常は Web サイトを介して) 手動で入力する必要があります。CNAME レコードは、リダイレクトメカニズムやベンダー固有のメタデータのコンテナーとしてなど、さまざまな目的で使用されます。ACM では、これらのレコードにより、初期ドメイン所有権の検証と継続的な自動証明書の更新が可能になります。 次の表に、6 つのドメイン名に対する CNAME レコードの例を示します。各レコードの**レコード名**-**レコード値**ペアは、ドメイン名の所有権を認証する役割を果たします。 表では、最初の 2 つの**レコード名**-**レコード値**のペアは同じです。これは、`*.example.com` など、ワイルドカードドメインの場合、ACM によって作成された文字列が、そのベースドメイン `example.com` で作成されたものと同じになることを示します。それ以外の場合は、ペアの**レコード名**および**レコード値**は、ドメイン名ごとに異なります。 **CNAME レコードの例** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/acm/latest/userguide/dns-validation.html) アンダースコア (\$1) に続く *xN* の値は、ACM によって生成される長い文字列です。例: ``` _3639ac514e785e898d2646601fa951d5.example.com. ``` が生成される一般的な**レコード名**です。関連付けされた**レコード値**は ``` _98d2646601fa951d53639ac514e785e8.acm-validation.aws. ``` 同じ DNS レコードで。 **注記** DNS プロバイダーがアンダースコアで始まる CNAME 値をサポートしていない場合は、「[DNS 検証の問題のトラブルシューティング](troubleshooting-DNS-validation.md)」を参照してください。 証明書をリクエストし、DNS 検証を指定すると、ACM は次の形式で CNAME 情報を提供します。 **** | ドメイン名 | レコード名 | レコードタイプ | レコード値 | | --- | --- | --- | --- | | example.com | \$1a79865eb4cd1a6ab990a45779b4e0b96.example.com。 | CNAME | \$1424c7224e9b0146f9a8808af955727d0.acm-validations.aws。 | ドメイン名は、証明書に関連付けられた FQDN です。レコード名は、キーと値のペアのキーとして機能するレコードを一意に識別します。レコード値は、キーと値のペアの値として機能します。 これらの 3 つの値 (ドメイン名、レコード名、レコード値) はすべて、DNS レコードを追加するための DNS プロバイダーのウェブインターフェイスの該当するフィールドに入力する必要があります。プロバイダーは、レコード名 (または単に「名前」) フィールドの処理に一貫性がありません。場合によっては、上記のように文字列全体を提供することが期待されます。他のプロバイダーは、入力したどの文字列にも自動的にドメイン名を付加します。つまり、(この例では) ``` _a79865eb4cd1a6ab990a45779b4e0b96 ``` 名前フィールドのみに入力することを意味します。これについて間違っていると思われる場合は、ドメイン名を含むレコード名 (`.example.com` など) を入力すると、次のようになります。 ``` _a79865eb4cd1a6ab990a45779b4e0b96.example.com.example.com. ``` この場合、検証は失敗します。したがって、プロバイダーが期待する入力のタイプを事前に決定する必要があります。 ## DNS 検証のセットアップ このセクションでは、DNS 検証を使用するためにパブリック証明書を設定する方法について説明します。 **コンソールで DNS 検証を設定するには** **注記** この手順では、少なくとも 1 つの証明書がすでに作成されており、それを作成した AWS リージョンで作業していることを前提としています。コンソールを開き、代わりに最初に使用する画面が表示する場合、またはコンソールを正常に開き、一覧に証明書が表示されない場合は、正しいリージョンが指定されていることを確認してください。 1. ACM コンソール ([https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/)) を開きます。 1. 証明書のリストで、証明書の設定を行う [**Pending validation**] (検証保留中) ステータスが付いた証明書の [**Certificate ID**] (証明書 ID) を選択します。このように、証明書の詳細ページを開きます。 1. [**Domains**] (ドメイン) セクションで、次の 2 つの手順の 1 つを完了します。 1. (オプション) Route 53 で検証します。 次の条件が true である場合に、アクティブな [**Create record in Route 53**] (Route 53 でレコードを作成) ボタンが表示されます。 + Route 53 を DNS プロバイダーとして使用します。 + Route 53 がホストするゾーンに対する書き込み許可があります。 + FQDN がまだ検証されていません。 **注記** 実際に Route 53 を使用しているが、[**Create record in Route 53**] (Route 53 でレコードを作成) が見つからないか無効になっている場合は、[ACM コンソールで [Create record in Route 53] ボタンが表示されない](troubleshooting-DNS-validation.md#troubleshooting-route53-1) を参照してください。 [**Create record in Route 53**] (Route 53 でレコードを作成) を選択し、[**Create records**] (レコードを作成) を選択します。[**Certificate status**] (証明書のステータス) ページで、[**Successfully created DNS records**] (DNS レコードが正常に作成された) ことを伝えるステータスバナーと共にページが開くでしょう。 新しい証明書は [**Pending validation**] (検証保留中) のステータスを最大 30 分間表示し続けます。 **ヒント** ACM が自動的に Route 53 にレコードを作成するようプログラムによってリクエストすることはできません。ただし、Route 53 を AWS CLI または API コールして、Route 53 DNS データベースにレコードを作成できます。Route 53 レコードセットの詳細については、「[リソースレコードセットの使用](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)」を参照してください。 1. (オプション) Route 53 を DNS プロバイダーとして使用していない場合は、CNAME 情報を取得し、それを DNS データベースに追加する必要があります。新しい証明書の詳細ページで次の 2 つのいずれかの方法を使用して、この処理を行うことができます。 + [**Domains**] (ドメイン) セクションに表示されている CNAME コンポーネントをコピーします。この情報は、DNS データベースに手動で追加する必要があります。 + 別の方法としては、[**Export to CSV**] (CSV へエクスポート) を選択します。結果ファイル内の情報は、DNS データベースに手動で追加する必要があります。 **重要** 検証の問題を回避するには、DNS プロバイダーのデータベースに情報を追加する前に、[ACM の CNAME レコードの 仕組み](#cnames-overview) をレビューします。問題が発生した場合は、[DNS 検証の問題のトラブルシューティング](troubleshooting-DNS-validation.md) を参照してください。 CNAME の値を生成してから 72 時間以内に ACM でドメイン名が検証されない場合、ACM では証明書のステータスが [**Validation timed out**] に変更されます。この結果が生じる主な理由として、DNS 設定を ACM によって生成された値で正常に更新しなかったことが考えられます。この問題を修正するには、CNAME の手順を確認してから新しい証明書をリクエストする必要があります。 # AWS Certificate Manager E メール検証 Amazon 認証局 (CA) がサイトの証明書を発行する前に、 AWS Certificate Manager (ACM) は、ユーザーがリクエストで指定したすべてのドメインの所有者または管理者であることを確認する必要があります。E メールまたは DNS のいずれかを使用して検証を実行できます。このトピックでは、E メール検証について説明します。 E メール検証を使用して問題が発生した場合は、[E メール検証の問題のトラブルシューティング](troubleshooting-email-validation.md) を参照してください。 ## E メール検証の仕組み ACM は、ドメインごとに次の 5 つの一般的なシステム E メールに検証 E メールメッセージを送信します。これらの E メールをスーパードメインで受信する場合は、そのスーパードメインを検証ドメインとして指定することもできます。ベースとなるウェブサイトアドレスまでの任意のサブドメインは有効であり、`@` の後に追加されて E メールアドレスのドメインとして使用されます。たとえば、subdomain.example.com の検証ドメインとして example.com を指定すると、admin@example.com に E メールが届きます。 + administrator@your\$1domain\$1name + hostmaster@your\$1domain\$1name + postmaster@your\$1domain\$1name + webmaster@your\$1domain\$1name + admin@your\$1domain\$1name ドメインを所有していることを証明するには、これらの E メールに含まれている検証リンクを選択する必要があります。ACM は、証明書の有効期限の 45 日前に、証明書を更新するために、これらの同じアドレスに検証 E メールを送信します。 ACM API または CLI を使用したマルチドメイン証明書リクエストの E メール検証では、リクエストに他のドメインのサブドメインが含まれていても、リクエストした各ドメインごとに E メールメッセージが送信されます。ドメイン所有者は、ACM が証明書を発行する前に、これらの各ドメインの E メールメッセージを検証する必要があります。 **このプロセスの例外** **www** またはワイルドカードアスタリスク (**\$1**) で始まるドメイン名に対して ACM 証明書をリクエストする場合、ACM は、先頭の **www** またはアスタリスクを削除し、管理アドレスに E メールを送信します。これらのアドレスはドメイン名の残りの部分に admin@、administrator@、hostmaster@、postmaster@、および webmaster@ を前置することによって形成されます。例えば、www.example.com に ACM 証明書をリクエストする場合、admin@www.example.com の代わりに admin@example.com に E メールが送信されます。同じように、\$1.test.example.com に ACM 証明書をリクエストする場合、admin@test.example.com に E メールが送信されます。残りの一般的な管理者アドレスも、同様に形成されます。 **重要** ACM は、新しい証明書または更新の WHOIS E メール検証をサポートしなくなりました。一般的なシステムアドレスは引き続きサポートされます。詳細については、[ブログ記事](https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/) を参照してください。 ## 考慮事項 E メール検証については、次の考慮事項に従ってください。 + E メール検証を使用するには、ドメインに登録されている作業用 E メールアドレスが必要です。E メールアドレスの設定手順は、このガイドの対象外です。 + 検証は、ACM によって発行されたパブリックに信頼できる証明書にのみ適用されます。ACM は、[インポートされた証明書](import-certificate.md)の、またはプライベート CA によって署名された証明書のドメインの所有権を検証しません。ACM は Amazon VPC [プライベートホストゾーン](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones)または他のプライベートドメインのリソースを検証できません。詳しくは、[証明書の検証のトラブルシューティング](certificate-validation.md) を参照してください。 + E メール検証を使用して証明書を作成した後は、DNS による検証に切り替えることはできません。DNS 検証を使用するには、証明書を削除し、DNS 検証を使用する新しい証明書を作成します。 ## 証明書の有効期限切れと更新 ACM 証明書は 198 日間有効です。証明書を更新するには、ドメイン所有者によるアクションが必要です。ACM は、有効期限切れの 45 日前にドメインに関連付けられた E メールアドレスに更新通知の送信を開始します。通知には、ドメイン所有者が更新するためにクリックできるリンクが含まれています。リストされているすべてのドメインが検証されると、ACM は同じ ARN で更新された証明書を発行します。 ## (オプション) 検証 E メールの再送信 各検証 E メールには、証明書リクエストの承認に使用できるトークンが含まれています。ただし、承認プロセスに必要な検証 E メールがスパムフィルターによってブロックされたり、転送中に紛失した場合、トークンは 72 時間後に自動的に有効期限切れになります。元の E メールを受信しなかった場合、またはトークンの期限が切れた場合は、E メールの再送信をリクエストできます。検証 E メールを再送信する方法については、「[検証 E メールを再送信する](email-renewal-validation.md#request-domain-validation-email-for-renewal)」を参照してください E メール検証に関する永続的な問題については、[に関する問題のトラブルシューティング AWS Certificate Manager](troubleshooting.md) の [E メール検証の問題のトラブルシューティング](troubleshooting-email-validation.md) セクションを参照してください。 # E AWS Certificate Manager メール検証を自動化する E メール検証された ACM 証明書には、通常、ドメイン所有者による手動による操作が必要です。大量の E メール検証された証明書を扱う組織は、必要なレスポンスを自動化できるパーサーを作成することを優先する場合があります。E メール検証を使用するユーザーを支援するために、このセクションの情報は、ドメイン検証 E メールメッセージに使用されるテンプレートと、検証プロセスの完了に関連するワークフローについて説明します。 ## 検証 E メールテンプレート 検証 E メールメッセージは、新しい証明書が要求されるか、既存の証明書が更新されるかに応じて、次の 2 つのいずれかの形式になります。強調表示された文字列の内容は、検証対象のドメインに固有の値に置き換える必要があります。 ### 新しい証明書を検証する E メールテンプレートのテキスト: ``` Greetings from Amazon Web Services, We received a request to issue an SSL/TLS certificate for requested_domain. Verify that the following domain, AWS account ID, and certificate identifier correspond to a request from you or someone in your organization. Domain: fqdn AWS account ID: account_id AWS Region name: region_name Certificate Identifier: certificate_identifier To approve this request, go to Amazon Certificate Approvals (https://region_name.acm-certificates.amazon.com/approvals?code=validation_code&context=validation_context) and follow the instructions on the page. This email is intended solely for authorized individuals for fqdn. To express any concerns about this email or if this email has reached you in error, forward it along with a brief explanation of your concern to validation-questions@amazon.com. Sincerely, Amazon Web Services ``` ### 更新のための証明書の検証 E メールテンプレートのテキスト: ``` Greetings from Amazon Web Services, We received a request to issue an SSL/TLS certificate for requested_domain. This email is a request to validate ownership of the domain in order to renew the existing, currently in use, certificate. Certificates have defined validity periods and email validated certificates, like this one, require you to re-validate for the certificate to renew. Verify that the following domain, AWS account ID, and certificate identifier correspond to a request from you or someone in your organization. Domain: fqdn AWS account ID: account_id AWS Region name: region_name Certificate Identifier: certificate_identifier To approve this request, go to Amazon Certificate Approvals at https://region_name.acm-certificates.amazon.com/approvals?code=$validation_code&context=$validation_context and follow the instructions on the page. This email is intended solely for authorized individuals for fqdn. You can see more about how AWS Certificate Manager validation works here - https://docs.aws.amazon.com/acm/latest/userguide/email-validation.html. To express any concerns about this email or if this email has reached you in error, forward it along with a brief explanation of your concern to validation-questions@amazon.com. Sincerely, Amazon Web Services -- Amazon Web Services, Inc. is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message produced and distributed by Amazon Web Services, Inc., 410 Terry Ave. North, Seattle, WA 98109-5210. (c)2015-2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Our privacy policy is posted at https://aws.amazon.com/privacy ``` から新しい検証メッセージを受け取ったら AWS、パーサーのup-to-date信頼できるテンプレートとして使用することをお勧めします。2020 年 11 月より前に設計されたメッセージパーサーを持っているユーザーは、テンプレートに対して行われた次の変更に注意する必要があります。 + E メール件名は、「`Certificate request for domain name`」ではなく、「`"Certificate approval for domain name`」のようになります。 + `AWS account ID` がダッシュやハイフンなしで表示されるようになりました。  + `Certificate Identifier` では、短縮形式の代わりに証明書 ARN 全体が表示されます。たとえば、`3b4d78e1-0882-4f51-954a-298ee44ff369` ではなく、`arn:aws:acm:us-east-1:000000000000:certificate/3b4d78e1-0882-4f51-954a-298ee44ff369` となります。 + 証明書の承認 URL に、`certificates.amazon.com` ではなく、`acm-certificates.amazon.com` が含まれるようになりました。 + 証明書の承認 URL をクリックして開いた承認フォームに、承認ボタンが含まれるようになりました。承認ボタン div の名前が、`approval_button` ではなく、`approve-button` となりました。 + 新しくリクエストされた証明書と更新証明書の両方の検証メッセージは、同じ E メール形式です。 ## 検証ワークフロー このセクションでは、E メール検証された証明書の更新ワークフローについて説明します。 + ACM コンソールがマルチドメイン証明書リクエストを処理すると、パブリック証明書をリクエストするときに指定したドメイン名または検証ドメインに検証 E メールメッセージを送信します。ドメイン所有者は、ACM が証明書を発行する前に、各ドメインの E メールメッセージを検証する必要があります。詳細については、「[E メールを使用したドメインの所有権の検証](https://docs.aws.amazon.com/acm/latest/userguide/email-validation.html)」を参照してください。 + ACM API または CLI を使用したマルチドメイン証明書リクエストの E メール検証では、リクエストに他のドメインのサブドメインが含まれていても、リクエストした各ドメインごとに E メールメッセージが送信されます。ドメイン所有者は、ACM が証明書を発行する前に、これらの各ドメインの E メールメッセージを検証する必要があります。 ACM コンソールを使用して既存の証明書の E メールを再送信すると、元の証明書リクエストで指定された検証ドメイン、または検証ドメインが指定されていない場合は対象のドメインに E メールが送信されます。別のドメインで検証 E メールを受信するには、検証に使用する検証ドメインを指定して、新しい証明書をリクエストできます。または、API、SDK、または CLI を使用して、`ValidationDomain` パラメータを使用して [ResendValidationEmail](https://docs.aws.amazon.com/acm/latest/APIReference/API_ResendValidationEmail.html) を呼び出すこともできます。ただし、`ResendValidationEmail` リクエストで指定された検証ドメインは、その呼び出しにのみ使用され、今後の検証 E メール用に証明書 Amazon リソースネーム (ARN) には保存されません。元の証明書リクエストで指定されていないドメイン名で検証 E メールを受信するたびに、`ResendValidationEmail` を呼び出す必要があります。 **注記** 2020 年 11 月以前は、apex ドメインのみを検証する必要がありました。ACM は、サブドメインもカバーする証明書を発行していました。それ以前に設計されたメッセージパーサーを使用しているユーザーは、E メール検証ワークフローの変更に注意する必要があります。 + ACM API または CLI を使用すると、マルチドメイン証明書リクエストに関するすべての検証 E メールメッセージを apex ドメインに送信できます。API では、[RequestCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_RequestCertificate.html) アクションの `DomainValidationOptions` パラメータを使用して `ValidationDomain` の値を指定します。これは、[DomainValidationOption](https://docs.aws.amazon.com/acm/latest/APIReference/API_DomainValidationOption.html) タイプのメンバーです。CLI では、[request-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html) コマンドの **--domain-validation-options** パラメータを使用して、`ValidationDomain` の値を指定します。 # AWS Certificate Manager HTTP 検証 ハイパーテキスト転送プロトコル (HTTP) は、World Wide Web 上のデータ通信の基本プロトコルです。CloudFront で使用される証明書の HTTP 検証を選択すると、ACM はこのプロトコルを活用してドメインの所有権を検証します。ACM は CloudFront と連携して、特定の URL と、ドメイン上のその URL でアクセスできるようにする必要がある一意のトークンを提供します。このトークンは、ドメインを制御する証拠として機能します。ドメインから CloudFront インフラストラクチャ内の ACM 制御のロケーションへのリダイレクトを設定することで、ドメインのコンテンツを変更し、所有権を検証する能力を示します。ACM と CloudFront のシームレスな統合により、特に CloudFront ディストリビューションの証明書発行プロセスが簡素化されます。 **重要** HTTP 検証は、ワイルドカードドメイン証明書 (\$1.example.com など) をサポートしていません。ワイルドカード証明書の場合は、代わりに DNS 検証または E メール検証を使用する必要があります。 例えば、CloudFront を使用して追加名として `www.example.com` を持つ `example.com` ドメインの証明書をリクエストすると、ACM は HTTP 検証用の 2 セットの URLs を提供します。各セットには、ドメインと AWS アカウント専用に作成された `redirectFrom` URL と `redirectTo` URL が含まれています。`redirectFrom` URL は、設定する必要があるドメイン (`http://example.com/.well-known/pki-validation/example.txt` など) のパスです。`redirectTo` URL は、一意の検証トークンが保存されている CloudFront インフラストラクチャ内の ACM 制御のロケーションを指します。これらのリダイレクトは 1 回だけ設定する必要があります。認証機関がドメインの所有権を検証しようとすると、CloudFront が `redirectFrom` URL にリダイレクトする `redirectTo` URL からファイルをリクエストし、検証トークンへのアクセスを許可します。証明書が CloudFront で使用されており、リダイレクトが維持されている限り、ACM は証明書を自動的に更新します。 CloudFront で完全修飾ドメイン名 (FQDN) の HTTP 検証を設定したら、HTTP リダイレクトが設定されている限り、検証プロセスを繰り返すことなく、その FQDN の追加の ACM 証明書をリクエストできます。つまり、同じドメイン名で代替証明書を作成できます。リダイレクトがまだアクティブであれば、検証プロセスを再度実行せずに、削除された証明書を置き換えることもできます。 HTTP 検証済みの証明書の自動更新を停止するには、2 つのオプションがあります。証明書は、関連付けられている CloudFront ディストリビューションから削除するか、検証用に設定した HTTP リダイレクトを削除できます。CloudFront 以外のコンテンツ配信ネットワーク (CDN) またはウェブサーバーを使用してリダイレクトを管理している場合は、そのドキュメントを参照してリダイレクトを削除する方法を確認してください。CloudFront を使用してリダイレクトを管理している場合は、ディストリビューションの設定を更新することでリダイレクトを削除できます。証明書のマネージド型更新の詳細については、[でのマネージド証明書の更新 AWS Certificate Manager](managed-renewal.md) を参照してください。自動更新を停止すると証明書の有効期限が切れ、HTTPS トラフィックが中断される可能性があることにご注意ください。 ## ACM の HTTP リダイレクトの仕組み **注記** このセクションは、コンテンツ配信に CloudFront を使用し、SSL/TLS 証明書管理に ACM を使用しているお客様を対象としています。 ACM と CloudFront で HTTP 検証を使用する場合は、HTTP リダイレクトを設定する必要があります。これらのリダイレクトにより、ACM は最初の証明書発行と継続的な自動更新のためにドメインの所有権を検証できます。リダイレクトメカニズムは、ドメイン上の特定の URL を、一意の検証トークンが保存されている CloudFront インフラストラクチャ内の ACM 制御のロケーションを指すことによって機能します。 次の表は、ドメイン名のリダイレクト設定の例を示しています。HTTP 検証はワイルドカードドメイン (\$1.example.com など) をサポートしていないことにご注意してください。各設定の **Redirect From**-**Redirect To** ペアは、ドメイン名の所有権を認証する役割を果たします。 **HTTP リダイレクト設定の例** | ドメイン名 | Redirect From | Redirect To | Comment | | --- | --- | --- | --- | | example.com | `http://example.com/.well-known/pki-validation/x2.txt` | `https://validation.region.acm-validations.aws/y2/.well-known/pki-validation/x2.txt` | Unique | | www.example.com | `http://www.example.com/.well-known/pki-validation/x3.txt` | `https://validation.region.acm-validations.aws/y3/.well-known/pki-validation/x3.txt` | Unique | | host.example.com | `http://host.example.com/.well-known/pki-validation/x4.txt` | `https://validation.region.acm-validations.aws/y4/.well-known/pki-validation/x4.txt` | Unique | | subdomain.example.com | `http://subdomain.example.com/.well-known/pki-validation/x5.txt` | `https://validation.region.acm-validations.aws/y5/.well-known/pki-validation/x5.txt` | Unique | | host.subdomain.example.com | `http://host.subdomain.example.com/.well-known/pki-validation/x6.txt` | `https://validation.region.acm-validations.aws/y6/.well-known/pki-validation/x6.txt` | Unique | ファイル名の *xN* 値と ACM 制御ドメインの *yN* 値は、ACM によって生成される一意の識別子です。例えば、 ``` http://example.com/.well-known/pki-validation/3639ac514e785e898d2646601fa951d5.txt ``` は生成された**Redirect From** URL の代表例です。関連する **Redirect To** URL は ``` https://validation.region.acm-validations.aws/98d2646601fa/.well-known/pki-validation/3639ac514e785e898d2646601fa951d5.txt ``` 同じ検証レコードである可能性があります。 **注記** ウェブサーバーまたはコンテンツ配信ネットワークが指定されたパスでのリダイレクトの設定をサポートしていない場合は、[HTTP 検証問題のトラブルシューティング](troubleshooting-HTTP-validation.md) を参照してください。 証明書をリクエストし、HTTP 検証を指定すると、ACM は次の形式でリダイレクト情報を提供します。 **** | ドメイン名 | Redirect From | Redirect To | | --- | --- | --- | | example.com | http://example.com/.well-known/pki-validation/a79865eb4cd1a6ab990a45779b4e0b96.txt | https://validation.region.acm-validations.aws/a424c7224e9b/.well-known/pki-validation/a79865eb4cd1a6ab990a45779b4e0b96.txt | ドメイン名は、証明書に関連付けられた FQDN です。*Redirect From* は、ACM が検証ファイルを検索するドメイン上の URL です。*Redirect To* は、実際の検証ファイルがホストされている ACM 制御の URL です。 *Redirect From* URL から *Redirect To* URL にリクエストをリダイレクトするようにウェブサーバーまたは CloudFront ディストリビューションを設定する必要があります。このリダイレクトをセットアップする正確な方法は、ウェブサーバーソフトウェアまたは CloudFront 設定によって異なります。ACM がドメインの所有権を検証し、証明書を発行または更新できるように、リダイレクトが正しく設定されていることを確認します。 ## HTTP 検証の設定 ACM は、CloudFront で使用するパブリック SSL/TLS 証明書を発行するときに、HTTP 検証を使用してドメインの所有権を検証します。このセクションでは、HTTP 検証を使用するためにパブリック証明書を設定する方法について説明します。 **コンソールで HTTP 検証を設定するには** **注記** この手順では、CloudFront を通じて証明書をリクエスト済みであり、それを作成した AWS リージョンで作業していることを前提としています。HTTP 検証は、CloudFront Distribution Tenants 機能を通じてのみ使用できます。 1. ACM コンソール ([https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/)) を開きます。 1. 証明書のリストで、証明書の設定を行う [**Pending validation**] (検証保留中) ステータスが付いた証明書の [**Certificate ID**] (証明書 ID) を選択します。このように、証明書の詳細ページを開きます。 1. **ドメイン**セクションには、証明書リクエストの各ドメインの**Redirect From**と**Redirect To**の値が表示されます。 1. ドメインごとに、**Redirect From** URL から**Redirect To** URL への HTTP リダイレクトを設定します。これを行うには、CloudFront ディストリビューション設定を使用します。 1. **Redirect From** URL から **Redirect To** URL にリクエストをリダイレクトするように CloudFront ディストリビューションを設定します。このリダイレクトを設定する方法は、CloudFront 設定によって異なります。 1. リダイレクトを設定すると、ACM は自動的にドメインの所有権の検証を試みます。このプロセスには最長 30 分かかることがあります。 ACM がリダイレクト値を生成してから 72 時間以内にドメイン名を検証できない場合、ACM では証明書のステータスが [**Validation timed out**] に変更されます。この結果の最も可能性の高い理由は、HTTP リダイレクトが正常に設定されなかったことです。この問題を解決するには、リダイレクトの手順を確認した後、新しい証明書をリクエストする必要があります。 **重要** 検証の問題を回避するには、**Redirect From **のロケーションのコンテンツが **Redirect To **のロケーションのコンテンツと一致することを確認してください。問題が発生した場合は、[HTTP 検証に関する問題のトラブルシューティング](troubleshooting-HTTP-validation.md) を参照してください。 **注記** DNS 検証とは異なり、ACM が HTTP リダイレクトを自動的に作成するようにプログラムでリクエストすることはできません。これらのリダイレクトは、CloudFront ディストリビューション設定を通じて設定する必要があります。 HTTP 検証の仕組みの詳細については、[ACM の HTTP リダイレクトの仕組み](#http-redirects-overview) を参照してください。