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

によって作成された既存のプライベート CA にアクセスできる場合 AWS Private CA、ACM はプライベート PKI での使用に適した証明書をリクエストできます。CA は、お客様のアカウントに存在するか、別のアカウントによってお客様と共有される場合があります。プライベート CA 作成の詳細については、Private Certificate Authority の作成を参照してください。

デフォルトでは、プライベート CA によって署名された証明書は信頼されないため、ACM はそれらに対する検証を一切サポートしていません。そのため、管理者は、組織のクライアントトラストストアにインストールするためのアクションを実行する必要があります。

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

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

• アルゴリズム: 暗号化の場合、証明書のプライベートキーのアルゴリズムは 2048 ビット RSA、256 ビット ECDSA、または 384 ビット ECDSA のいずれかである必要があります。

  注記

  指定された署名アルゴリズムファミリー (RSA または ECDSA) は、CA のシークレットキーのアルゴリズムファミリーと一致する必要があります。

• 有効期限: 各証明書は 13 か月間 (395 日間) 有効です。署名した CA 証明書の終了日は、リクエストした証明書の終了日より後になっている必要があります。以前になっていると、証明書リクエストは失敗します。

• 更新: ACM は 11 か月後にプライベート証明書を自動的に更新しようとします。

エンドエンティティ証明書の署名に使用されるプライベート CA には、次に示す独自の制限が適用されます。

• CA はステータスがアクティブである必要があります。

• CA プライベートキーアルゴリズムは RSA 2048 または RSA 4096 である必要があります。

注記

パブリックに信頼された証明書とは異なり、プライベート CA によって署名された証明書は、検証の必要がありません。

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

AWS Private CA を使用して ACM 証明書に署名できるのは、次の 2 つの場合のいずれかです。

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

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

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

  クロスアカウントの発行と更新を有効にするには、 AWS Private CA 管理者が API アクションまたは put-policy コマンドを使用してリソースベースのポリシーを CA にアタッチする必要があります。 AWS Private CAPutPolicyAWS CLIこのポリシーは、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 コンソールを使用してプライベート PKI 証明書をリクエストする

1. AWS 管理コンソールにサインインし、https://console.aws.amazon.com/acm/home にある ACM コンソールを開きます。

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

2. [Request certificate] (証明書のリクエスト) ページで、[Request a private certificate] (プライベート証明書のリクエスト) と [Next] (次へ) を選択して続行します。

3. [Certificate authority details] (認証権限の詳細) セクションで、[Certificate authority] (認証権限) メニューをクリックし、使用可能なプライベート CA の 1 つを選択します。CA が別のアカウントから共有されている場合、ARN には所有権情報が付加されます。

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

   • 所有者

   • タイプ

   • 共通名 (CN)

   • 組織 (O)

   • 組織単位 (OU)

   • 国名 (C)

   • 州または県

   • 市区町村

4. [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) は保護しないことに注意してください。両方を保護するには、次のステップを参照してください。

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

5. [Key algorithm] (キーアルゴリズム) セクションで、使用可能な 3 つのアルゴリズムのいずれかを選択します。

   • RSA 2048 (デフォルト)

   • ECDSA P 256

   • ECDSA P 384

   アルゴリズムの選択に役立つ情報については、キーアルゴリズム を参照してください。

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

7. [Certificate renewal permissions] (証明書の更新許可) セクションで、証明書の更新許可に関する通知を確認します。これらの許可により、選択した CA で署名するプライベート PKI 証明書を自動的に更新できます。詳細については、「ACM でのサービスにリンクされたロールの使用」を参照してください。

8. 必要な情報をすべて提供して、[Request] (リクエスト) を選択します。コンソールによって証明書リストに戻り、新しい証明書を表示できます。

   注記

   リストの配列方法によっては、探している証明書がすぐには表示されない場合があります。右側の黒い三角形をクリックすると、配列を変更できます。また、右上のページ番号を使用して、証明書の複数のページを検索することもできます。

CLI を使用してプライベート PKI 証明書をリクエストする

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

注記

CA が署名したプライベート PKI 証明書をからリクエストする場合 AWS Private CA、指定された署名アルゴリズムファミリ (RSA または ECDSA) は CA の秘密鍵のアルゴリズムファミリーと一致する必要があります。

aws acm request-certificate \
--domain-name www.example.com \
--idempotency-token 12563 \
--certificate-authority-arn arn:aws:acm-pca:Region:444455556666:\
certificate-authority/CA_ID

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

{
    "CertificateArn": "arn:aws:acm:Region:444455556666:certificate/certificate_ID"
}	

ほとんどの場合、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 でのサービスにリンクされたロールの使用」を参照してください。