プライベート PKI 証明書のリクエスト
AWS Private CA が作成した既存のプライベート CA にアクセスできる場合、ACM はプライベート PKI での使用に適した証明書をリクエストできます。CA は、お客様のアカウントに存在するか、別のアカウントによってお客様と共有される場合があります。プライベート CA 作成の詳細については、Private Certificate Authority の作成を参照してください。
デフォルトでは、プライベート CA によって署名された証明書は信頼されないため、ACM はそれらに対する検証を一切サポートしていません。そのため、管理者は、組織のクライアントトラストストアにインストールするためのアクションを実行する必要があります。
プライベート ACM 証明書は X.509 標準に準拠しており、次の制約事項が適用されます。
-
名前: DNS に準拠するサブジェクト名を使用する必要があります。詳細については、「ドメイン名」を参照してください。
-
アルゴリズム: 暗号化の場合、証明書のプライベートキーのアルゴリズムは 2048 ビット RSA、256 ビット ECDSA、または 384 ビット ECDSA のいずれかである必要があります。
-
有効期限: 各証明書は 13 か月間 (395 日間) 有効です。署名した CA 証明書の終了日は、リクエストした証明書の終了日より後になっている必要があります。以前になっていると、証明書リクエストは失敗します。
-
更新: ACM は 11 か月後にプライベート証明書を自動的に更新しようとします。
エンドエンティティ証明書の署名に使用されるプライベート CA には、次に示す独自の制限が適用されます。
-
CA はステータスがアクティブである必要があります。
-
CA プライベートキーアルゴリズムは RSA 2048 または RSA 4096 である必要があります。
パブリックに信頼された証明書とは異なり、プライベート CA によって署名された証明書は、検証の必要がありません。
プライベート CA へのアクセスの設定
次の 2 つのケースのいずれかで、AWS Private CA を使用して ACM 証明書に署名できます。
-
単一アカウント: 同じ AWS アカウントにある署名 CA と発行された ACM 証明書。
単一アカウントの発行と更新を有効にするには、AWS Private CA 管理者が ACM サービスプリンシパルに証明書を作成、取得、および一覧表示するためのアクセス許可を付与する必要があります。これは、AWS Private CA API アクション
CreatePermission
または AWS CLI コマンド create-permission を使用して行います。アカウント所有者は、証明書の発行を担当する IAM ユーザーまたはグループに、これらのアクセス許可を割り当てます。 -
クロスアカウント: 異なるAWSアカウントにある署名 CA と発行された ACM 証明書、また CA へのアクセスが、証明書があるアカウントに付与されています。
クロスアカウント発行および更新を有効にするには、AWS Private CA 管理者は、AWS Private CA API アクション
PutPolicy
または AWS CLI コマンド put-policy を使用して、リソースベースのポリシーを 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 コンソールを使用してプライベート PKI 証明書をリクエストする
-
AWS マネジメントコンソールにサインインして ACM コンソール (https://console.aws.amazon.com/acm/home
) を開きます。 [証明書のリクエスト] を選択します。
-
[Request certificate] (証明書のリクエスト) ページで、[Request a private certificate] (プライベート証明書のリクエスト) と [Next] (次へ) を選択して続行します。
-
[Certificate authority details] (認証権限の詳細) セクションで、[Certificate authority] (認証権限) メニューをクリックし、使用可能なプライベート CA の 1 つを選択します。CA が別のアカウントから共有されている場合、ARN には所有権情報が付加されます。
CA に関する詳細が表示され、正しい CA を選択したことについての確認に役立ちます。
-
所有者
-
[Type] (タイプ)
-
共通名 (CN)
-
組織 (O)
-
組織単位 (OU)
-
国名 (C)
-
州または県
-
市区町村
-
-
[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
など) の認証のために役立ちます。 -
[Key algorithm] (キーアルゴリズム) セクションで、使用可能な 3 つのアルゴリズムのいずれかを選択します。
-
RSA 2048 (デフォルト)
-
ECDSA P 256
-
ECDSA P 384
アルゴリズムの選択に役立つ情報については、キーアルゴリズム を参照してください。
-
-
[Tags] (タグ) セクションで、オプションで証明書にタグを付けることができます。タグとは、AWS リソースを識別および整理するためのメタデータとして機能するキーと値のペアのことを指します。ACM タグパラメータのリスト、および証明書作成後にタグを追加する方法については、「AWSCertificate Manager 証明書のタグ付け」を参照してください。
-
[Certificate renewal permissions] (証明書の更新許可) セクションで、証明書の更新許可に関する通知を確認します。これらの許可により、選択した CA で署名するプライベート PKI 証明書を自動的に更新できます。詳細については、「ACM でのサービスにリンクされたロールの使用」を参照してください。
-
必要な情報をすべて提供して、[Request] (リクエスト) を選択します。コンソールによって証明書リストに戻り、新しい証明書を表示できます。
注記 リストの配列方法によっては、探している証明書がすぐには表示されない場合があります。右側の黒い三角形をクリックすると、配列を変更できます。また、右上のページ番号を使用して、証明書の複数のページを検索することもできます。
CLI を使用してプライベート PKI 証明書をリクエストする
ACM で request-certificate コマンドを使用してプライベート証明書をリクエストします。
aws acm request-certificate \ --domain-name www.example.com \ --idempotency-token 12563 \ --certificate-authority-arn arn:aws:acm-pca:
region
:account
:\ certificate-authority/CA_ID
このコマンドは、新しいプライベート証明書の Amazon リソースネーム (ARN) を出力します。
{
"CertificateArn": "arn:aws:acm:region
:account
: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 でのサービスにリンクされたロールの使用」を参照してください。