# Certificate authorities in AWS Private CA Using AWS Private Certificate Authority, you can create an entirely AWS hosted hierarchy of root and subordinate certificate authorities (CAs) for internal use by your organization. To manage certificate revocation, you can enable Online Certificate Status Protocol (OCSP), certificate revocation lists (CRLs), or both. AWS Private CA stores and manages your CA certificates, CRLs, and OCSP responses, and the private keys for your root authorities are securely stored by AWS. **Note** The OCSP implementation in AWS Private CA does not support OCSP request extensions. If you submit an OCSP batch query containing multiple certificates, the AWS OCSP responder processes only the first certificate in the queue and drops the others. A revocation might take up to an hour to appear in OCSP responses. You can access AWS Private CA using the AWS Management Console, the AWS CLI, and the AWS Private CA API. The following topics show you how to use the console and the CLI. To learn more about the API, see the [AWS Private Certificate Authority API Reference](https://docs.aws.amazon.com/privateca/latest/APIReference/). For Java examples that show you how to use the API, see [Use AWS Private CA with the AWS SDK for Java](PcaApiIntro.md). After you create an active private CA and configured access to it, you can issue and retrieve certificates, as described in [Issue and manage certificates in AWS Private CA](PcaUsing.md). **Topics** + [Set up to use AWS Private CA](setup-aws.md) + [Create a private CA in AWS Private CA](create-CA.md) + [Installing the CA certificate](PCACertInstall.md) + [Control access to the private CA](granting-ca-access.md) + [List private CAs](list-CAs.md) + [View a private CA](describe-CA.md) + [Add tags for your private CA](PcaCaTagging.md) + [Understand AWS Private CA CA status](PcaUpdateStatus.md) + [Update a private CA in AWS Private Certificate Authority](PCAUpdateCA.md) + [Delete your private CA](PCADeleteCA.md) + [Restore a private CA](PCARestoreCA.md) + [Use externally signed private CA certificates](PcaExternalRoot.md) # Set up to use AWS Private CA If you're not already an Amazon Web Services (AWS) customer, you must sign up to be able to use AWS Private CA. Your account automatically has access to all available services, but you are charged only for services that you use. **Topics** + [Sign up for an AWS account](#sign-up-for-aws) + [Create a user with administrative access](#create-an-admin) + [Install the AWS Command Line Interface](#cli) ## Sign up for an AWS account If you do not have an AWS account, complete the following steps to create one. **To sign up for an AWS account** 1. Open [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup). 1. Follow the online instructions. Part of the sign-up procedure involves receiving a phone call or text message and entering a verification code on the phone keypad. When you sign up for an AWS account, an *AWS account root user* is created. The root user has access to all AWS services and resources in the account. As a security best practice, assign administrative access to a user, and use only the root user to perform [tasks that require root user access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks). AWS sends you a confirmation email after the sign-up process is complete. At any time, you can view your current account activity and manage your account by going to [https://aws.amazon.com/](https://aws.amazon.com/) and choosing **My Account**. ## Create a user with administrative access After you sign up for an AWS account, secure your AWS account root user, enable AWS IAM Identity Center, and create an administrative user so that you don't use the root user for everyday tasks. **Secure your AWS account root user** 1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/) as the account owner by choosing **Root user** and entering your AWS account email address. On the next page, enter your password. For help signing in by using root user, see [Signing in as the root user](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) in the *AWS Sign-In User Guide*. 1. Turn on multi-factor authentication (MFA) for your root user. For instructions, see [Enable a virtual MFA device for your AWS account root user (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) in the *IAM User Guide*. **Create a user with administrative access** 1. Enable IAM Identity Center. For instructions, see [Enabling AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) in the *AWS IAM Identity Center User Guide*. 1. In IAM Identity Center, grant administrative access to a user. For a tutorial about using the IAM Identity Center directory as your identity source, see [ Configure user access with the default IAM Identity Center directory](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) in the *AWS IAM Identity Center User Guide*. **Sign in as the user with administrative access** + To sign in with your IAM Identity Center user, use the sign-in URL that was sent to your email address when you created the IAM Identity Center user. For help signing in using an IAM Identity Center user, see [Signing in to the AWS access portal](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) in the *AWS Sign-In User Guide*. **Assign access to additional users** 1. In IAM Identity Center, create a permission set that follows the best practice of applying least-privilege permissions. For instructions, see [ Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) in the *AWS IAM Identity Center User Guide*. 1. Assign users to a group, and then assign single sign-on access to the group. For instructions, see [ Add groups](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) in the *AWS IAM Identity Center User Guide*. ## Install the AWS Command Line Interface If you have not installed the AWS CLI but want to use it, follow the directions at [AWS Command Line Interface](https://aws.amazon.com/cli/). In this guide, we assume that you have [configured](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) your endpoint, Region, and authentication details, and we omit these parameters from the sample commands. # Create a private CA in AWS Private CA You can use the procedures in this section to create either root CAs or subordinate CAs, resulting in an auditable hierarchy of trust relationships that matches your organizational needs. You can create a CA using the AWS Management Console, the PCA portion of the AWS CLI, or AWS CloudFormation. For information about updating the configuration of a CA that you have already created, see [Update a private CA in AWS Private Certificate Authority](PCAUpdateCA.md). For information about using a CA to sign end-entity certificates for your users, devices, and applications, see [Issue private end-entity certificates](PcaIssueCert.md). **Note** Your account is charged a monthly price for each private CA starting from the time that you create it. For the latest AWS Private CA pricing information, see [AWS Private Certificate Authority Pricing](https://aws.amazon.com/private-ca/pricing/). You can also use the [AWS pricing calculator](https://calculator.aws/#/createCalculator/certificateManager) to estimate costs. **Topics** + [CLI examples for creating a private CA](#create-ca-cli-examples) ------ #### [ Console ] **To create a private CA using the console** 1. Complete the following steps to create a private CA using the AWS Management Console. **To get started using the console** Sign in to your AWS account and open the AWS Private CA console at **[https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home)**. + If you are opening the console in a Region where you have no private CAs, the introductory page appears. Choose **Create a private CA**. + If you are opening the console in a Region where you have already created a CA, the **Private certificate authorities** page opens with a list of your CAs. Choose **Create CA**. 1. Under **Mode options**, choose the expiration mode of the certificates that your CA issues. + **General-purpose** – Issues certificates that can be configured with any expiration date. This is the default. + **Short-lived certificate** – Issues certificates with a maximum validity period of seven days. A short validity period can substitute in some cases for a revocation mechanism. 1. On the **Type options** section of the console, choose the type of private certificate authority that you want to create. + Choosing **Root** establishes a new CA hierarchy. This CA is backed by a self-signed certificate. It serves as the ultimate signing authority for other CAs and end-entity certificates in the hierarchy. + Choosing **Subordinate** creates a CA that must be signed by a parent CA above it in the hierarchy. Subordinate CAs are typically used to create other subordinate CAs or to issue end-entity certificates to users, computers, and applications. **Note** AWS Private CA provides an automated signing process when your subordinate CA's parent CA is also hosted by AWS Private CA. All you do is choose the parent CA to use. Your subordinate CA might need to be signed by an external trust services provider. If so, AWS Private CA provides you with a certificate signing request (CSR) that you must download and use to obtain a signed CA certificate. For more information, see [Install a subordinate CA certificate signed by an external parent CA](PCACertInstall.md#InstallSubordinateExternal). 1. Under **Subject distinguished name options**, configure the subject name of your private CA. You must enter a value for at least one of the following options: + **Organization (O)** – For example, a company name + **Organization Unit (OU)** – For example, a division within a company + **Country name (C)** – A two-letter country code + **State or province name** – Full name of a state or province + **Locality name** – The name of a city + **Common Name (CN)** – A human-readable string to identify the CA. **Note** You can further customize the subject name of a certificate by applying an APIPassthrough template at the time of issue. For more information and a detailed example, see [Issue a certificate with a custom subject name using an APIPassthrough template](PcaIssueCert.md#custom-subject-1). Because the backing certificate is self-signed, the subject information that you provide for a private CA is probably more sparse than what a public CA would contain. For more information about each of the values that make up a subject distinguished name, see [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.4). 1. Under **Key algorithm options**, choose the key algorithm and the algorithm strength. The default value is RSA 2048. You can choose from the following algorithms: + ML-DSA-44 + ML-DSA-65 + ML-DSA-87 + RSA 2048 + RSA 3072 + RSA 4096 + ECDSA P256 + ECDSA P384 + ECDSA P521 1. Under **Certificate revocation options**, you can select from two methods of sharing revocation status with clients that use your certificates: + **Activate CRL distribution** + **Turn on OCSP** You can configure either, neither, or both of these revocation options for your CA. Although optional, managed revocation is recommended as a [best practice](ca-best-practices.md). Before completing this step, see [Plan your AWS Private CA certificate revocation method](revocation-setup.md) for information about the advantages of each method, the preliminary setup that might be required, and additional revocation features. **Note** If you create your CA without configuring revocation, you can always configure it later. For more information, see [Update a private CA in AWS Private Certificate Authority](PCAUpdateCA.md). To configure **Certificate revocation options**, perform the following steps. 1. Under **Certificate revocation options**, choose **Activate CRL distribution**. 1. Under **S3 bucket URI**, choose an existing bucket from the list. When you specify an existing bucket, you must ensure that BPA is disabled for the account and for the bucket. Otherwise, the operation to create the CA fail. If the CA is created successfully, you must still manually attach a policy to it before you can begin generating CRLs. Use one of the policy patterns described in [Access policies for CRLs in Amazon S3](crl-planning.md#s3-policies). For more information, see [Adding a bucket policy using the Amazon S3 console.](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html) 1. Expand **CRL settings** for additional configuration options. + Choose **Enable partitioning** to enable partitioning of CRLs. If you don't enable partitioning, your CA is subject to the maximum number of revoked certificates. For more information, see [AWS Private Certificate Authority quotas](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca). For more information about partitioned CRLs, see [CRL types](crl-planning.md#crl-type). + Add a **Custom CRL Name** to create an alias for your Amazon S3 bucket. This name is contained in certificates issued by the CA in the “CRL Distribution Points" extension that is defined by RFC 5280. To use CRLs over IPv6, set this to your bucket's dualstack S3 endpoint as described in [Using CRLs over IPv6](crl-planning.md#crl-ipv6). + Add a **Custom path** to create a DNS alias for the file path in your Amazon S3 bucket. + Type the **Validity in days ** your CRL will remain valid. The default value is 7 days. For online CRLs, a validity period of 2-7 days is common. AWS Private CA tries to regenerate the CRL at the midpoint of the specified period. 1. For **Certificate revocation options**, choose **Turn on OCSP**. 1. In the **Custom OCSP endpoint * - optional*** field, you can provide a fully qualified domain name (FQDN) for a non-Amazon OCSP endpoint. To use OCSP over IPv6, set this field to a dualstack endpoint as described in [Using OCSP over IPv6](ocsp-customize.md#ocsp-ipv6). When you provide an FQDN in this field, AWS Private CA inserts the FQDN into the *Authority Information Access* extension of each issued certificate in place of the default URL for the AWS OCSP responder. When an endpoint receives a certificate containing the custom FQDN, it queries that address for an OCSP response. For this mechanism to work, you need to take two additional actions: + Use a proxy server to forward traffic that arrives at your custom FQDN to the AWS OCSP responder. + Add a corresponding CNAME record to your DNS database. **Tip** For more information about implementing a complete OCSP solution using a custom CNAME, see [Customize OCSP URL for AWS Private CA](ocsp-customize.md). For example, here is a CNAME record for customized OCSP as it would appear in Amazon Route 53. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/privateca/latest/userguide/create-CA.html) **Note** The value of the CNAME must not include a protocol prefix such as "http://" or "https://". 1. Under **Add tags**, you can optionally tag your CA. Tags are key-value pairs that serve as metadata for identifying and organizing AWS resources. For a list of AWS Private CA tag parameters and for instructions on how to add tags to CAs after creation, see [Add tags for your private CA](PcaCaTagging.md). **Note** To attach tags to a private CA during the creation procedure, a CA administrator must first associate an inline IAM policy with the `CreateCertificateAuthority` action and explicitly allow tagging. For more information, see [Tag-on-create: Attaching tags to a CA at the time of creation](auth-InlinePolicies.md#tag-on-create). 1. Under **CA permissions options**, you can optionally delegate automatic renewal permissions to the AWS Certificate Manager service principal. ACM can only automatically renew private end-entity certificates generated by this CA if this permission is granted. You can assign renewal permissions at any time with the AWS Private CA [CreatePermission](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CreatePermission.html) API or [create-permission](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/create-permission.html) CLI command. The default is to enable these permissions. **Note** AWS Certificate Manager does not support the automatic renewal of short-lived certificates. 1. Under **Pricing**, confirm that you understand the pricing for a private CA. **Note** For the latest AWS Private CA pricing information, see [AWS Private Certificate Authority Pricing](https://aws.amazon.com/private-ca/pricing/). You can also use the [AWS pricing calculator](https://calculator.aws/#/createCalculator/certificateManager) to estimate costs. 1. Choose **Create CA** after you have checked all of the entered information for accuracy. The details page for the CA opens and displays its status as **Pending certificate**. **Note** While on the details page, you can finish configuring your CA by choosing **Actions**, **Install CA certificate**, or you can return later to the **Private certificate authorities** list and complete the installation procedure that applies in your case: [Install a root CA certificate](PCACertInstall.md#InstallRoot) [Install a subordinate CA certificate hosted by AWS Private CA](PCACertInstall.md#InstallSubordinateInternal) [Install a subordinate CA certificate signed by an external parent CA](PCACertInstall.md#InstallSubordinateExternal) ------ #### [ CLI ] Use the [create-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/create-certificate-authority.html) command to create a private CA. You must specify the CA configuration (containing algorithm and subject-name information), the revocation configuration (if you plan to use OCSP and/or a CRL), and the CA type (root or subordinate). The configuration and revocation configuration details are contained in two files that you supply as arguments to the command. Optionally, you can also configure the CA usage mode (for issuing standard or short-lived certificates), attach tags, and provide an idempotency token. If you are configuring a CRL, you must have a secured Amazon S3 bucket in place *before* you issue the **create-certificate-authority** command. For more information, see [Access policies for CRLs in Amazon S3](crl-planning.md#s3-policies). The CA configuration file specifies the following information: + The name of the algorithm + The key size to be used to create the CA private key + The type of signing algorithm that the CA uses to sign its own Certificate Signing Request, CRLs, and OCSP responses + X.500 subject information The revocation configuration for OCSP defines an `OcspConfiguration` object with the following information: + The `Enabled` flag set to "true". + (Optional) A custom CNAME declared as a value for `OcspCustomCname`. The revocation configuration for a CRL defines a `CrlConfiguration` object with the following information: + The `Enabled` flag set to "true". + The CRL expiration period in days (the validity period of the CRL). + The Amazon S3 bucket that will contain the CRL. + (Optional) An [S3ObjectAcl](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CrlConfiguration.html#privateca-Type-CrlConfiguration-S3ObjectAcl) value that determines whether the CRL is publicly accessible. In the example presented here, public access is blocked. For more information, see [Enable S3 Block Public Access (BPA) with CloudFront](crl-planning.md#s3-bpa). + (Optional) A CNAME alias for the S3 bucket that is included in certificates issued by the CA. If the CRL is not publicly accessible, this will point to a distribution mechanism such as Amazon CloudFront. + (Optional) A `CrlDistributionPointExtensionConfiguration` object with the following information: + The `OmitExtension` flag set to "true" or "false". This controls whether the default value for the CDP extension will be written to a certificate issued by the CA. For more information about the CDP extension, see [Determining the CRL Distribution Point (CDP) URI](crl-planning.md#crl-url). A CustomCname cannot be set if OmitExtension is "true". + (Optional) A custom path for the CRL in the S3 bucket. + (Optional) A [CrlType](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CrlConfiguration.html#privateca-Type-CrlConfiguration-CrlType) value that determines whether the CRL will be complete or partitioned. If not supplied, the CRL will default to complete. **Note** You can enable both revocation mechanisms on the same CA by defining both an `OcspConfiguration` object and a `CrlConfiguration` object. If you supply no **--revocation-configuration** parameter, both mechanisms are disabled by default. If you need revocation validation support later, see [Updating a CA (CLI)](PCAUpdateCA.md#ca-update-cli). See the following section for CLI examples. ------ ## CLI examples for creating a private CA The following examples assume that you have set up your `.aws` configuration directory with a valid default Region, endpoint, and credentials. For information about configuring your AWS CLI environment, see [Configuration and credential file settings](https://docs.aws.amazon.com/cli/latest/reference/cli-configure-files.html). For readability, we supply the CA configuration and revocation input as JSON files in the example commands. Modify the example files as needed for your use. All of the examples use the following `ca_config.txt` configuration file unless otherwise stated. **File: ca\$1config.txt** ``` { "KeyAlgorithm":"RSA_2048", "SigningAlgorithm":"SHA256WITHRSA", "Subject":{ "Country":"US", "Organization":"Example Corp", "OrganizationalUnit":"Sales", "State":"WA", "Locality":"Seattle", "CommonName":"www.example.com" } } ``` ### Example 1: Create a CA with OCSP enabled In this example, the revocation file enables default OCSP support, which uses the AWS Private CA responder to check certificate status. **File: revoke\$1config.txt for OCSP** ``` { "OcspConfiguration":{ "Enabled":true } } ``` **Command** ``` $ aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config.txt \ --revocation-configuration file://revoke_config.txt \ --certificate-authority-type "ROOT" \ --idempotency-token 01234567 \ --tags Key=Name,Value=MyPCA ``` If successful, this command outputs the Amazon Resource Name (ARN) of the new CA. ``` { "CertificateAuthorityArn":"arn:aws:acm-pca:region:account: certificate-authority/CA_ID" } ``` **Command** ``` $ aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config.txt \ --revocation-configuration file://revoke_config.txt \ --certificate-authority-type "ROOT" \ --idempotency-token 01234567 \ --tags Key=Name,Value=MyPCA-2 ``` If successful, this command outputs the Amazon Resource Name (ARN) of the CA. ``` { "CertificateAuthorityArn":"arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" } ``` Use the following command to inspect the configuration of your CA. ``` $ aws acm-pca describe-certificate-authority \ --certificate-authority-arn "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" \ --output json ``` This description should contain the following section. ``` "RevocationConfiguration": { ... "OcspConfiguration": { "Enabled": true } ... } ``` ### Example 2: Create a CA with OCSP and a custom CNAME enabled In this example, the revocation file enables customized OCSP support. The `OcspCustomCname` parameter takes a fully qualified domain name (FQDN) as its value. When you provide an FQDN in this field, AWS Private CA inserts the FQDN into the *Authority Information Access* extension of each issued certificate in place of the default URL for the AWS OCSP responder. When an endpoint receives a certificate containing the custom FQDN, it queries that address for an OCSP response. For this mechanism to work, you need to take two additional actions: + Use a proxy server to forward traffic that arrives at your custom FQDN to the AWS OCSP responder. + Add a corresponding CNAME record to your DNS database. **Tip** For more information about implementing a complete OCSP solution using a custom CNAME, see [Customize OCSP URL for AWS Private CA](ocsp-customize.md). For example, here is a CNAME record for customized OCSP as it would appear in Amazon Route 53. **** | Record name | Type | Routing policy | Differentiator | Value/Route traffic to | | --- | --- | --- | --- | --- | | alternative.example.com | CNAME | Simple | - | proxy.example.com | **Note** The value of the CNAME must not include a protocol prefix such as "http://" or "https://". **File: revoke\$1config.txt for OCSP** ``` { "OcspConfiguration":{ "Enabled":true, "OcspCustomCname":"alternative.example.com" } } ``` **Command** ``` $ aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config.txt \ --revocation-configuration file://revoke_config.txt \ --certificate-authority-type "ROOT" \ --idempotency-token 01234567 \ --tags Key=Name,Value=MyPCA-3 ``` If successful, this command outputs the Amazon Resource Name (ARN) of the CA. ``` { "CertificateAuthorityArn":"arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" } ``` Use the following command to inspect the configuration of your CA. ``` $ aws acm-pca describe-certificate-authority \ --certificate-authority-arn "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" \ --output json ``` This description should contain the following section. ``` "RevocationConfiguration": { ... "OcspConfiguration": { "Enabled": true, "OcspCustomCname": "alternative.example.com" } ... } ``` ### Example 3: Create a CA with an attached CRL In this example, the revocation configuration defines CRL parameters. **File: revoke\$1config.txt** ``` { "CrlConfiguration":{ "Enabled":true, "ExpirationInDays":7, "S3BucketName":"amzn-s3-demo-bucket" } } ``` **Command** ``` $ aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config.txt \ --revocation-configuration file://revoke_config.txt \ --certificate-authority-type "ROOT" \ --idempotency-token 01234567 \ --tags Key=Name,Value=MyPCA-1 ``` If successful, this command outputs the Amazon Resource Name (ARN) of the CA. ``` { "CertificateAuthorityArn":"arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" } ``` Use the following command to inspect the configuration of your CA. ``` $ aws acm-pca describe-certificate-authority \ --certificate-authority-arn "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" \ --output json ``` This description should contain the following section. ``` "RevocationConfiguration": { ... "CrlConfiguration": { "Enabled": true, "ExpirationInDays": 7, "S3BucketName": "amzn-s3-demo-bucket" }, ... } ``` ### Example 4: Create a CA with an attached CRL and a custom CNAME enabled In this example, the revocation configuration defines CRL parameters that include a custom CNAME. **File: revoke\$1config.txt** ``` { "CrlConfiguration":{ "Enabled":true, "ExpirationInDays":7, "CustomCname": "alternative.example.com", "S3BucketName":"amzn-s3-demo-bucket" } } ``` **Command** ``` $ aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config.txt \ --revocation-configuration file://revoke_config.txt \ --certificate-authority-type "ROOT" \ --idempotency-token 01234567 \ --tags Key=Name,Value=MyPCA-1 ``` If successful, this command outputs the Amazon Resource Name (ARN) of the CA. ``` { "CertificateAuthorityArn":"arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" } ``` Use the following command to inspect the configuration of your CA. ``` $ aws acm-pca describe-certificate-authority \ --certificate-authority-arn "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" \ --output json ``` This description should contain the following section. ``` "RevocationConfiguration": { ... "CrlConfiguration": { "Enabled": true, "ExpirationInDays": 7, "CustomCname": "alternative.example.com", "S3BucketName": "amzn-s3-demo-bucket", ... } } ``` ### Example 5: Create a CA and specify the usage mode In this example, the CA usage mode is specified when creating a CA. If unspecified, the usage mode parameter defaults to GENERAL\$1PURPOSE. In this example, the parameter is set to SHORT\$1LIVED\$1CERTIFICATE, which means that the CA will issue certificates with a maximum validity period of seven days. In situations where it is inconvenient to configure revocation, a short-lived certificate that has been compromised quickly expires as part of normal operations. Consequently, this example CA lacks a revocation mechanism. **Note** AWS Private CA does not perform validity checks on root CA certificates. ``` $ aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config.txt \ --certificate-authority-type "ROOT" \ --usage-mode SHORT_LIVED_CERTIFICATE \ --tags Key=usageMode,Value=SHORT_LIVED_CERTIFICATE ``` Use the [https://docs.aws.amazon.com/cli/latest/reference/acm-pca/describe-certificate-authority.html](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/describe-certificate-authority.html) command in the AWS CLI to display details about the resulting CA, as shown in the following command: ``` $ aws acm-pca describe-certificate-authority \ --certificate-authority-arn arn:aws:acm:region:account:certificate-authority/CA_ID ``` ``` { "CertificateAuthority":{ "Arn":"arn:aws:acm-pca:region:account:certificate-authority/CA_ID", "CreatedAt":"2022-09-30T09:53:42.769000-07:00", "LastStateChangeAt":"2022-09-30T09:53:43.784000-07:00", "Type":"ROOT", "UsageMode":"SHORT_LIVED_CERTIFICATE", "Serial":"serial_number", "Status":"PENDING_CERTIFICATE", "CertificateAuthorityConfiguration":{ "KeyAlgorithm":"RSA_2048", "SigningAlgorithm":"SHA256WITHRSA", "Subject":{ "Country":"US", "Organization":"Example Corp", "OrganizationalUnit":"Sales", "State":"WA", "Locality":"Seattle", "CommonName":"www.example.com" } }, "RevocationConfiguration":{ "CrlConfiguration":{ "Enabled":false }, "OcspConfiguration":{ "Enabled":false } }, ... ``` ### Example 6: Create a CA for Active Directory login You can create a private CA suitable for use in the Enterprise NTAuth store of Microsoft Active Directory (AD), where it can issue card-logon or domain-controller certificates. For information about importing a CA certificate into AD, see [How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store). The Microsoft [certutil](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil) tool can be used to publish CA certificates in AD by invoking the **-dspublish** option. A certificate published to AD with certutil is trusted across the entire forest. Using group policy, you can also limit trust to a subset of the entire forest, for example, a single domain or a group of computers in a domain. For logon to work, the issuing CA must also be published in the NTAuth store. For more information, see [Distribute Certificates to Client Computers by Using Group Policy](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/distribute-certificates-to-client-computers-by-using-group-policy). This example uses the following `ca_config_AD.txt` configuration file. **File: ca\$1config\$1AD.txt** ``` { "KeyAlgorithm":"RSA_2048", "SigningAlgorithm":"SHA256WITHRSA", "Subject":{ "CustomAttributes":[ { "ObjectIdentifier":"2.5.4.3", "Value":"root CA" }, { "ObjectIdentifier":"0.9.2342.19200300.100.1.25", "Value":"example" }, { "ObjectIdentifier":"0.9.2342.19200300.100.1.25", "Value":"com" } ] } } ``` **Command** ``` $ aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config_AD.txt \ --certificate-authority-type "ROOT" \ --tags Key=application,Value=ActiveDirectory ``` If successful, this command outputs the Amazon Resource Name (ARN) of the CA. ``` { "CertificateAuthorityArn":"arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" } ``` Use the following command to inspect the configuration of your CA. ``` $ aws acm-pca describe-certificate-authority \ --certificate-authority-arn "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" \ --output json ``` This description should contain the following section. ``` ... "Subject":{ "CustomAttributes":[ { "ObjectIdentifier":"2.5.4.3", "Value":"root CA" }, { "ObjectIdentifier":"0.9.2342.19200300.100.1.25", "Value":"example" }, { "ObjectIdentifier":"0.9.2342.19200300.100.1.25", "Value":"com" } ] } ... ``` ### Example 7: Create a Matter CA with an attached CRL and the CDP extension omitted from issued certificates You can create a private CA suitable for issuing certificates for the Matter smart home standard. In this example, the CA configuration in `ca_config_PAA.txt` defines a Matter Product Attestation Authority (PAA) with the Vendor ID (VID) set to FFF1. **File: ca\$1config\$1PAA.txt** ``` { "KeyAlgorithm":"EC_prime256v1", "SigningAlgorithm":"SHA256WITHECDSA", "Subject":{ "Country":"US", "Organization":"Example Corp", "OrganizationalUnit":"SmartHome", "State":"WA", "Locality":"Seattle", "CommonName":"Example Corp Matter PAA", "CustomAttributes":[ { "ObjectIdentifier":"1.3.6.1.4.1.37244.2.1", "Value":"FFF1" } ] } } ``` The revocation configuration enables CRLs, and configures the CA to omit the default CDP URL from any issued certificates. **File: revoke\$1config.txt** ``` { "CrlConfiguration":{ "Enabled":true, "ExpirationInDays":7, "S3BucketName":"amzn-s3-demo-bucket", "CrlDistributionPointExtensionConfiguration":{ "OmitExtension":true } } } ``` **Command** ``` $ aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config_PAA.txt \ --revocation-configuration file://revoke_config.txt \ --certificate-authority-type "ROOT" \ --idempotency-token 01234567 \ --tags Key=Name,Value=MyPCA-1 ``` If successful, this command outputs the Amazon Resource Name (ARN) of the CA. ``` { "CertificateAuthorityArn":"arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" } ``` Use the following command to inspect the configuration of your CA. ``` $ aws acm-pca describe-certificate-authority \ --certificate-authority-arn "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" \ --output json ``` This description should contain the following section. ``` "RevocationConfiguration": { ... "CrlConfiguration": { "Enabled": true, "ExpirationInDays": 7, "S3BucketName": "amzn-s3-demo-bucket", "CrlDistributionPointExtensionConfiguration":{ "OmitExtension":true } }, ... } ... ``` # Installing the CA certificate Complete the following procedures to create and install your private CA certificate. Your CA will then be ready to use. AWS Private CA supports three scenarios for installing a CA certificate: + Installing a certificate for a root CA hosted by AWS Private CA + Installing a subordinate CA certificate whose parent authority is hosted by AWS Private CA + Installing a subordinate CA certificate whose parent authority is externally hosted The following sections describe procedures for each scenario. The console procedures begin on the console page **Private CAs**. ## Compatible signing algorithms Signing algorithm support for CA certificates depends on the signing algorithm of the parent CA and on the AWS Region. The following constraints apply to both console and AWS CLI operations. + A parent CA with the RSA key algorithm can issue certificates with the following signing algorithms: + SHA256 RSA + SHA384 RSA + SHA512 RSA + In a legacy AWS Region, a parent CA with the EDCSA key algorithm can issue certificates with the following signing algorithms: + SHA256 ECDSA + SHA384 ECDSA + SHA512 ECDSA Legacy AWS Regions include: **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/privateca/latest/userguide/PCACertInstall.html) + In a non-legacy AWS Region, the following rules apply for EDCSA: + A parent CA with the EC\$1prime256v1 signing algorithm can issue certificates with ECDSA P256. + A parent CA with the EC\$1secp384r1 signing algorithm can issue certificates with ECDSA P384. + In every AWS Region, the following rules apply for EDCSA: + A parent CA with the EC\$1secp521r1 signing algorithm can issue certificates with ECDSA P521. ## Install a root CA certificate You can install a root CA certificate from the AWS Management Console or the AWS CLI. **To create and install a certificate for your private root CA (console)** 1. (Optional) If you are not already on the CA's details page, open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home). On the **Private certificate authorities** page, choose a root CA with status **Pending certificate** or **Active**. 1. Choose **Actions**, **Install CA certificate** to open the **Install root CA certificate** page. 1. Under **Specify the root CA certificate parameters**, specify the following certificate parameters: + **Validity** — Specifies the expiration date and time for the CA certificate. The AWS Private CA default validity period for a root CA certificate is 10 years. + **Signature algorithm** — Specifies the signing algorithm to use when the root CA issues new certificates. Available options vary according to the AWS Region where you are creating the CA. For more information, see [Compatible signing algorithms](#signing_algorithms), [Supported cryptographic algorithms in AWS Private Certificate Authority](PcaWelcome.md#supported-algorithms), and **SigningAlgorithm** in [CertificateAuthorityConfiguration](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CertificateAuthorityConfiguration.html#API_CertificateAuthorityConfiguration_Contents). + SHA256 RSA + SHA384 RSA + SHA512 RSA Review your settings for correctness, then choose **Confirm and install**. AWS Private CA exports a CSR for your CA, generates a certificate using a root CA certificate [template](UsingTemplates.md), and self-signs the certificate. AWS Private CA then imports the self-signed root CA certificate. 1. The details page for the CA displays the status of the installation (success or failure) at the top. If the installation was successful, the newly completed root CA displays a status of **Active** in the **General** pane. **To create and install a certificate for your private root CA (AWS CLI)** 1. Generate a certificate signing request (CSR). ``` $ aws acm-pca get-certificate-authority-csr \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566 \ --output text \ --region region > ca.csr ``` The resulting file `ca.csr`, a PEM file encoded in base64 format, has the following appearance. ``` -----BEGIN CERTIFICATE REQUEST----- MIIC1DCCAbwCAQAwbTELMAkGA1UEBhMCVVMxFTATBgNVBAoMDEV4YW1wbGUgQ29y cDEOMAwGA1UECwwFU2FsZXMxCzAJBgNVBAgMAldBMRgwFgYDVQQDDA93d3cuZXhh bXBsZS5jb20xEDAOBgNVBAcMB1NlYXR0bGUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDD+7eQChWUO2m6pHslI7AVSFkWvbQofKIHvbvy7wm8VO9/BuI7 LE/jrnd1jGoyI7jaMHKXPtEP3uNlCzv+oEza07OjgjqPZVehtA6a3/3vdQ1qCoD2 rXpv6VIzcq2onx2X7m+Zixwn2oY1l1ELXP7I5g0GmUStymq+pY5VARPy3vTRMjgC JEiz8w7VvC15uIsHFAWa2/NvKyndQMPaCNft238wesV5s2cXOUS173jghIShg99o ymf0TRUgvAGQMCXvsW07MrP5VDmBU7k/AZ9ExsUfMe2OB++fhfQWr2N7/lpC4+DP qJTfXTEexLfRTLeLuGEaJL+c6fMyG+Yk53tZAgMBAAGgIjAgBgkqhkiG9w0BCQ4x EzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAA7xxLVI5s1B qmXMMT44y1DZtQx3RDPanMNGLGO1TmLtyqqnUH49Tla+2p7nrl0tojUf/3PaZ52F QN09SrFk8qtYSKnMGd5PZL0A+NFsNW+w4BAQNKlg9m617YEsnkztbfKRloaJNYoA HZaRvbA0lMQ/tU2PKZR2vnao444Ugm0O/t3jx5rj817b31hQcHHQ0lQuXV2kyTrM ohWeLf2fL+K0xJ9ZgXD4KYnY0zarpreA5RBeO5xs3Ms+oGWc13qQfMBx33vrrz2m dw5iKjg71uuUUmtDV6ewwGa/VO5hNinYAfogdu5aGuVbnTFT3n45B8WHz2+9r0dn bA7xUel1SuQ= -----END CERTIFICATE REQUEST----- ``` You can use [OpenSSL](https://www.openssl.org/) to view and verify the contents of the CSR. ``` openssl req -text -noout -verify -in ca.csr ``` This yields output similar to the following. ``` verify OK Certificate Request: Data: Version: 0 (0x0) Subject: C=US, O=Example Corp, OU=Sales, ST=WA, CN=www.example.com, L=Seattle Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c3:fb:b7:90:0a:15:94:3b:69:ba:a4:7b:25:23: b0:15:48:59:16:bd:b4:28:7c:a2:07:bd:bb:f2:ef: 09:bc:54:ef:7f:06:e2:3b:2c:4f:e3:ae:77:75:8c: 6a:32:23:b8:da:30:72:97:3e:d1:0f:de:e3:65:0b: 3b:fe:a0:4c:da:d3:b3:a3:82:3a:8f:65:57:a1:b4: 0e:9a:df:fd:ef:75:0d:6a:0a:80:f6:ad:7a:6f:e9: 52:33:72:ad:a8:9f:1d:97:ee:6f:99:8b:1c:27:da: 86:35:97:51:0b:5c:fe:c8:e6:0d:06:99:44:ad:ca: 6a:be:a5:8e:55:01:13:f2:de:f4:d1:32:38:02:24: 48:b3:f3:0e:d5:bc:2d:79:b8:8b:07:14:05:9a:db: f3:6f:2b:29:dd:40:c3:da:08:d7:ed:db:7f:30:7a: c5:79:b3:67:17:39:44:b5:ef:78:e0:84:84:a1:83: df:68:ca:67:f4:4d:15:20:bc:01:90:30:25:ef:b1: 6d:3b:32:b3:f9:54:39:81:53:b9:3f:01:9f:44:c6: c5:1f:31:ed:8e:07:ef:9f:85:f4:16:af:63:7b:fe: 5a:42:e3:e0:cf:a8:94:df:5d:31:1e:c4:b7:d1:4c: b7:8b:b8:61:1a:24:bf:9c:e9:f3:32:1b:e6:24:e7: 7b:59 Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: sha256WithRSAEncryption 0e:f1:c4:b5:48:e6:cd:41:aa:65:cc:31:3e:38:cb:50:d9:b5: 0c:77:44:33:da:9c:c3:46:2c:63:b5:4e:62:ed:ca:aa:a7:50: 7e:3d:4e:56:be:da:9e:e7:ae:5d:2d:a2:35:1f:ff:73:da:67: 9d:85:40:dd:3d:4a:b1:64:f2:ab:58:48:a9:cc:19:de:4f:64: bd:00:f8:d1:6c:35:6f:b0:e0:10:10:34:a9:60:f6:6e:b5:ed: 81:2c:9e:4c:ed:6d:f2:91:96:86:89:35:8a:00:1d:96:91:bd: b0:34:94:c4:3f:b5:4d:8f:29:94:76:be:76:a8:e3:8e:14:82: 6d:0e:fe:dd:e3:c7:9a:e3:f3:5e:db:df:58:50:70:71:d0:d2: 54:2e:5d:5d:a4:c9:3a:cc:a2:15:9e:2d:fd:9f:2f:e2:b4:c4: 9f:59:81:70:f8:29:89:d8:d3:36:ab:a6:b7:80:e5:10:5e:3b: 9c:6c:dc:cb:3e:a0:65:9c:d7:7a:90:7c:c0:71:df:7b:eb:af: 3d:a6:77:0e:62:2a:38:3b:d6:eb:94:52:6b:43:57:a7:b0:c0: 66:bf:54:ee:61:36:29:d8:01:fa:20:76:ee:5a:1a:e5:5b:9d: 31:53:de:7e:39:07:c5:87:cf:6f:bd:af:47:67:6c:0e:f1:51: e9:75:4a:e4 ``` 1. Using the CSR from the previous step as the argument for the `--csr` parameter, issue the root certificate. **Note** The examples below use the prefix `fileb://` to load required input files, ensuring that AWS Private CA parses Base64-encoded data correctly. If you are using AWS CLI version older than 1.6.3, use `file://` instead. ``` $ aws acm-pca issue-certificate \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --csr fileb://ca.csr \ --signing-algorithm SHA256WITHRSA \ --template-arn arn:aws:acm-pca:::template/RootCACertificate/V1 \ --validity Value=365,Type=DAYS ``` 1. Retrieve the root certificate. ``` $ aws acm-pca get-certificate \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566 \ --certificate-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID/certificate/certificate_ID \ --output text > cert.pem ``` The resulting file `cert.pem`, a PEM file encoded in base64 format, has the following appearance. ``` -----BEGIN CERTIFICATE----- MIIDpzCCAo+gAwIBAgIRAIIuOarlQETlUQEOZJGZYdIwDQYJKoZIhvcNAQELBQAw bTELMAkGA1UEBhMCVVMxFTATBgNVBAoMDEV4YW1wbGUgQ29ycDEOMAwGA1UECwwF U2FsZXMxCzAJBgNVBAgMAldBMRgwFgYDVQQDDA93d3cuZXhhbXBsZS5jb20xEDAO BgNVBAcMB1NlYXR0bGUwHhcNMjEwMzA4MTU0NjI3WhcNMjIwMzA4MTY0NjI3WjBt MQswCQYDVQQGEwJVUzEVMBMGA1UECgwMRXhhbXBsZSBDb3JwMQ4wDAYDVQQLDAVT YWxlczELMAkGA1UECAwCV0ExGDAWBgNVBAMMD3d3dy5leGFtcGxlLmNvbTEQMA4G A1UEBwwHU2VhdHRsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMP7 t5AKFZQ7abqkeyUjsBVIWRa9tCh8oge9u/LvCbxU738G4jssT+Oud3WMajIjuNow cpc+0Q/e42ULO/6gTNrTs6OCOo9lV6G0Dprf/e91DWoKgPatem/pUjNyraifHZfu b5mLHCfahjWXUQtc/sjmDQaZRK3Kar6ljlUBE/Le9NEyOAIkSLPzDtW8LXm4iwcU BZrb828rKd1Aw9oI1+3bfzB6xXmzZxc5RLXveOCEhKGD32jKZ/RNFSC8AZAwJe+x bTsys/lUOYFTuT8Bn0TGxR8x7Y4H75+F9BavY3v+WkLj4M+olN9dMR7Et9FMt4u4 YRokv5zp8zIb5iTne1kCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUaW3+r328uTLokog2TklmoBK+yt4wDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3 DQEBCwUAA4IBAQAXjd/7UZ8RDE+PLWSDNGQdLemOBTcawF+tK+PzA4Evlmn9VuNc g+x3oZvVZSDQBANUz0b9oPeo54aE38dW1zQm2qfTab8822aqeWMLyJ1dMsAgqYX2 t9+u6w3NzRCw8Pvz18V69+dFE5AeXmNP0Z5/gdz8H/NSpctjlzopbScRZKCSlPid Rf3ZOPm9QP92YpWyYDkfAU04xdDo1vR0MYjKPkl4LjRqSU/tcCJnPMbJiwq+bWpX 2WJoEBXB/p15Kn6JxjI0ze2SnSI48JZ8it4fvxrhOo0VoLNIuCuNXJOwU17Rdl1W YJidaq7je6k18AdgPA0Kh8y1XtfUH3fTaVw4 -----END CERTIFICATE----- ``` You can use [OpenSSL](https://www.openssl.org/) to view and verify the contents of the certificate. ``` openssl x509 -in cert.pem -text -noout ``` This yields output similar to the following. ``` Certificate: Data: Version: 3 (0x2) Serial Number: 82:2e:39:aa:e5:40:44:e5:51:01:0e:64:91:99:61:d2 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Example Corp, OU=Sales, ST=WA, CN=www.example.com, L=Seattle Validity Not Before: Mar 8 15:46:27 2021 GMT Not After : Mar 8 16:46:27 2022 GMT Subject: C=US, O=Example Corp, OU=Sales, ST=WA, CN=www.example.com, L=Seattle Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c3:fb:b7:90:0a:15:94:3b:69:ba:a4:7b:25:23: b0:15:48:59:16:bd:b4:28:7c:a2:07:bd:bb:f2:ef: 09:bc:54:ef:7f:06:e2:3b:2c:4f:e3:ae:77:75:8c: 6a:32:23:b8:da:30:72:97:3e:d1:0f:de:e3:65:0b: 3b:fe:a0:4c:da:d3:b3:a3:82:3a:8f:65:57:a1:b4: 0e:9a:df:fd:ef:75:0d:6a:0a:80:f6:ad:7a:6f:e9: 52:33:72:ad:a8:9f:1d:97:ee:6f:99:8b:1c:27:da: 86:35:97:51:0b:5c:fe:c8:e6:0d:06:99:44:ad:ca: 6a:be:a5:8e:55:01:13:f2:de:f4:d1:32:38:02:24: 48:b3:f3:0e:d5:bc:2d:79:b8:8b:07:14:05:9a:db: f3:6f:2b:29:dd:40:c3:da:08:d7:ed:db:7f:30:7a: c5:79:b3:67:17:39:44:b5:ef:78:e0:84:84:a1:83: df:68:ca:67:f4:4d:15:20:bc:01:90:30:25:ef:b1: 6d:3b:32:b3:f9:54:39:81:53:b9:3f:01:9f:44:c6: c5:1f:31:ed:8e:07:ef:9f:85:f4:16:af:63:7b:fe: 5a:42:e3:e0:cf:a8:94:df:5d:31:1e:c4:b7:d1:4c: b7:8b:b8:61:1a:24:bf:9c:e9:f3:32:1b:e6:24:e7: 7b:59 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 69:6D:FE:AF:7D:BC:B9:32:E8:92:88:36:4E:49:66:A0:12:BE:CA:DE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign Signature Algorithm: sha256WithRSAEncryption 17:8d:df:fb:51:9f:11:0c:4f:8f:2d:64:83:34:64:1d:2d:e9: 8e:05:37:1a:c0:5f:ad:2b:e3:f3:03:81:2f:96:69:fd:56:e3: 5c:83:ec:77:a1:9b:d5:65:20:d0:04:03:54:cf:46:fd:a0:f7: a8:e7:86:84:df:c7:56:d7:34:26:da:a7:d3:69:bf:3c:db:66: aa:79:63:0b:c8:9d:5d:32:c0:20:a9:85:f6:b7:df:ae:eb:0d: cd:cd:10:b0:f0:fb:f3:d7:c5:7a:f7:e7:45:13:90:1e:5e:63: 4f:d1:9e:7f:81:dc:fc:1f:f3:52:a5:cb:63:97:3a:29:6d:27: 11:64:a0:92:94:f8:9d:45:fd:d9:38:f9:bd:40:ff:76:62:95: b2:60:39:1f:01:4d:38:c5:d0:e8:d6:f4:74:31:88:ca:3e:49: 78:2e:34:6a:49:4f:ed:70:22:67:3c:c6:c9:8b:0a:be:6d:6a: 57:d9:62:68:10:15:c1:fe:9d:79:2a:7e:89:c6:32:34:cd:ed: 92:9d:22:38:f0:96:7c:8a:de:1f:bf:1a:e1:3a:8d:15:a0:b3: 48:b8:2b:8d:5c:93:b0:53:5e:d1:76:5d:56:60:98:9d:6a:ae: e3:7b:a9:35:f0:07:60:3c:0d:0a:87:cc:b5:5e:d7:d4:1f:77: d3:69:5c:38 ``` 1. Import the root CA certificate to install it on the CA. **Note** The examples below use the prefix `fileb://` to load required input files, ensuring that AWS Private CA parses Base64-encoded data correctly. If you are using AWS CLI version older than 1.6.3, use `file://` instead. ``` $ aws acm-pca import-certificate-authority-certificate \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --certificate fileb://cert.pem ``` Inspect the new status of the CA. ``` $ aws acm-pca describe-certificate-authority \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566 \ --output json ``` The status now appears as ACTIVE. ``` { "CertificateAuthority": { "Arn": "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566", "CreatedAt": "2021-03-05T14:24:12.867000-08:00", "LastStateChangeAt": "2021-03-08T12:37:14.235000-08:00", "Type": "ROOT", "Serial": "serial_number", "Status": "ACTIVE", "NotBefore": "2021-03-08T07:46:27-08:00", "NotAfter": "2022-03-08T08:46:27-08:00", "CertificateAuthorityConfiguration": { "KeyAlgorithm": "RSA_2048", "SigningAlgorithm": "SHA256WITHRSA", "Subject": { "Country": "US", "Organization": "Example Corp", "OrganizationalUnit": "Sales", "State": "WA", "CommonName": "www.example.com", "Locality": "Seattle" } }, "RevocationConfiguration": { "CrlConfiguration": { "Enabled": true, "ExpirationInDays": 7, "CustomCname": "alternative.example.com", "S3BucketName": "amzn-s3-demo-bucket" }, "OcspConfiguration": { "Enabled": false } } } } ``` ## Install a subordinate CA certificate hosted by AWS Private CA You can use the AWS Management Console to create and install a certificate for your AWS Private CA hosted subordinate CA. **To create and install a certificate for your AWS Private CA hosted subordinate CA** 1. (Optional) If you are not already on the CA's details page, open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home). On the **Private certificate authorities** page, choose a subordinate CA with status **Pending certificate** or **Active**. 1. Choose **Actions**, **Install CA Certificate** to open the **Install subordinate CA certificate** page. 1. On the **Install subordinate CA certificate** page, under **Select CA type**, choose **AWS Private CA** to install a certificate that is managed by AWS Private CA. 1. Under **Select parent CA**, choose a CA from the **Parent private CA** list. The list is filtered to display CAs that meet the following criteria: + You have permission to use the CA. + The CA would not be signing itself. + The CA is in state `ACTIVE`. + The CA mode is `GENERAL_PURPOSE`. 1. Under **Specify the subordinate CA certificate parameters**, specify the following certificate parameters: + **Validity** — Specifies the expiration date and time for the CA certificate. + **Signature algorithm** — Specifies the signing algorithm to use when the root CA issues new certificates. Options are: + SHA256 RSA + SHA384 RSA + SHA512 RSA + **Path length** — The number of trust layers that the subordinate CA can add when signing new certificates. A path length of zero (the default) means that only end-entity certificates, and not CA certificates, can be created. A path length of one or more means that the subordinate CA may issue certificates to create additional CAs subordinate to it. + **Template ARN** — Displays the ARN of the configuration template for this CA certificate. The template changes if you change the specified **Path length**. If you create a certificate using the CLI [issue-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/issue-certificate.html) command or API [IssueCertificate](https://docs.aws.amazon.com/privateca/latest/APIReference/API_IssueCertificate.html) action, you must specify the ARN manually. For information about available CA certificate templates, see [Use AWS Private CA certificate templates](UsingTemplates.md). 1. Review your settings for correctness, then choose **Confirm and install**. AWS Private CA exports a CSR, generates a certificate using a subordinate CA certificate [template](UsingTemplates.md), and signs the certificate it with the selected parent CA. AWS Private CA then imports the signed subordinate CA certificate. 1. The details page for the CA displays the status of the installation (success or failure) at the top. If the installation was successful, the newly completed subordinate CA displays a status of **Active** in the **General** pane. ## Install a subordinate CA certificate signed by an external parent CA After you create a subordinate private CA as described in [Create a private CA in AWS Private CA](create-CA.md), you have the option of activating it by installing a CA certificate signed by an external signing authority. Signing your subordinate CA certificate with an external CA requires that you first set up an external trust services provider as your signing authority, or arrange for the use of a third-party provider. **Note** Procedures for creating or obtaining an external trust services provider are outside the scope of this guide. After you have created a subordinate CA and you have access to an external signing authority, complete the following tasks: 1. Obtain a certificate signing request (CSR) from AWS Private CA. 1. Submit the CSR to your external signing authority and obtain a signed CA certificate along with any chain certificates. 1. Import the CA certificate and chain into AWS Private CA to activate your subordinate CA. For detailed procedures, see [Use externally signed private CA certificates](PcaExternalRoot.md). # Control access to the private CA Any user with the necessary permissions on a private CA from AWS Private CA can use that CA to sign other certificates. The CA owner can issue certificates or delegate the required permissions for issuing certificates to an AWS Identity and Access Management (IAM) user that resides in the same AWS account. A user that resides in a different AWS account can also issue certificates if authorized by the CA owner through a [resource-based policy](pca-rbp.md). Authorized users, whether single-account or cross-account, can use AWS Private CA or AWS Certificate Manager resources when issuing certificates. Certificates that are issued from the AWS Private CA [IssueCertificate](https://docs.aws.amazon.com/privateca/latest/APIReference/API_IssueCertificate.html) API or [issue-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/issue-certificate.html) CLI command are unmanaged. Such certificates require manual installation on target devices and manual renewal when they expire. Certificates issued from the ACM console, the ACM [RequestCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_RequestCertificate.html) API, or the [request-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html) CLI command are managed. Such certificates can easily be installed in services that are integrated with ACM. If the CA administrator permits it and the issuer's account has a [service-linked role](https://docs.aws.amazon.com/acm/latest/userguide/acm-slr.html) in place for ACM, managed certificates are renewed automatically when they expire. **Topics** + [Create single-account permissions for an IAM user](assign-permissions.md) + [Attach a policy for cross-account access](pca-ram.md) # Create single-account permissions for an IAM user When the CA administrator (that is, the owner of the CA) and the certificate issuer reside in a single AWS account, a [best practice](ca-best-practices.md) is to separate the issuer and administrator roles by creating an AWS Identity and Access Management (IAM) user with limited permissions. For information about using IAM with AWS Private CA, along with example permissions, see [Identity and Access Management (IAM) for AWS Private Certificate Authority](security-iam.md). **Single-account case 1: Issuing an unmanaged certificate** In this case, the account owner creates a private CA and then creates an IAM user with permission to issue certificates signed by the private CA. The IAM user issues a certificate by calling the AWS Private CA `IssueCertificate` API. ![\[Issuing an unmanaged certificate\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/ca_access_1_account_pca_api.png) Certificates issued in this manner are unmanaged, which means that an administrator must export them and install them on devices where they are intended to be used. They also must be manually renewed when they expire. Issuing a certificate using this API requires a certificate signing request (CSR) and key pair that is generated outside of AWS Private CA by [OpenSSL](https://www.openssl.org/) or a similar program. For more information, see the `IssueCertificate` [documentation](https://docs.aws.amazon.com/privateca/latest/APIReference/API_IssueCertificate.html). **Single-account case 2: Issuing a managed certificate through ACM** This second case involves API operations from both ACM and PCA. The account owner creates a private CA and IAM user as before. The account owner then [grants permission](create-CA.md#PcaCreateAcmPerms) to the ACM service principal to renew automatically any certificates that are signed by this CA. The IAM user again issues the certificate, but this time by calling the ACM `RequestCertificate` API, which handles CSR and key generation. When the certificate expires, ACM automates the renewal workflow. ![\[Issuing a managed certificate\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/ca_access_1_account_acm_api.png) The account owner has the option of granting renewal permission through the management console during or after CA creation or using the PCA `CreatePermission` API. The managed certificates created from this workflow are available for use on with AWS services that are integrated with ACM. The following section contains procedures for granting renewal permissions. ## Assign certificate renewal permissions to ACM With [managed renewal](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) in AWS Certificate Manager (ACM), you can automate the certificate renewal process for both public and private certificates. In order for ACM to automatically renew the certificates generated by a private CA, the ACM service principal must be given all possible permissions *by the CA itself*. If these renewal permissions are not present for ACM, the CA's owner (or an authorized representative) must manually reissue each private certificate when it expires. **Important** These procedures for assigning renewal permissions apply only when the CA owner and the certificate issuer reside in the same AWS account. For cross-account scenarios, see [Attach a policy for cross-account access](pca-ram.md). Renewal permissions can be delegated during [private CA creation](create-CA.md) or altered anytime after as long as the CA is in the `ACTIVE` state. You can manage private CA permissions from the [AWS Private CA Console](https://console.aws.amazon.com/acm-pca), the [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/reference/), or the [AWS Private CA API](https://docs.aws.amazon.com/privateca/latest/APIReference/): **To assign private CA permissions to ACM (console)** 1. Sign in to your AWS account and open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home). 1. On the **Private certificate authorities page**, choose your private CA from the list. 1. Choose **Actions**, **Configure CA permissions**. 1. Select **Authorize ACM access to renew certificates requested by this account**. 1. Choose **Save**. **To manage ACM permissions in AWS Private CA (AWS CLI)** Use the [create-permission](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/create-permission.html) command to assign permissions to ACM. You must assign the necessary permissions (`IssueCertificate`, `GetCertificate`, and `ListPermissions`) in order for ACM to automatically renew your certificates. ``` $ aws acm-pca create-permission \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --actions IssueCertificate GetCertificate ListPermissions \ --principal acm.amazonaws.com ``` Use the [list-permissions](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/list-permissions.html) command to list the permissions delegated by a CA. ``` $ aws acm-pca list-permissions \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID ``` Use the [delete-permission](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/delete-permission.html) command to revoke permissions assigned by a CA to an AWS service principal. ``` $ aws acm-pca delete-permission \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --principal acm.amazonaws.com ``` # Attach a policy for cross-account access When the CA administrator and the certificate issuer reside in different AWS accounts, the CA administrator must share CA access. This is accomplished by attaching a resource-based policy to the CA. The policy grants issuance permissions to a specific principal, which can be an AWS account owner, an IAM user, an AWS Organizations ID, or an organizational unit ID. A CA administrator can attach and manage policies in the following ways: + In the management console, using AWS Resource Access Manager (RAM), which is a standard method for sharing AWS resources across accounts. When you share a CA resource in AWS RAM with a principal in another account, the required resource-based policy is attached to the CA automatically. For more information about RAM, see the [AWS RAM User Guide](https://docs.aws.amazon.com/ram/latest/userguide/). **Note** You can easily open the RAM console by choosing a CA and then choosing **Actions**, **Manage resource shares**. + Programmatically, using the PCA APIs [PutPolicy](https://docs.aws.amazon.com/privateca/latest/APIReference/API_PutPolicy.html), [GetPolicy](https://docs.aws.amazon.com/privateca/latest/APIReference/API_GetPolicy.html), and [DeletePolicy](https://docs.aws.amazon.com/privateca/latest/APIReference/API_DeletePolicy.html). + Manually, using the PCA commands [put-policy](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/put-policy.html), [get-policy](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/get-policy.html), and [delete-policy](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/delete-policy.html) in the AWS CLI. Only the console method requires RAM access. **Cross-account case 1: Issuing a managed certificate from the console** In this case, the CA administrator uses AWS Resource Access Manager (AWS RAM) to share CA access with another AWS account, which allows that account to issue managed ACM certificates. The diagram shows that AWS RAM can share the CA directly with the account, or indirectly through an AWS Organizations ID in which the account is a member. ![\[Cross-account issuance with the console\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/ca_access_2_accounts_console.png) After RAM shares a resource through AWS Organizations, the recipient principal must accept the resource for it to take effect. The recipient can configure AWS Organizations to accept offered shares automatically. **Note** The recipient account is responsible for configuring autorenewal in ACM. Typically, on the first occasion a shared CA is used, ACM installs a service-linked role that permits it to make unattended certificate calls on AWS Private CA. If this fails (usually due to a missing permission), certificates from the CA are not renewed automatically. Only the ACM user can resolve the problem, not the CA administrator. For more information, see [Using a Service Linked Role (SLR) with ACM](https://docs.aws.amazon.com/acm/latest/userguide/acm-slr.html). **Cross-account case 2: Issuing managed and unmanaged certificates using the API or CLI** This second case demonstrates the sharing and issuance options that are possible using the AWS Certificate Manager and AWS Private CA API. All of these operations can also be carried out using the corresponding AWS CLI commands. ![\[Cross-account issuance using the APIs\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/ca_access_2_accounts_api_options.png) Because the API operations are being used directly in this example, the certificate issuer has a choice of two API operations to issue a certificate. The PCA API action `IssueCertificate` results in an unmanaged certificate that will not be automatically renewed and must be exported and manually installed. The ACM API action [RequestCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_RequestCertificate.html) results in a managed certificate that can be easily installed on ACM integrated services and renews automatically. **Note** The recipient account is responsible for configuring auto-renewal in ACM. Typically, on the first occasion a shared CA is used, ACM installs a service-linked role that allows it to make unattended certificate calls on AWS Private CA. If this fails (usually due to a missing permission), certificates from the CA will not renew automatically, and only the ACM user can resolve the problem, not the CA administrator. For more information, see [Using a Service Linked Role (SLR) with ACM](https://docs.aws.amazon.com/acm/latest/userguide/acm-slr.html). # List private CAs You can use the AWS Private CA console or AWS CLI to list private CAs that you own or have access to. **To list available CAs using the console** 1. Sign in to your AWS account and open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home). 1. Review the information in the **Private certificate authorities** list. You can navigate through multiple pages of CAs using the page numbers at upper-right. Each CA occupies a row with some or all of the following columns displayed for each one: + **Subject** – Summary of distinguished name information for the CA. + **Id** – 32-byte hexadecimal unique identifier of the CA. + **Status** – CA status. Possible values are **Creating**, **Pending certificate**, **Active**, **Deleted**, **Disabled**, **Expired**, and **Failed**. + **Type** – The type of CA. Possible values are **Root** and **Subordinate**. + **Mode** – The mode of the CA. Possible values are **General-purpose** (issues certificates that can be configured with any expiration date) and **Short-lived certificate** (issues certificates with a maximum validity period of seven days). A short validity period can substitute in some cases for a revocation mechanism. The default is **General-purpose**. + **Owner** – The AWS account that owns the CA. This may be your account or an account that has delegated CA management permissions to you. + **Key algorithm** – The public key algorithm supported by the CA. Possible values are **ML\$1DSA\$144**, **ML\$1DSA\$165**, **ML\$1DSA\$187**, **RSA\$12048**, **RSA\$13072**, **RSA\$14096**, **EC\$1prime256v1**, **EC\$1secp384r1**, and **EC\$1secp521r1**. + **Signing algorithm** – The algorithm that the CA uses to sign certificate requests. (Not to be confused with the `SigningAlgorithm` parameter used to sign certificates when they are issued.) Possible values are **ML\$1DSA\$144**, **ML\$1DSA\$165**, **ML\$1DSA\$187**, **SHA256WITHRSA**, **SHA384WITHRSA**, **SHA512WITHRSA**, **SHA256WITHECDSA**, **SHA384WITHECDSA**, and **SHA512WITHECDSA**. **Note** You can customize the columns that you want to display, as well as other settings, by choosing the settings icon in the upper-right corner of the console. **To list available CAs using the AWS CLI** Use the [list-certificate-authorities](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/list-certificate-authorities.html) command to list available CAs as shown in the following example: ``` $ aws acm-pca list-certificate-authorities --max-items 10 ``` The command returns information similar to the following: ``` { "CertificateAuthorities":[ { "Arn":"arn:aws:acm-pca:region:account:certificate-authority/CA_ID", "CreatedAt":"2022-05-02T11:59:02.022000-07:00", "LastStateChangeAt":"2022-05-02T11:59:18.498000-07:00", "Type":"ROOT", "Serial":"serial_number", "Status":"ACTIVE", "NotBefore":"2022-05-02T10:59:17-07:00", "NotAfter":"2032-05-02T11:59:17-07:00", "CertificateAuthorityConfiguration":{ "KeyAlgorithm":"RSA_2048", "SigningAlgorithm":"SHA256WITHRSA", "Subject":{ "Organization":"testing_com" } }, "RevocationConfiguration":{ "CrlConfiguration":{ "Enabled":false } } } ... ] } ``` # View a private CA You can use the ACM console or the AWS CLI to view detailed metadata about a private CA and change several of the values as needed. For detailed information about updating CAs, see [Update a private CA in AWS Private Certificate Authority](PCAUpdateCA.md). **To view CA details in the console** 1. Sign in to your AWS account and open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home). 1. Review the **Private certificate authorities** list. You can navigate through multiple pages of CAs using the page numbers at upper-right. 1. To show detailed metadata for a listed CA, choose the radio button by the CA that you want to inspect. This opens a details pane with the following tabbed views: + **Subject** tab– Information about the distinguished name for the CA. For more information, see [Subject distinguished name](create-CA.md#PcaCreateCaName). The fields displayed include: + **Subject** – Summary of provided name information fields + **Organization (O)** – For example, a company name + **Organization Unit (OU)** – For example, a division within a company + **Country name (C)** – A two-letter country code + **State or province name** – Full name of a state or province + **Locality name** – The name of a city + **Common Name (CN)** – A human-readable string to identify the CA. + **CA certificate** tab – Information about the validity of the CA certificate + **Valid until** – The date and time until the CA certificate is valid + **Expires in** – The number of days until expiration + **Revocation configuration** tab – Your current selections for certificate revocation options. Choose **Edit** to update. + **Certificate Revocation List (CRL) distribution** – Status of **Enabled** or **Disabled** + **Online Certificate Status Protocol (OCSP)** – Status of **Enabled** or **Disabled** + **Permissions** tab – Your current selection of certificate renewal permisisons for this CA through AWS Certificate Manager (ACM). Choose **Edit** to update. + **ACM authorization for renewals** – Status of authorized or unauthorized + **Tags** tab – Your current assignment of customizable labels for this CA. Choose the **Manage tags** to update. + **Resource shares** tab – Your current assignment of resource shares for this CA through AWS Resource Access Manager (RAM). Choose **Manage resource shares** to update. + **Name** – Name of the resource share + **Status** – status of the resource share 1. Choose the **ID** field of the CA that you want to inspect to open the **General** pane. The CA's 32-byte hexadecimal unique identifier appears at the top. The pane provides the following additional information: + **Status** – CA status. Possible values are **Creating**, **Pending certificate**, **Active**, **Deleted**, **Disabled**, **Expired**, and **Failed**. + **ARN** – The [Amazon Resource Name](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) for the CA. + **Owner** – The AWS account that owns the CA. This may be your account (**Self**) or an account that has delegated CA management permissions to you. + **CA type** – The type of CA. Possible values are **Root** and **Subordinate**. + **Created at** – The date and time when the CA was created. + **Expiration date** – The date and time when the CA certificate expires. + **Mode** – The mode of the CA. Possible values are **General-purpose **(certificates that can be configured with any expiration date) and **Short-lived certificate** (certificates with a maximum validity period of seven days). A short validity period can substitute in some cases for a revocation mechanism. The default is **General-purpose**. + **Key algorithm** – The public key algorithm supported by the CA. Possible values are **ML-DSA-44**, **ML-DSA-65**, **ML-DSA-87**, **RSA 2048**, **RSA 3072**, **RSA 4096**, **ECDSA P256**, **ECDSA P384**, and **ECDSA P521**. + **Signing algorithm** – The algorithm that the CA uses to sign its own Certificate Signing Request, CRLs, and OCSP responses (Not to be confused with the `SigningAlgorithm` parameter used in the IssueCertificate API.) Possible values are **ML-DSA-44**, **ML-DSA-65**, **ML-DSA-87**, **SHA256 RSA**, **SHA384 RSA**, and **SHA512 RSA**, **SHA256 ECDSA**, **SHA384 ECDSA**, **SHA512 ECDSA** + **Key storage security standard** – Level of Federal Information Processing Standards (FIPS) conformance. You can choose from these values: **FIPS 140-2 level 2 or higher**, **FIPS 140-2 level 3 or higher**, and **CCPC Level 1 or higher**. This parameter varies by AWS Region. **Note** Starting January 26, 2023, AWS Private CA protects all CA private keys in non-China regions using hardware security modules (HSMs) that comply with FIPS PUB 140-2 Level 3. **To view and modify CA details using the AWS CLI** Use the [https://docs.aws.amazon.com/cli/latest/reference/acm-pca/describe-certificate-authority.html](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/describe-certificate-authority.html) command in the AWS CLI to display details about a CA, as shown in the following command: ``` $ aws acm-pca describe-certificate-authority --certificate-authority-arn arn:aws:acm:region:account:certificate-authority/CA_ID ``` The command returns information similar to the following: ``` { "CertificateAuthority":{ "Arn":"arn:aws:acm:region:account:certificate-authority/CA_ID", "CreatedAt":"2022-05-02T11:59:02.022000-07:00", "LastStateChangeAt":"2022-05-02T11:59:18.498000-07:00", "Type":"ROOT", "Serial":"serial_number", "Status":"ACTIVE", "NotBefore":"2022-05-02T10:59:17-07:00", "NotAfter":"2031-05-02T11:59:17-07:00", "CertificateAuthorityConfiguration":{ "KeyAlgorithm":"RSA_2048", "SigningAlgorithm":"SHA256WITHRSA", "Subject":{ "Organization":"testing_com" } }, "RevocationConfiguration":{ "CrlConfiguration":{ "Enabled":false } } } } ``` For information about updating a private CA from the command line, see [Updating a CA (CLI)](PCAUpdateCA.md#ca-update-cli). # Add tags for your private CA Tags are words or phrases that act as metadata for identifying and organizing AWS resources. Each tag consists of a **key** and a **value**. You can use the AWS Private CA console, AWS Command Line Interface (AWS CLI), or the PCA API to add, view, or remove tags for private CAs. You can add or remove custom tags for your private CA at any time. For example, you could tag private CAs with key-value pairs like `Environment=Prod` or `Environment=Beta` to identify which environment the CA is intended for. For more information, see [Create a Private CA](create-CA.md). **Note** To attach tags to a private CA during the creation procedure, a CA administrator must first associate an inline IAM policy with the `CreateCertificateAuthority` action and explicitly allow tagging. For more information, see [Tag-on-create: Attaching tags to a CA at the time of creation](auth-InlinePolicies.md#tag-on-create). Other AWS resources also support tagging. You can assign the same tag to different resources to indicate that those resources are related. For example, you can assign a tag such as `Website=example.com` to your CA, the Elastic Load Balancing load balancer, and other related resources. For more information on tagging AWS resources, see [Tagging your Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the [Amazon EC2 User Guide](https://docs.aws.amazon.com/ec2/index.html#lang/en_us). The following basic restrictions apply to AWS Private CA tags: + The maximum number of tags per private CA is 50. + The maximum length of a tag key is 128 characters. + The maximum length of a tag value is 256 characters. + The tag key and value can contain the following characters: A-Z, a-z, and .:\$1=@\$1%-(hyphen). + Tag keys and values are case-sensitive. + The `aws:` and `rds:` prefixes are reserved for AWS use; you cannot add, edit, or delete tags whose key begins with `aws:` or `rds:`. Default tags that begin with `aws:` and `rds:` do not count against your tags-per-resource quota. + If you plan to use your tagging schema across multiple services and resources, remember that other services might have different restrictions for allowed characters. Refer to the documentation for that service. + AWS Private CA tags are not available for use in the [Resource Groups and Tag Editor](https://aws.amazon.com/blogs/aws/resource-groups-and-tagging/) in the AWS Management Console. You can tag a private CA from the [AWS Private CA Console](https://console.aws.amazon.com/acm-pca), the [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/reference/), or the [AWS Private CA API](https://docs.aws.amazon.com/privateca/latest/APIReference/). **To tag a private CA (console)** 1. Sign in to your AWS account and open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home). 1. On the **Private certificate authorities page**, choose your private CA from the list. 1. In the details area below the list, choose the **Tags** tab. A list of existing tags is displayed. 1. Choose **Manage tags**. 1. Choose **Add new tag**. 1. Type a key and value pair. 1. Choose **Save**. **To tag a private CA (AWS CLI)** Use the [tag-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/tag-certificate-authority.html) command to add tags to your private CA. ``` $ aws acm-pca tag-certificate-authority \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --tags Key=Admin,Value=Alice ``` Use the [list-tags](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/list-tags.html) command to list the tags for a private CA. ``` $ aws acm-pca list-tags \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --max-results 10 ``` Use the [untag-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/untag-certificate-authority.html) command to remove tags from a private CA. ``` $ aws acm-pca untag-certificate-authority \ --certificate-authority-arn arn:aws:acm-pca:aregion:account:certificate-authority/CA_ID \ --tags Key=Purpose,Value=Website ``` # Understand AWS Private CA CA status The status of a CA that is managed by AWS Private CA results from a user action or, in some cases, from a service action. For example, a CA status changes when it expires. The status options available to CA administrators vary depending on the current status of the CA. AWS Private CA can report the following status values. The table shows the CA capabilities available in each state. **Note** For all status values except `DELETED` and `FAILED`, you are billed for the CA. **** | Status | Issue certificates | Validate certs with OCSP | Generate CRLs | Generate audits | You can update the CA cert | Certificates can be revoked | You are billed for the CA | | --- | --- | --- | --- | --- | --- | --- | --- | | CREATING – The CA is being created. | No | No | No | No | No | No | Yes | | `PENDING_CERTIFICATE` – The CA has been created and needs a certificate to be operational.\$1 | No | No | No | No | No | No | Yes | | ACTIVE | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | DISABLED – You have manually disabled the CA. | No | Yes | Yes | Yes | No | Yes | Yes | | EXPIRED – The CA certificate has expired.\$1\$1 | No | No | No | No | Yes | No | Yes | | FAILED | The CreateCertificateAuthority action failed. This can occur because of a network outage, backend AWS failure, or other errors. A failed CA cannot be recovered. Delete the CA and create a new one. | No | | DELETED | Your CA is within the restoration period, which can have a length of 7-30 days. After this period, it is permanently deleted. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/privateca/latest/userguide/PcaUpdateStatus.html) | No | To complete activation, you need to generate a CSR, get a signed CA certificate from a CA, and import the certificate into AWS Private CA. The CSR can be submitted either to your new CA (for self-signing), or to an on-premises root or subordinate CA. For more information, see [Installing the CA certificate](PCACertInstall.md). You cannot directly change the status of an expired CA. If you import a new certificate for the CA, AWS Private CA resets the status to `ACTIVE` unless it was set to `DISABLED` before the certificate expired. **Additional considerations about expired CA certificates:** + CA certificates are not automatically renewed. For information about automating renewal through AWS Certificate Manager, see [Assign certificate renewal permissions to ACM](assign-permissions.md#PcaPermissions). + If you attempt to issue a new certificate with an expired CA, the `IssueCertificate` API returns `InvalidStateException`. An expired root CA must self-sign a new root CA certificate before it can issue new subordinate certificates. + `The ListCertificateAuthorities` and `DescribeCertificateAuthority` APIs return a status of `EXPIRED` if the CA certificate is expired, regardless of whether the CA status is set to `ACTIVE` or `DISABLED`. However, if the expired CA has been set to `DELETED`, the status returned is `DELETED`. + The `UpdateCertificateAuthority` API cannot update the status of an expired CA. + The `RevokeCertificate` API cannot be used to revoke any expired certificate, including a CA certificate. ## Relation between CA status and CA lifecycle The following diagram illustrates the CA lifecycle as an interaction of management actions with CA status. ![\[Interaction of CA management actions and status.\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/status.png) **Diagram key** | | | | | | --- |--- |--- |--- | | ![\[Blue fabric swatch with a repeating pattern of white polka dots.\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/rectangle.png) Management action | ![\[Blue parallelogram shape with angled sides and sharp corners.\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/parallelogram.png)CA status | ![\[Blue arrow pointing to the right, indicating direction or progression.\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/arrow-solid.png) Action results in a state change | ![\[Blue arrow pointing right, composed of five dots increasing in size from left to right.\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/arrow-dotted.png) New state enables new action | At the top of the diagram, management actions are applied through the AWS Private CA console, CLI, or API. The actions take the CA through creation, activation, expiration and renewal. The CA status changes in response (as shown by the solid lines) to manual actions or automated updates. In most cases, a new status leads to a new possible action (shown by a dotted line) that the CA administrator can apply. The lower-right inset shows the possible status values permitting delete and restore actions. **Topics** + [Relation between CA status and CA lifecycle](#status-and-lifecycle) # Update a private CA in AWS Private Certificate Authority You can update the status of a private CA or change its [revocation configuration](revocation-setup.md) after creating it. This topic provides details about CA status and the CA lifecycle, along with examples of console and CLI updates to CAs. ## Update a CA (console) The following procedures show how to update existing CA configurations using the AWS Management Console. ### Update CA status (console) In this example, the status of an enabled CA is changed to disabled. **To update the status of a CA** 1. Sign in to your AWS account and open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home) 1. On the **Private certificate authorities** page, choose a private CA that is currently active from the list. 1. On the **Actions** menu, choose **Disable** to disable the private CA. ### Updating a CA's revocation configuration (console) You can update the [revocation configuration](revocation-setup.md) for your private CA, for example, by adding or removing either OCSP or CRL support, or by modifying their settings. **Note** Changes to the revocation configuration of a CA do not affect certificates that were already issued. For managed revocation to work, older certificates must be re-issued. For OCSP, you change the following settings: + Enable or disable OCSP. + Enable or disable a custom OCSP fully qualified domain name (FQDN). + Change the FQDN. For a CRL, you can change any of the following settings: + The CRL type (complete or partitioned) + Whether the private CA generates a certificate revocation list (CRL) + The number of days before a CRL expires. Note that AWS Private CA begins trying to regenerate the CRL at ½ the number of days you specify. + The name of the Amazon S3 bucket where your CRL is saved. + An alias to hide the name of your Amazon S3 bucket from public view. **Important** Changing any of the preceding parameters can have negative effects. Examples include disabling CRL generation, changing the validity period, or changing the S3 bucket after you have placed your private CA in production. Such changes can break existing certificates that depend on the CRL and the current CRL configuration. Changing the alias can be done safely as long as the old alias remains linked to the correct bucket. **To update the revocation settings** 1. Sign in to your AWS account and open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home). 1. On the **Private certificate authorities** page, choose a private CA from the list. This opens the details panel for the CA. 1. Choose the **Revocation configuration** tab, then choose **Edit**. 1. Under **Certificate revocation options**, two options are displayed: + **Activate CRL distribution** + **Turn on OCSP** You can configure either, neither, or both of these revocation mechanisms for your CA. Although optional, managed revocation is recommended as a [best practice](ca-best-practices.md). Before completing this step, see [Plan your AWS Private CA certificate revocation method](revocation-setup.md) for information about the advantages of each method, the preliminary setup that may be required, and additional revocation features. #### To configure a CRL 1. Select **Activate CRL distribution**. 1. To create an Amazon S3 bucket for your CRL entries, select **Create a new S3 bucket**. Provide a unique bucket name. (You do not need to include the path to the bucket.) Otherwise, leave this option unselected and choose an existing bucket from the **S3 bucket name** list. If you create a new bucket, AWS Private CA creates and attaches the [required access policy](crl-planning.md#s3-policies) to it. If you decide to use an existing bucket, you must attach an access policy it before you can begin generating CRLs. Use one of the policy patterns described in [Access policies for CRLs in Amazon S3](crl-planning.md#s3-policies). For information about attaching a policy, see [Adding a bucket policy by using the Amazon S3 console](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html). **Note** When you are using the AWS Private CA console, an attempt to create a CA fails if both of the following conditions apply: You are enforcing Block Public Access settings on your Amazon S3 bucket or account. You asked AWS Private CA to create an Amazon S3 bucket automatically. In this situation, the console attempts, by default, to create a publicly accessible bucket, and Amazon S3 rejects this action. Check your Amazon S3 settings if this occurs. For more information, see [Blocking public access to your Amazon S3 storage](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html). 1. Expand **Advanced** for additional configuration options. + Choose **Enable partitioning** to enable partitioning of CRLs. If you don't enable partitioning, your CA is subject to the maximum number of revoked certificates, shown on the [AWS Private Certificate Authority quotas](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca). For more information about partitioned CRLs, see [CRL types](crl-planning.md#crl-type). + Add a **Custom CRL Name** to create an alias for your Amazon S3 bucket. This name is contained in certificates issued by the CA in the “CRL Distribution Points" extension that is defined by RFC 5280. To use CRLs over IPv6, set this to your bucket's dualstack S3 endpoint as described in [Using CRLs over IPv6](crl-planning.md#crl-ipv6). + Add a **Custom path** to create a DNS alias for the file path in your Amazon S3 bucket. + Type the **Validity in days ** your CRL will remain valid. The default value is 7 days. For online CRLs, a validity period of 2-7 days is common. AWS Private CA tries to regenerate the CRL at the midpoint of the specified period. 1. Choose **Save changes** when done. #### To configure OCSP 1. On the** Certificate revocation** page, choose **Turn on OCSP**. 1. (Optional) In the **Custom OCSP endpoint** field, provide a fully qualified domain name (FQDN) for your OCSP endpoint. To use OCSP over IPv6, set this field to a dualstack endpoint as described in [Using OCSP over IPv6](ocsp-customize.md#ocsp-ipv6). When you provide an FQDN in this field, AWS Private CA inserts the FQDN into the *Authority Information Access* extension of each issued certificate in place of the default URL for the AWS OCSP responder. When an endpoint receives a certificate containing the custom FQDN, it queries that address for an OCSP response. For this mechanism to work, you need to take two additional actions: + Use a proxy server to forward traffic that arrives at your custom FQDN to the AWS OCSP responder. + Add a corresponding CNAME record to your DNS database. **Tip** For more information about implementing a complete OCSP solution using a custom CNAME, see [Customize OCSP URL for AWS Private CA](ocsp-customize.md). For example, here is a CNAME record for customized OCSP as it would appear in Amazon Route 53. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/privateca/latest/userguide/PCAUpdateCA.html) **Note** The value of the CNAME must not include a protocol prefix such as "http://" or "https://". 1. Choose **Save changes** when done. ## Updating a CA (CLI) The following procedures show how to update the status and [revocation configuration](revocation-setup.md) of an existing CA using the AWS CLI. **Note** Changes to the revocation configuration of a CA do not affect certificates that were already issued. For managed revocation to work, older certificates must be re-issued. **To update the status of your private CA (AWS CLI)** Use the [update-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/update-certificate-authority.html) command. This is useful when you have an existing CA with status `DISABLED` that you want to set to `ACTIVE`. To begin, confirm the initial status of the CA with the following command. ``` $ aws acm-pca describe-certificate-authority \ --certificate-authority-arn "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" \ --output json ``` This results in output similar to the following. ``` { "CertificateAuthority": { "Arn": "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566", "CreatedAt": "2021-03-05T14:24:12.867000-08:00", "LastStateChangeAt": "2021-03-08T13:17:40.221000-08:00", "Type": "ROOT", "Serial": "serial_number", "Status": "DISABLED", "NotBefore": "2021-03-08T07:46:27-08:00", "NotAfter": "2022-03-08T08:46:27-08:00", "CertificateAuthorityConfiguration": { "KeyAlgorithm": "RSA_2048", "SigningAlgorithm": "SHA256WITHRSA", "Subject": { "Country": "US", "Organization": "Example Corp", "OrganizationalUnit": "Sales", "State": "WA", "CommonName": "www.example.com", "Locality": "Seattle" } }, "RevocationConfiguration": { "CrlConfiguration": { "Enabled": true, "ExpirationInDays": 7, "CustomCname": "alternative.example.com", "S3BucketName": "amzn-s3-demo-bucket" }, "OcspConfiguration": { "Enabled": false } } } } ``` The following command sets the status of the private CA to `ACTIVE`. This is possible only if a valid certificate is installed on the CA. ``` $ aws acm-pca update-certificate-authority \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566 \ --status "ACTIVE" ``` Inspect the new status of the CA. ``` $ aws acm-pca describe-certificate-authority \ --certificate-authority-arn "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566" \ --output json ``` The status now appears as `ACTIVE`. ``` { "CertificateAuthority": { "Arn": "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566", "CreatedAt": "2021-03-05T14:24:12.867000-08:00", "LastStateChangeAt": "2021-03-08T13:23:09.352000-08:00", "Type": "ROOT", "Serial": "serial_number", "Status": "ACTIVE", "NotBefore": "2021-03-08T07:46:27-08:00", "NotAfter": "2022-03-08T08:46:27-08:00", "CertificateAuthorityConfiguration": { "KeyAlgorithm": "RSA_2048", "SigningAlgorithm": "SHA256WITHRSA", "Subject": { "Country": "US", "Organization": "Example Corp", "OrganizationalUnit": "Sales", "State": "WA", "CommonName": "www.example.com", "Locality": "Seattle" } }, "RevocationConfiguration": { "CrlConfiguration": { "Enabled": true, "ExpirationInDays": 7, "CustomCname": "alternative.example.com", "S3BucketName": "amzn-s3-demo-bucket" }, "OcspConfiguration": { "Enabled": false } } } } ``` In some cases, you might have an active CA with no revocation mechanism configured. If you want to begin using a certificate revocation list (CRL), use the following procedure. **To add a CRL to an existing CA (AWS CLI)** 1. Use the following command to inspect the current status of the CA. ``` $ aws acm-pca describe-certificate-authority --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566 --output json ``` The output confirms that the CA has status `ACTIVE` but is not configured to use a CRL. ``` { "CertificateAuthority": { "Arn": "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566", "CreatedAt": "2021-03-08T14:36:26.449000-08:00", "LastStateChangeAt": "2021-03-08T14:50:52.224000-08:00", "Type": "ROOT", "Serial": "serial_number", "Status": "ACTIVE", "NotBefore": "2021-03-08T13:46:50-08:00", "NotAfter": "2022-03-08T14:46:50-08:00", "CertificateAuthorityConfiguration": { "KeyAlgorithm": "RSA_2048", "SigningAlgorithm": "SHA256WITHRSA", "Subject": { "Country": "US", "Organization": "Example Corp", "OrganizationalUnit": "Sales", "State": "WA", "CommonName": "www.example.com", "Locality": "Seattle" } }, "RevocationConfiguration": { "CrlConfiguration": { "Enabled": false }, "OcspConfiguration": { "Enabled": false } } } } ``` 1. Create and save a file with a name such as `revoke_config.txt` to define your CRL configuration parameters. ``` { "CrlConfiguration":{ "Enabled": true, "ExpirationInDays": 7, "S3BucketName": "amzn-s3-demo-bucket" } } ``` **Note** When updating a Matter device attestation CA to enable CRLs, you must configure it to omit the CDP extension from the issued certificates to help conform to the current Matter standard. To do this, define your CRL configuration parameters as illustrated below: ``` { "CrlConfiguration":{ "Enabled": true, "ExpirationInDays": 7, "S3BucketName": "amzn-s3-demo-bucket" "CrlDistributionPointExtensionConfiguration":{ "OmitExtension": true } } } ``` 1. Use the [update-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/update-certificate-authority.html) command and the revocation configuration file to update the CA. ``` $ aws acm-pca update-certificate-authority \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566 \ --revocation-configuration file://revoke_config.txt ``` 1. Again inspect the status of the CA. ``` $ aws acm-pca describe-certificate-authority --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566 --output json ``` The output confirms that CA is now configured to use a CRL. ``` { "CertificateAuthority": { "Arn": "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566", "CreatedAt": "2021-03-08T14:36:26.449000-08:00", "LastStateChangeAt": "2021-03-08T14:50:52.224000-08:00", "Type": "ROOT", "Serial": "serial_number", "Status": "ACTIVE", "NotBefore": "2021-03-08T13:46:50-08:00", "NotAfter": "2022-03-08T14:46:50-08:00", "CertificateAuthorityConfiguration": { "KeyAlgorithm": "RSA_2048", "SigningAlgorithm": "SHA256WITHRSA", "Subject": { "Country": "US", "Organization": "Example Corp", "OrganizationalUnit": "Sales", "State": "WA", "CommonName": "www.example.com", "Locality": "Seattle" } }, "RevocationConfiguration": { "CrlConfiguration": { "Enabled": true, "ExpirationInDays": 7, "S3BucketName": "amzn-s3-demo-bucket", }, "OcspConfiguration": { "Enabled": false } } } } ``` In some cases, you might want to add OCSP revocation support instead of enabling a CRL as in the previous procedure. In that case, use the following steps. **To add OCSP support to an existing CA (AWS CLI)** 1. Create and save a file with a name such as `revoke_config.txt` to define your OCSP parameters. ``` { "OcspConfiguration":{ "Enabled":true } } ``` 1. Use the [update-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/update-certificate-authority.html) command and the revocation configuration file to update the CA. ``` $ aws acm-pca update-certificate-authority \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566 \ --revocation-configuration file://revoke_config.txt ``` 1. Again inspect the status of the CA. ``` $ aws acm-pca describe-certificate-authority --certificate-authority-arnarn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566 --output json ``` The output confirms that CA is now configured to use OCSP. ``` { "CertificateAuthority": { "Arn": "arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566", "CreatedAt": "2021-03-08T14:36:26.449000-08:00", "LastStateChangeAt": "2021-03-08T14:50:52.224000-08:00", "Type": "ROOT", "Serial": "serial_number", "Status": "ACTIVE", "NotBefore": "2021-03-08T13:46:50-08:00", "NotAfter": "2022-03-08T14:46:50-08:00", "CertificateAuthorityConfiguration": { "KeyAlgorithm": "RSA_2048", "SigningAlgorithm": "SHA256WITHRSA", "Subject": { "Country": "US", "Organization": "Example Corp", "OrganizationalUnit": "Sales", "State": "WA", "CommonName": "www.example.com", "Locality": "Seattle" } }, "RevocationConfiguration": { "CrlConfiguration": { "Enabled": false }, "OcspConfiguration": { "Enabled": true } } } } ``` **Note** You can also configure both CRL and OCSP support on a CA. # Delete your private CA You can delete a private CA from the AWS Management Console or AWS CLI permanently. You might want to delete one, for example, to replace it with a new CA that has a new private key. In order to delete a CA safely, follow these steps: 1. Create the replacement CA. 1. Once the new private CA is in production, disable the old one but do not immediately delete it. 1. Keep the old CA disabled until all of the certificates issued by it have expired. 1. Delete the old CA. AWS Private CA does not check that all of the issued certificates have expired before it processes a delete request. You can generate an [audit report](PcaAuditReport.md) to determine which certificates have expired. While the CA is disabled, you can revoke certificates, but you cannot issue new ones. If you must delete a private CA before all the certificates it has issued have expired, we recommend that you also revoke the CA certificate. The CA certificate will be listed in the CRL of the parent CA, and the private CA will be untrusted by clients. **Important** A private CA can be deleted if it is in the `PENDING_CERTIFICATE`, `CREATING`, `EXPIRED`, `DISABLED`, or `FAILED` state. In order to delete a CA in the `ACTIVE` state, you must first disable it, or else the delete request results in an exception. If you are deleting a private CA in the `PENDING_CERTIFICATE` or `DISABLED` state, you can set the length of its restoration period from 7-30 days, with 30 being the default. During this period, status is set to `DELETED` and the CA is restorable. A private CA that is deleted while in the `CREATING` or `FAILED` state has no assigned restoration period and cannot be restored. For more information, see [Restore a private CA](PCARestoreCA.md). You are not charged for a private CA after it has been deleted. However, if a deleted CA is restored, you are charged for the time between deletion and restoration. For more information, see [Pricing for AWS Private Certificate Authority](PcaWelcome.md#PcaPricing). **To delete a private CA (console)** 1. Sign in to your AWS account and open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home). 1. On the **Private certificate authorities** page, choose your private CA from the list. 1. If your CA is in the `ACTIVE` state, you must first disable it. On the **Actions** menu, choose **Disable**. When prompted, choose **I understand the risk, continue**. 1. For a CA that is not in the `ACTIVE` state, choose **Actions**, **Delete**. 1. If your CA is in the `DISABLED`, `EXPIRED`, or `PENDING_CERTIFICATE` state, the **Delete CA** page lets you specify a restoration period of 7-30 days. If your private CA is not in one of these states, it cannot be restored later and deletion is permanent. 1. Choose **Delete**. 1. If you are certain that you want to delete the private CA, choose **Permanently delete** when prompted. The status of the private CA changes to `DELETED`. However, you can restore the private CA before the end of the restoration period. To check the restoration period of a private CA in the `DELETED` state, call the [DescribeCerticateAuthority](https://docs.aws.amazon.com/privateca/latest/APIReference/API_DescribeCertificateAuthority.html) or [ListCertificateAuthorities](https://docs.aws.amazon.com/privateca/latest/APIReference/API_ListCertificateAuthorities.html) API operation. **To delete a private CA (AWS CLI)** Use the [delete-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/delete-certificate-authority.html) command to delete a private CA. ``` $ aws acm-pca delete-certificate-authority \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --permanent-deletion-time-in-days 16 ``` # Restore a private CA You can restore a private CA that has been deleted as long as the CA remains within the restoration period that you specified upon deletion. The restoration period is from 7-30 days. At the end of that period, the private CA is permanently deleted. For more information, see [Delete your private CA](PCADeleteCA.md). You cannot restore a private CA that has been permanently deleted. **Note** You are not charged for a private CA after it has been deleted. However, if a deleted CA is restored, you are charged for the time between deletion and restoration. For more information, see [Pricing for AWS Private Certificate Authority](PcaWelcome.md#PcaPricing). ## Restoring a private CA (console) You can use the AWS Management Console to restore a private CA. **To restore a private CA (console)** 1. Sign in to your AWS account and open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home). 1. On the **Private certificate authorities** page, choose your deleted private CA from the list. 1. On the **Actions** menu, choose **Restore**. 1. On the **Restore CA** page, choose **Restore** again. 1. If successful, the status of the private CA is set to its pre-deletion state. Choose **Actions**, **Enable**, and **Enable** again to change its status to `ACTIVE`. If the private CA was in the `PENDING_CERTIFICATE` state at the time of deletion, you must import a CA certificate into the private CA before you can activate it. ## Restore a private CA (AWS CLI) Use the [restore-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/restore-certificate-authority.html) command to restore a deleted private CA that is in the `DELETED` state. The following steps discuss the entire process required to delete, restore, and then reactivate a private CA. **To delete, restore, and reactivate a private CA (AWS CLI)** 1. Delete the private CA. Run the [delete-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/delete-certificate-authority.html) command to delete the private CA. If the private CA's status is `DISABLED` or `PENDING_CERTIFICATE`, you can set the `--permanent-deletion-time-in-days` parameter to specify the private CA's restoration period from 7 -30 days. If you do not specify a restoration period, the default is 30 days. If successful, this command sets the status of the private CA to `DELETED`. **Note** To be restorable, the private CA's status at the time of deletion must be `DISABLED` or `PENDING_CERTIFICATE`. ``` $ aws acm-pca delete-certificate-authority \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --permanent-deletion-time-in-days 16 ``` 1. Restore the private CA. Run the [restore-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/restore-certificate-authority.html) command to restore the private CA. You must run the command before the restoration period that you set with the **delete-certificate-authority** command expires. If successful, the command sets the status of the private CA to its pre-deletion status. ``` $ aws acm-pca restore-certificate-authority \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID ``` 1. Make the private CA `ACTIVE`. Run the [update-certificate-authority](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/update-certificate-authority.html) command to change the status of the private CA to `ACTIVE`. ``` $ aws acm-pca update-certificate-authority \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --status ACTIVE ``` # Use externally signed private CA certificates If your private CA hierarchy's root of trust must be a CA outside of AWS Private CA, you can create and self-sign your own root CA. Alternatively, you can obtain a private CA certificate that is signed by an external private CA operated by your organization. Whatever its source, you can use this externally obtained CA to sign a private subordinate CA certificate that AWS Private CA manages. **Note** Procedures for creating or obtaining an external trust services provider are outside the scope of this guide. Using an external parent CA with AWS Private CA permits you to enforce CA name constraints as defined in the [Name Constraints](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10) section of RFC 5280. Name constraints provide a way for CA administrators to restrict subject names in certificates. If you plan to sign a private subordinate CA certificate with an external CA, there are three tasks to complete before you have a working CA in AWS Private CA: 1. Generate a certificate signing request (CSR). 1. Submit the CSR to your external signing authority and return with a signed certificate and certificate chain. 1. Install a signed certificate in AWS Private CA. The following procedures describe how to complete these tasks using either the AWS Management Console or the AWS CLI. **To obtain and install an externally signed CA certificate (console)** 1. (Optional) If you are not already on the CA's details page, open the AWS Private CA console at [https://console.aws.amazon.com/acm-pca/home](https://console.aws.amazon.com/acm-pca/home). On the **Private certificate authorities** page, choose a subordinate CA with status **Pending certificate**, **Active**, **Disabled**, or **Expired**. 1. Choose **Actions**, **Install CA Certificate** to open the **Install subordinate CA certificate** page. 1. On the **Install subordinate CA certificate** page, under **Select CA type**, choose **External private CA**. 1. Under **CSR for this CA**, the console displays the Base64-encoded ASCII text of the CSR. You can copy the text using the **Copy** button or you can choose **Export CSR to a file** and save it locally. **Note** The exact format of the CSR text must be preserved when copying and pasting. 1. If you cannot immediately perform the offline steps to obtain a signed certificate from your external signing authority, you can close the page and return to it once you possess a signed certificate and a certificate chain. Otherwise, if you are ready, do either of the following: + Paste the Base64-encoded ASCII text of your certificate body and of your certificate chain into their respective text boxes. + Choose **Upload** to load the certificate body and certificate chain from local files into their respective text boxes. 1. Choose **Confirm and install**. **To obtain and install an externally signed CA certificate (CLI)** 1. Use the [get-certificate-authority-csr](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/get-certificate-authority-csr.html) command to retrieve the certificate signing request (CSR) for your private CA. If you want to send the CSR to your display, use the `--output text` option to eliminate CR/LF characters from the end of each line. To send the CSR to a file, use the redirect option (>) followed by a file name. ``` $ aws acm-pca get-certificate-authority-csr \ --certificate-authority-arn arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/11223344-1234-1122-2233-112233445566 \ --output text ``` After saving a CSR as a local file, you can inspect it by using the following [OpenSSL](https://www.openssl.org/) command: ``` openssl req -in path_to_CSR_file -text -noout ``` This command generates output similar to the following. Notice that the **CA** extension is `TRUE`, indicating that the CSR is for a CA certificate. ``` Certificate Request: Data: Version: 0 (0x0) Subject: O=ExampleCompany, OU=Corporate Office, CN=Example CA 1 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d4:23:51:b3:dd:01:09:01:0b:4c:59:e4:ea:81: 1d:7f:48:36:ef:2a:e9:45:82:ec:95:1d:c6:d7:c9: 7f:19:06:73:c5:cd:63:43:14:eb:c8:03:82:f8:7b: c7:89:e6:8d:03:eb:b6:76:58:70:f2:cb:c3:4c:67: ea:50:fd:b9:17:84:b8:60:2c:64:9d:2e:d5:7d:da: 46:56:38:34:a9:0d:57:77:85:f1:6f:b8:ce:73:eb: f7:62:a7:8e:e6:35:f5:df:0c:f7:3b:f5:7f:bd:f4: 38:0b:95:50:2c:be:7d:bf:d9:ad:91:c3:81:29:23: b2:5e:a6:83:79:53:f3:06:12:20:7e:a8:fa:18:d6: a8:f3:a3:89:a5:a3:6a:76:da:d0:97:e5:13:bc:84: a6:5c:d6:54:1a:f0:80:16:dd:4e:79:7b:ff:6d:39: b5:67:56:cb:02:6b:14:c3:17:06:0e:7d:fb:d2:7e: 1c:b8:7d:1d:83:13:59:b2:76:75:5e:d1:e3:23:6d: 8a:5e:f5:85:ca:d7:e9:a3:f1:9b:42:9f:ed:8a:3c: 14:4d:1f:fc:95:2b:51:6c:de:8f:ee:02:8c:0c:b6: 3e:2d:68:e5:f8:86:3f:4f:52:ec:a6:f0:01:c4:7d: 68:f3:09:ae:b9:97:d6:fc:e4:de:58:58:37:09:9a: f6:27 Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha256WithRSAEncryption c5:64:0e:6c:cf:11:03:0b:b7:b8:9e:48:e1:04:45:a0:7f:cc: a7:fd:e9:4d:c9:00:26:c5:6e:d0:7e:69:7a:fb:17:1f:f3:5d: ac:f3:65:0a:96:5a:47:3c:c1:ee:45:84:46:e3:e6:05:73:0c: ce:c9:a0:5e:af:55:bb:89:46:21:92:7b:10:96:92:1b:e6:75: de:02:13:2d:98:72:47:bd:b1:13:1a:3d:bb:71:ae:62:86:1a: ee:ae:4e:f4:29:2e:d6:fc:70:06:ac:ca:cf:bb:ee:63:68:14: 8e:b2:8f:e3:8d:e8:8f:e0:33:74:d6:cf:e2:e9:41:ad:b6:47: f8:2e:7d:0a:82:af:c6:d8:53:c2:88:a0:32:05:09:e0:04:8f: 79:1c:ac:0d:d4:77:8e:a6:b2:5f:07:f8:1b:e3:98:d4:12:3d: 28:32:82:b5:50:92:a4:b2:4c:28:fc:d2:73:75:75:ff:10:33: 2c:c0:67:4b:de:fd:e6:69:1c:a8:bb:e8:31:93:07:35:69:b7: d6:53:37:53:d5:07:dd:54:35:74:50:50:f9:99:7d:38:b7:b6: 7f:bd:6c:b8:e4:2a:38:e5:04:00:a8:a3:d9:e5:06:38:e0:38: 4c:ca:a9:3c:37:6d:ba:58:38:11:9c:30:08:93:a5:62:00:18: d1:83:66:40 ``` 1. Submit the CSR to your external signing authority and obtain files containing the Base64 PEM-encoded signed certificate and certificate chain. 1. Use the [import-certificate-authority-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm-pca/import-certificate-authority-certificate.html) command to import the private CA certificate file and the chain file into AWS Private CA. ``` $ aws acm-pca import-certificate-authority-certificate \ --certificate-authority-arn arn:aws:acm-pca:region:account:\ certificate-authority/12345678-1234-1234-1234-123456789012 \ --certificate file://C:\example_ca_cert.pem \ --certificate-chain file://C:\example_ca_cert_chain.pem ```