ACM 証明書の特徴 - AWS Certificate Manager

ACM 証明書の特徴

ACM が提供するパブリック証明書には、このページ で説明する特徴があります。

注記

これらの特徴は ACM が提供する証明書にのみ適用されます。ACM にインポートする証明書 には適用されない場合があります。

認証機関と階層

ACM を通じてリクエストしたパブリック証明書は、Amazon が管理するパブリック認証機関 (CA) である Amazon Trust Services から取得されます。Amazon ルート CA 1 ~ 4 は、Starfield G2 Root Certificate Authority - G2 という名前の古いルートによってクロス署名されています。Starfield ルートは、それ以降のバージョンの Gingerbread 以降の Androidデバイス、および バージョン4.1 以降の iOS で信頼されています。Amazon ルートは、バージョン 11 以降の iOS によって信頼されています。Amazon または Starfield ルートを含むブラウザ、アプリケーション、OS は、ACM から取得したパブリック証明書を信頼します。

ACM がお客様に発行するリーフ証明書またはエンドエンティティ証明書は、複数の中間 CA を介して Amazon Trust Services のルート CA からの認証を受けます。ACM は、要求された証明書のタイプ (RSA または ECDSA) に基づいて中間 CA をランダムに割り当てます。中間 CA はリクエストの生成後にランダムに選択されるため、ACM は中間 CA 情報を提供しません。

ブラウザとアプリケーションの信頼

ACM 証明書は、Google Chrome、Microsoft Internet Explorer と Microsoft Edge、そして Mozilla Firefox および Apple Safari を含むすべての主要なブラウザから信頼されています。ACM 証明書を信頼するブラウザでは、ACM 証明書を使用するサイトに SSL/TLS から接続するときにステータスバーにロックアイコンが表示されます。ACM 証明書は Java でも信頼されています。

中間 CA とルート CA のローテーション

回復力と俊敏性を備えた証明書インフラストラクチャを維持するために、Amazon は事前の通知なしに中間認証機関を廃止することがあります。この種の変更は、お客様には影響しません。詳細については、ブログ記事「Amazon introduces dynamic intermediate certificate authorities」(Amazon が動的中間認証機関を導入) を参照してください。

Amazon がルート CA を廃止した場合、状況に応じて速やかに変更が行われます。このような変更による影響は大きいため、Amazon は、利用可能なすべてのメカニズム (AWS Health Dashboard、アカウントオーナーへの E メール、技術アカウントマネージャーへの連絡など) を使用して AWS のお客様に通知します。

失効時のファイアウォールアクセス

エンドエンティティ証明書が信頼されなくなると、その証明書は失効します。OCSP と CRL は、証明書が取り消されたかどうかを検証するために使用される標準的なメカニズムです。OCSP と CRL は、失効情報の公開に使用される標準的なメカニズムです。お客様のファイアウォールによっては、これらのメカニズムを機能させるために追加のルールが必要になる場合があります。

次の例の URL ワイルドカードパターンを使用して、失効トラフィックを識別できます。アスタリスク (*) ワイルドカードは 1 つ以上の英数字、疑問符 (?) は単一の英数字を表し、ハッシュマーク (#) は数字を表します。

  • OCSP

    http://ocsp.?????.amazontrust.com

    http://ocsp.*.amazontrust.com

  • CRL

    http://crl.?????.amazontrust.com/?????.crl

    http://crl.*.amazontrust.com/*.crl

    CRL パーティションが存在する場合、追加の URL は http://crl.?????.amazontrust.com/?????p##.crl の形式になります。

ドメイン検証 (DV)

ACM 証明書は、ドメイン検証されます。つまり、ACM 証明書のサブジェクトフィールドはドメイン名のみを識別します。ACM 証明書をリクエストした場合、リクエストで指定したすべてのドメインの所有者または管理者であることを検証する必要があります。E メールまたは DNS を使用して所有権を検証できます。詳細については、E メール検証 および DNS での検証 を参照してください。

有効期間

ACM 証明書の有効期間は、現在 13 か月 (395 日) です。

マネージド更新とデプロイ

ACM は、ACM の更新プロセスと、更新後の証明書のプロビジョニングを管理します。自動更新は、証明書の設定ミス、失効、期限切れによるダウンタイムを防止するために役立ちます。詳しくは、ACM 証明書のマネージド更新 を参照してください。

複数のドメイン名

各 ACM 証明書には、少なくとも 1 つの完全修飾ドメイン名 (FQDN) が含まれる必要があり、希望する場合には追加の名前を付けくわえることができます。たとえば、www.example.com に ACM 証明書を作成する場合、www.example.net という名前を追加すると、カスタマーはどちらの名前を使用してもサイトにアクセスできます。これは、zone apex またはネイキッドドメインとも呼ばれるホスト名のないドメインにも有効です。つまり、www.example.com に ACM 証明書をリクエストし、example.com という名前を追加できます。詳しくは、パブリック証明書をリクエストする を参照してください。

ワイルドカード名

ACM は、ドメイン名にアスタリスク (*) を使うことで、同じドメイン内の複数のサイトを保護できるワイルドカード名を含む ACM 証明書を作成することができます。たとえば、*.example.com は、www.example.comimages.example.com を保護します。

注記

ワイルドカード証明書をリクエストする場合、アスタリスク (*) はドメイン名の左側に付ける必要があり、1 つのサブドメインレベルのみを保護できます。たとえば、*.example.comlogin.example.com および test.example.com を保護できますが、test.login.example.com を保護することはできません。また、*.example.com example.com のサブドメインのみを保護し、ネイキッドドメインまたは apex ドメイン (example.com) は保護しないことに注意してください。ただし、複数のドメイン名を特定してリクエストすることで、ネイキッドあるいはホスト名のないドメインとそのサブドメインを保護する証明書をリクエストできます。たとえば、example.com*.example.comを保護する証明書をリクエストできます。

キーアルゴリズム

証明書では、アルゴリズムやキーサイズを指定する必要があります。現在、ACM がサポートしているパブリックキーアルゴリズムは、以下の RSA および楕円曲線デジタル署名アルゴリズム (ECDSA) です。ACM は、アスタリスク (*) でマークされたアルゴリズムを使用して新しい証明書の発行をリクエストできます。残りのアルゴリズムは、インポートされた証明書でのみサポートされます。

  • RSA 1024 ビット (RSA_1024)

  • RSA 2048 ビット (RSA_2048)*

  • RSA 3072 ビット (RSA_3072)

  • RSA 4096 ビット (RSA_4096)

  • ECDSA 256 ビット (EC_prime256v1)*

  • ECDSA 384 ビット (EC_secp384r1)*

  • ECDSA 521 ビット (EC_secp521r1)

ECDSA キーはサイズが小さく、RSA キーに匹敵するセキュリティを提供しますが、コンピューティング効率も高くなります。ただし、ECDSA はすべてのネットワーククライアントでサポートされているわけではありません。次の表は、NIST から引用したもので、さまざまなサイズのキーを使用した RSA と ECDSA の代表的なセキュリティ強度を示しています。値はすべてビット単位です。

アルゴリズムとキーのセキュリティ比較

セキュリティ強度

RSA キーサイズ

ECDSA キーサイズ

128

3072 256

192

7680 384

256

15360 512

セキュリティ強度は 2 の累乗として理解され、暗号化を解除するために必要な推測回数に関係します。例えば、3072 ビットの RSA キーと 256 ビットの ECDSA キーはどちらも、2128 回以下の推測で取得できます。

アルゴリズムの選択に役立つ情報については、AWS ブログ記事「AWS Certificate Manager で ECDSA 証明書を評価して使用する方法」を参照してください。

重要

統合サービスでは、リソースへの関連付けがサポートされているアルゴリズムとキーサイズのみが許可されることに注意してください。さらに、そのサポートは、証明書のインポート先が IAM であるか、または ACM であるかによって異なります。詳細については、各サービスのドキュメントを参照してください。

Punycode

国際化ドメイン名に関連する次の Punycode 要件を満たす必要があります:

  1. パターン「<character><character>—」で始まるドメイン名は「xn—」と一致する必要があります。

  2. 「xn—」で始まるドメイン名も有効な国際化ドメイン名である必要があります。

Punycode の例

ドメイン名

フルフィル #1

フルフィル #2

許可

注意

example.com

該当なし

該当なし

「<character><character>—」で始まらない

a--example.com

該当なし

該当なし

「<character><character>—」で始まらない

abc--example.com

該当なし

該当なし

「<character><character>—」で始まらない

xn--xyz.com

はい

はい

有効な国際化ドメイン名 (简.com に解決)

xn--example.com

はい

いいえ

有効な国際化ドメイン名ではありません

ab--example.com

いいえ

いいえ

「xn--」で始まる必要があります。

例外

次の点に注意してください。

  • ACM は、拡張検証 (EV) 証明書または組織検証 (OV) 証明書を提供していません。

  • ACM は、SSL/TLS プロトコル以外の証明書を提供していません。

  • E メールの暗号化に ACM 証明書を使用することはできません。

  • ACM は現在、ACM 証明書のマネージド証明書更新のオプトアウトを許可していません。また、マネージド更新は ACM にインポートした証明書には使用できません。

  • 末尾が amazonaws.com、cloudfront.net、または elasticbeanstalk.com などの Amazon が所有するドメイン名に証明書をリクエストすることはできません。

  • ACM 証明書のプライベートキーをダウンロードすることはできません。

  • Amazon Elastic Compute Cloud (Amazon EC2) のウェブサイトまたはアプリケーションに ACM Certificate を直接インストールすることはできません。ただし、どの統合されたサービスでも証明書を使用できます。詳しくは、AWS Certificate Manager と統合されたサービス を参照してください。