プライベート証明書のリクエスト

以下のセクションでは、ACM コンソールまたは ACM CLI コマンドを使用し、以前に ACM Private CA を使用して作成した Private Certificate Authority (CA) によって署名されたプライベート PKI 証明書をリクエストする方法について説明します。CA は、お客様のアカウントに存在するか、別のアカウントによってお客様と共有される場合があります。プライベート CA 作成の詳細については、Private Certificate Authority の作成を参照してください。

パブリック ACM 証明書とプライベート ACM 証明書はいずれも X.509 標準に準拠しており、次の制約事項が適用されます。

• DNS サブジェクト名を使用する必要があります。詳細については、「ドメイン名」を参照してください。

• 2048 ビットの RSA プライベートキーアルゴリズムのみを使用できます。

• 署名アルゴリズムは SHA256WithRSAEncryption のみサポートされます。

• 各証明書は 13 か月間 (395 日間) 有効です。

• ACM は可能な場合、11 か月後に証明書を自動的に更新します。

プライベート CA によって署名された証明書には、ドメインの検証手順はありません。

注記

プライベート CA の CA 証明書の終了日は、リクエストした証明書の終了日より後になっている必要があります。以前になっていると、証明書リクエストは失敗します。

プライベート CA にはアクティブなステータスがあることが必要で、CA プライベートキーのタイプは RSA 2048 または RSA 4096 である必要があります。

注記

プライベート CA によって署名された証明書はデフォルトでは信頼されないため、管理者はそれらをクライアントの信頼ストアにインストールする必要があります。

プライベート CA へのアクセスの設定

次の 2 つのケースのいずれかで、ACM Private CA を使用して ACM 証明書に署名できます。

• 単一アカウント: 同じ AWS アカウントにある署名 CA と発行された ACM 証明書。

  単一アカウントの発行と更新を有効にするには、ACM Private CA 管理者が ACM サービスプリンシパルに証明書を作成、取得、および一覧表示するためのアクセス許可を付与する必要があります。これは、ACM Private CA API アクション CreatePermission または AWS CLI コマンド作成許可を使用して行われます。アカウント所有者は、証明書の発行を担当する IAM ユーザーまたはグループに、これらのアクセス許可を割り当てます。

• クロスアカウント: 異なるAWSアカウントにある署名 CA と発行された ACM 証明書、また CA へのアクセスが、証明書があるアカウントに付与されています。

  クロスアカウント発行および更新を有効にするには、ACM Private CA 管理者は、ACM Private CA API アクション PutPolicy またはAWS CLIコマンドプットポリシーを使用して、リソースベースのポリシーを CA にアタッチする必要があります。このポリシーは、CA への制限付きアクセスを許可する他のアカウントのプリンシパルを指定します。詳細については、「ACM Private CA でのリソースベースのポリシーの使用」を参照してください。

  クロスアカウントシナリオでは、ACM がプリンシパルとして PCA ポリシーとやり取りするサービスリンクロール (SLR) をセットアップする必要もあります。ACM は、最初の証明書の発行時に SLR を自動的に作成します。

  ACM では、アカウントに SLR が存在するかどうかを判断できないという警告が表示されることがあります。必要な iam:GetRole アクセス許可がすでにアカウントの ACM SLR に付与されている場合、SLR の作成後にアラートは再発しません。再発する場合は、ユーザーまたはアカウント管理者が iam:GetRole アクセス許可を ACM に付与するか、アカウントを ACM 管理ポリシー AWSCertificateManagerFullAccess に関連付けます。

  詳細については、「ACM でのサービスにリンクされたロールの使用」を参照してください。

重要

ACM 証明書は、自動更新する前に、サポートされている AWS のサービスに有効に関連付けられている必要があります。ACM がサポートするリソースについては、「AWS Certificate Manager と統合されたサービス」を参照してください。

ACM コンソールを使用したプライベート証明書のリクエスト

1. AWS マネジメントコンソールにサインインして ACM コンソール (https://console.aws.amazon.com/acm/home) を開きます。

   [証明書のリクエスト] を選択します。

2. [証明書のリクエスト] ページで、[プライベート証明書のリクエスト] と [証明書のリクエスト] を選択して続行します。

3. [Select a certificate authority (CA)] ページで、[Select a CA] フィールドをクリックして、ARN によって特定された使用可能なプライベート CA のリストを表示します。CA が別のアカウントから共有されている場合、ARN には所有権情報が付加されます。リストから CA を選択します。

   CA に関する詳細が表示され、正しい CA を選択したことを確認するのに役立ちます。

   • 所有者

   • タイプ

   • サブジェクト識別名

   • 価値組織 (O)

   • 組織単位 (OU)

   • 国名 (C)

   • 州または県

   • 市区町村

   • 共通名 (CN)

   注記

   ACM コンソールに、ECDSA キーのあるプライベート CA について、[使用不可] が表示されます。

   [Next] を選択します。

4. [Add domain names] ページで、ドメイン名を入力します。www.example.com のような完全修飾ドメイン名 (FQDN) や example.com のようなネイキッドドメインあるいは apex ドメイン名を使用できます。また、同じドメインで複数のサイト名を保護するために、最左位置にアスタリスク (*) をワイルドカードとして使用できます。たとえば、*.example.com は、corp.example.com と images.example.com を保護します。ワイルドカード名は、ACM 証明書の [件名] フィールドと [サブジェクト代替名] 拡張子に表示されます。

   注記

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

   注記

   プライベート証明書のドメインを検証する必要はありません。

5. 別の名前を追加するには、[この証明書に別の名前を追加] を選択し、テキストボックスに名前を入力します。これは、ネイキッドドメインまたは apex ドメイン (example.com など) の両方とそのサブドメイン (*.example.com など) の認証のために役立ちます。

   名前の追加が終了したら、[次へ] を選択します。

6. [タグの追加] ページでは、オプションで証明書にタグを付けることができます。タグとは、AWS リソースを識別および整理するためのメタデータとして機能するキーと値のペアです。AACM タグパラメータのリスト、および証明書作成後にタグを追加する方法については、「AWSCertificate Manager 証明書のタグ付け」を参照してください。

   タグの追加が完了したら、[Review and request] を選択します。

7. [レビューとリクエスト] ページに、リクエストに関する情報が表示されます。

   別のアカウントから共有された CA を初めて使用すると、ACM はアカウントに対してサービスにリンクされたロール (SLR) が作成されることを警告します。この役割により、CA で署名した証明書の自動更新が可能になります。詳細については、「ACM でのサービスにリンクされたロールの使用」を参照してください。

   情報が正しい場合は、[確認とリクエスト]を選択します。ACM は、プライベートとパブリック両方の ACM 証明書に関する情報を確認できる証明書ページを返します。

   注記

   ACM では、この時点で 2 つの通知のうちの 1 つが表示されることがあります。

   • この ACM は、アカウントに SLR が存在するかどうかを判断できません。これは、不正なアクセス許可の設定が原因である可能性があります。証明書のリクエストは続行できますが、自動更新を有効にするには、証明書の有効期限が切れる前に、ユーザーまたは管理者が必要なアクセス許可を指定する必要があります。詳細については、「ACM でのサービスにリンクされたロールの使用」を参照してください。

   • そのACMは、ユーザーのアカウントに SLR が存在しないと判断し、1 つがユーザーのために作成されます。

CLI を使用したプライベート証明書のリクエスト

ACM で request-certificate コマンドを使用してプライベート証明書をリクエストします。

aws acm request-certificate \
--domain-name www.example.com \
--idempotency-token 12563 \
--options CertificateTransparencyLoggingPreference=DISABLED \
--certificate-authority-arn arn:aws:acm-pca:region:account:\
certificate-authority/12345678-1`234-1234-1234-123456789012

このコマンドは、新しいプライベート証明書の Amazon リソースネーム (ARN) を出力します。

{
    "CertificateArn": "arn:aws:acm:region:account:certificate/12345678-1234-1234-1234-123456789012"
}	

ほとんどの場合、ACM は、共有 CA を初めて使用するときに、サービスにリンクされたロール (SLR) をアカウントに自動的にアタッチします。SLR によって、発行するエンドエンティティ証明書の自動更新が可能になります。SLR が存在するかどうかを確認するには、以下のコマンドを使用して IAM にクエリを実行することができます。

aws iam get-role --role-name AWSServiceRoleForCertificateManager

SLR が存在する場合、コマンドの出力は次のようになります。

{
   "Role":{
      "Path":"/aws-service-role/acm.amazonaws.com/",
      "RoleName":"AWSServiceRoleForCertificateManager",
      "RoleId":"AAAAAAA0000000BBBBBBB",
      "Arn":"arn:aws:iam::{account_no}:role/aws-service-role/acm.amazonaws.com/AWSServiceRoleForCertificateManager",
      "CreateDate":"2020-08-01T23:10:41Z",
      "AssumeRolePolicyDocument":{
         "Version":"2012-10-17",
         "Statement":[
            {
               "Effect":"Allow",
               "Principal":{
                  "Service":"acm.amazonaws.com"
               },
               "Action":"sts:AssumeRole"
            }
         ]
      },
      "Description":"SLR for ACM Service for accessing cross-account Private CA",
      "MaxSessionDuration":3600,
      "RoleLastUsed":{
         "LastUsedDate":"2020-08-01T23:11:04Z",
         "Region":"ap-southeast-1"
      }
   }
}

SLR がない場合は、「ACM でのサービスにリンクされたロールの使用」を参照してください。