翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
プライベート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 証明書の終了日は、リクエストした証明書の終了日より後になっている必要があります。以前になっていると、証明書リクエストは失敗します。
-
更新: は 11 か月後にプライベート証明書を自動的に更新ACMしようとします。
エンドエンティティ証明書の署名に使用されるプライベート CA には、次に示す独自の制限が適用されます。
-
CA はステータスがアクティブである必要があります。
-
CA プライベートキーアルゴリズムは 2048 RSA または 4096 RSA である必要があります。
注記
パブリックに信頼された証明書とは異なり、プライベート CA によって署名された証明書は、検証の必要がありません。
プライベート CA へのアクセスの設定
を使用して AWS Private CA 、次の 2 つのケースのいずれかでACM証明書に署名できます。
-
単一アカウント: 署名 CA と発行されたACM証明書は、同じ AWS アカウントにあります。
単一アカウントの発行と更新を有効にするには、 AWS Private CA 管理者はACMサービスプリンシパルに証明書を作成、取得、および一覧表示するアクセス許可を付与する必要があります。これは、 APIアクションCreatePermissionまたは AWS CLI コマンド create-permission を使用して AWS Private CA 行われます。アカウント所有者は、証明書の発行を担当するIAMユーザー、グループ、またはロールにこれらのアクセス許可を割り当てます。
-
クロスアカウント : 署名 CA と発行されたACM証明書は異なる AWS アカウントに存在し、CA へのアクセスは証明書が存在するアカウントに付与されています。
クロスアカウント発行および更新を有効にするには、 AWS Private CA 管理者は AWS Private CA APIアクションPutPolicyまたは AWS CLI コマンド put-policy を使用してリソースベースのポリシーを CA にアタッチする必要があります。このポリシーは、CA への制限付きアクセスを許可する他のアカウントのプリンシパルを指定します。詳細については、ACM「プライベート CA でのリソースベースのポリシーの使用」を参照してください。
クロスアカウントシナリオではACM、プリンシパルとしてPCAポリシーとやり取りするためのサービスにリンクされたロール (SLR) も設定する必要があります。ACM は、最初の証明書の発行時に SLRを自動的に作成します。
ACM は、 がアカウントSLRに存在するかどうかを判断できないことを警告することがあります。ACM SLR アカウントに必要な
iam:GetRole
アクセス許可が既に に付与されている場合、 の作成後にアラートSLRは再発しません。繰り返し発生する場合は、ユーザーまたはアカウント管理者が にアクセスiam:GetRole
許可を付与するかACM、アカウントを ACM管理ポリシー に関連付ける必要がありますAWSCertificateManagerFullAccess
。詳細については、「 でサービスにリンクされたロールを使用するACM」を参照してください。
重要
ACM 証明書を自動的に更新する前に、サポートされている AWS サービスに証明書をアクティブに関連付ける必要があります。がACMサポートするリソースの詳細については、「」を参照してくださいと統合されたサービス AWS Certificate Manager。
ACM コンソールを使用してプライベートPKI証明書をリクエストする
-
AWS マネジメントコンソールにサインインし、https://console.aws.amazon.com/acm/ホーム
でACMコンソールを開きます。 [証明書のリクエスト] を選択します。
-
[Request certificate] (証明書のリクエスト) ページで、[Request a private certificate] (プライベート証明書のリクエスト) と [Next] (次へ) を選択して続行します。
-
認証局の詳細セクションで、認証局メニューをクリックし、使用可能なプライベート のいずれかを選択しますCAs。CA が別のアカウントから共有されている場合、 ARN の先頭には所有権情報が表示されます。
CA に関する詳細が表示され、正しい CA を選択したことについての確認に役立ちます。
-
[所有者]
-
タイプ
-
共通名 (CN)
-
組織 (O)
-
組織単位 (OU)
-
国名 (C)
-
州または県
-
市区町村
-
-
[Domain names] (ドメイン名) セクションで、ドメイン名を入力します。などの完全修飾ドメイン名 (FQDN)
www.example.com
、または などのベアドメイン名または apex ドメイン名を使用できますexample.com
。また、同じドメインで複数のサイト名を保護するために、最左位置にアスタリスク (*
) をワイルドカードとして使用できます。たとえば、*.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 タグパラメータのリストと、作成後に証明書にタグを追加する方法については、「」を参照してください証明書への AWS Certificate Manager タグ付け。
-
[Certificate renewal permissions] (証明書の更新許可) セクションで、証明書の更新許可に関する通知を確認します。これらのアクセス許可により、選択した CA で署名したプライベートPKI証明書の自動更新が可能になります。詳細については、「 でサービスにリンクされたロールを使用するACM」を参照してください。
-
必要な情報をすべて提供して、[Request] (リクエスト) を選択します。コンソールによって証明書リストに戻り、新しい証明書を表示できます。
注記
リストの配列方法によっては、探している証明書がすぐには表示されない場合があります。右側の黒い三角形をクリックすると、配列を変更できます。また、右上のページ番号を使用して、証明書の複数のページを検索することもできます。
を使用してプライベートPKI証明書をリクエストする CLI
request-certificate コマンドを使用して、 でプライベート証明書をリクエストしますACM。
注記
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
"
}
ほとんどの場合、共有 CA を初めて使用すると、 はサービスにリンクされたロール (SLR) をアカウントACMに自動的にアタッチします。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」を参照してください。