「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」
プライベート証明書のリクエスト
以下のセクションでは、ACM コンソールまたは ACM CLI コマンドを使用して、以前に ACM Private CA を使用して作成されたプライベート認証機関 (CA) によって署名されたプライベート証明書をリクエストする方法について説明します。CA は、アカウント内に存在することも、別のアカウントと共有することもできます。プライベート CA 作成の詳細については、プライベート認証機関 (CA) の作成.を参照してください。
パブリック証明書とプライベート ACM 証明書はどちらも X.509 標準に準拠していますが、パブリック使用向けの証明書には、次の制限が適用されます。
-
DNS サブジェクト名を使用する必要があります。詳細については、「」を参照してください。ドメイン名
-
2048 ビットの RSA プライベートキーのみを使用できます。
-
サポートされる署名アルゴリズムは、SHA256WithRSAEncryption のみです。
-
各証明書は 13 か月 (395 日) に対して有効であり、ACM は、可能な場合は 11 か月後に証明書を自動的に更新します。
プライベート CA によって署名された証明書には、これらの制限はありません。代わりに、以下の操作を行うことができます。
この柔軟性は、特定の名前でサブジェクトを識別する必要がある場合や、証明書を簡単にローテーションできない場合に有益です。
プライベート CA の CA 証明書の終了日は、リクエストした証明書の終了日より後になっている必要があります。以前になっていると、証明書リクエストは失敗します。
プライベート CA のステータスは Active である必要があり、CA プライベートキーのタイプは RSA 2048 または RSA 4096 である必要があります。
プライベート CA によって署名された証明書はデフォルトでは信頼されないため、管理者はそれらの証明書をクライアントの信頼ストアにインストールする必要があります。
プライベート CA へのアクセスの設定
を使用して、次の 2 つのいずれかのケースで ACM Private CA 証明書に署名することができます。ACM
-
単一アカウント: 発行される署名 CA と ACM 証明書が同じ AWS アカウント内に存在する。
単一アカウント発行および更新を有効にするには、ACM Private CA 管理者は ACM サービスプリンシパルに、証明書を作成、取得、および一覧表示するためのアクセス許可を付与する必要があります。そのためには、ACM Private CA API アクション
CreatePermission
または AWS CLI コマンド create-permission を使用します。アカウントの所有者は、証明書の発行を担当する IAM ユーザーまたはグループに、これらのアクセス許可を割り当てます。 -
クロスアカウント: 発行される署名 CA と ACM 証明書は異なる AWS アカウントに存在し、証明書が存在するアカウントに CA へのアクセスが許可されています。
クロスアカウント発行および更新を有効にするには、ACM Private CA 管理者は ACM Private CA API アクション
PutPolicy
または コマンド AWS CLIput-policy を使用して、リソースベースのポリシーを CA にアタッチする必要があります。このポリシーは、CA への制限付きアクセスが許可されている他のアカウントのプリンシパルをホワイトリストに登録します。詳細については、「ACM プライベート CA でのリソースベースのポリシーの使用」を参照してください。クロスアカウントのシナリオでは、ACM がサービスにリンクされたロール (SLR) をセットアップして、PCA ポリシーでプリンシパルとして操作する必要もあります。SLR の作成は、最初の証明書の発行中に自動的に実行されます。
ACM は、SLR がアカウントに存在するかどうかを判断できない場合にアラートを送信することがあります。必要な
iam:GetRole
アクセス許可がアカウントの ACM SLR にすでに付与されている場合、SLR の作成後にアラートは繰り返し発生しません。繰り返し発生した場合は、ユーザーまたはアカウント管理者が ACM にiam:GetRole
アクセス許可を付与するか、アカウントを ACM 管理ポリシーAWSCertificateManagerFullAccess
に関連付ける必要があります。詳細については、「ACM でのサービスにリンクされたロールの使用」を参照してください。
ACM 証明書は、自動更新する前に、サポートされている AWS のサービスに有効に関連付けられている必要があります。ACM がサポートするリソースについては、「サービスと の統合AWS Certificate Manager」を参照してください。
コンソールを使用したプライベート証明書のリクエストACM
-
AWS マネジメントコンソールにサインインし、ACM コンソールを https://console.aws.amazon.com/acm/home
. で開きます。 証明書のリクエスト.] を選択します。
-
[証明書のリクエスト] ページで、[プライベート証明書のリクエスト] を選択し、[証明書のリクエスト] を選択して続行します。
-
[認証機関 (CA) の選択] ページで、[CA の選択] フィールドをクリックして、ARN によって識別される使用可能なプライベート CAs のリストを表示します。CA が別のアカウントから共有される場合、ARN は所有権情報の前に付けられます。リストから CA を選択します。
CA に関する詳細が表示され、正しい CA を選択したことを確認するのに役立ちます。
-
所有者
-
タイプ
-
件名の識別名
-
値の組織 (O)
-
組織単位 (OU)
-
国名 (C)
-
州または県
-
市区町村
-
共通名 (CN)
注記 コンソールに、ECDSA キーのあるプライベート ACMCA のための使用不可CAs
次へ.] を選択します。
-
-
[Add domain names] ページで、ドメイン名を入力します。のような完全修飾ドメイン名 (FQDN) や
www.example.com
のようなネイキッドドメインあるいは apex ドメイン名を使用できます。example.com
また、同じドメインで複数のサイト名を保護するために、最左位置にアスタリスク (*
) をワイルドカードとして使用できます。たとえば、*.example.com
は、corp.example.com
およびimages.example.com
を保護します。 ワイルドカード名は、 証明書の [Subject] フィールドと [Subject Alternative NameACM] 拡張子に表示されます。注記 ワイルドカード証明書をリクエストする場合、アスタリスク (
*
) はドメイン名の左側に付ける必要があり、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
など) を認証する場合に便利です。名前の追加が終了したら、[次へ.] を選択します。
-
[タグの追加] ページでは、オプションで証明書にタグを付けることができます。タグとは、AWS リソースを識別および整理するためのメタデータとして機能するキーと値のペアです。ACM タグパラメータのリスト、および証明書作成後にタグを追加する方法については、「AWS Certificate Manager 証明書へのタグ付け.」を参照してください。
タグの追加が完了したら、[Review and request.] を選択します。
-
[Review and request] ページにリクエストに関する情報が表示されます。
別のアカウントから共有されている CA を初めて使用する際、サービスにリンクされたロール (SLR) がアカウントに作成されることが ACM によりアラートで通知されます。このロールにより、CA で署名した証明書の自動更新が可能になります。詳細については、「 でのサービスにリンクされたロールの使用ACM」を参照してください。
情報が正しい場合は、[Confirm and request (確認してリクエスト)] を選択します。ACM より、[Certificates (証明書)] ページが返り、プライベートとパブリックの両方のすべての ACM 証明書に関する情報を確認できます。
注記 ACM には、この時点で 2 つの通知のいずれかが表示される場合があります。
-
その ACM は、SLR がアカウントに存在するかどうかを判断できません。これは、誤ったアクセス許可設定が原因で発生する可能性があります。証明書のリクエストは続行できますが、自動更新を有効にするには、証明書の有効期限が切れる前に、お客様またはお客様の管理者が必要なアクセス許可を指定する必要があります。詳細については、「 でのサービスにリンクされたロールの使用ACM」を参照してください。
-
この ACM により、アカウントに SLR が存在しないと判断され、SLR が自動的に作成されます。
-
CLI を使用したプライベート証明書のリクエスト
で request-certificateACM. コマンドを使用してプライベート証明書をリクエストします。
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 でのサービスにリンクされたロールの使用」を参照してください。