# 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).