# Plan your AWS Private CA certificate revocation method
As you plan your private PKI with AWS Private CA, you should consider how to handle situations where you no longer wish endpoints to trust an issued certificate, such as when the private key of an endpoint is exposed. The common approaches to this problem are to use short-lived certificates or to configure certificate revocation. Short-lived certificates expire in such a short period of time, in hours or days, that revocation makes no sense, with the certificate becoming invalid in about the same time it takes to notify an endpoint of revocation. This section describes the revocation options for AWS Private CA customers, including configuration and best practices.
Customers looking for a revocation method can choose Online Certificate Status Protocol (OCSP), certificate revocation lists (CRLs), or both.
**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).
+ **Online Certificate Status Protocol (OCSP)**
AWS Private CA provides a fully managed OCSP solution to notify endpoints that certificates have been revoked without the need for customers to operate infrastructure themselves. Customers can enable OCSP on new or existing CAs with a single operation using the AWS Private CA console, the API, the CLI, or through CloudFormation. Whereas CRLs are stored and processed on the endpoint and can become stale, OCSP storage and processing requirements are handled synchronously on the responder backend.
When you enable OCSP for a CA, AWS Private CA includes the URL of the OCSP responder in the *Authority Information Access* (AIA) extension of each new certificate issued. The extension allows clients such as web browsers to query the responder and determine whether an end-entity or subordinate CA certificate can be trusted. The responder returns a status message that is cryptographically signed to assure its authenticity.
The AWS Private CA OCSP responder is compliant with [RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019).
**OCSP considerations**
+ OCSP status messages are signed using the same signing algorithm that the issuing CA was configured to use. CAs created in the AWS Private CA console use the SHA256WITHRSA signature algorithm by default. Other supported algorithms can be found in the [CertificateAuthorityConfiguration](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CertificateAuthorityConfiguration.html) API documentation.
+ [APIPassthrough and CSRPassthrough](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html#template-varieties) certificate templates will not work with the AIA extension if the OCSP responder is enabled.
+ The endpoint of the managed OCSP service is accessible on the public internet. Customers who want OCSP but prefer not to have a public endpoint will need to operate their own OCSP infrastructure.
+ **Certificate Revocation Lists (CRLs)**
A certificate revocation list (CRL) is a file that contains a list of certificates revoked before their scheduled expiration date. The CRL contains a list of certificates that should no longer be trusted, the reason for revocation, and other relevant information.
When you configure your certificate authority (CA), you can choose whether AWS Private CA creates a complete or partitioned CRL. Your choice determines the maximum number of certificates that the certificate authority can issue and revoke. For more information, see [AWS Private CA quotas](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca).
**CRL considerations**
+ Memory and bandwidth considerations: CRLs require more memory than OCSP due to local download and processing requirements. However, CRLs might reduce network bandwidth compared to OCSP by caching revocation lists instead of checking status per connection. For memory-constrained devices, such as certain IoT devices, consider using partitioned CRLs.
+ Changing the CRL type: When changing from a complete to partitioned CRL, AWS Private CA creates new partitions as needed and adds the IDP extension to all CRLs, including the original. Changing from partitioned to complete updates only a single CRL and prevents future revocation of certificates associated with previous partitions.
**Note**
Both OCSP and CRLs exhibit some delay between revocation and the availability of the status change.
OCSP responses may take up to 60 minutes to reflect the new status when you revoke a certificate. In general, OCSP tends to support faster distribution of revocation information because, unlike CRLs which can be cached by clients for days, OCSP responses are typically not cached by clients.
A CRL is typically updated approximately 30 minutes after a certificate is revoked. If for any reason a CRL update fails, AWS Private CA makes further attempts every 15 minutes.
## General requirements for revocation configurations
The following requirements apply to all revocation configurations.
+ A configuration disabling CRLs or OCSP must contain only the `Enabled=False` parameter, and will fail if other parameters such as `CustomCname` or `ExpirationInDays` are included.
+ In a CRL configuration, the `S3BucketName` parameter must conform to [Amazon Simple Storage Service bucket naming rules](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html).
+ A configuration containing a custom Canonical Name (CNAME) parameter for CRLs or OCSP must conform to [RFC7230](https://www.ietf.org/rfc/rfc7230.txt) restrictions on the use of special characters in a CNAME.
+ In a CRL or OCSP configuration, the value of a CNAME parameter must not include a protocol prefix such as "http://" or "https://".
**Topics**
+ [
## General requirements for revocation configurations
](#revocation-requirements)
+ [
# Set up a CRL for AWS Private CA
](crl-planning.md)
+ [
# Customize OCSP URL for AWS Private CA
](ocsp-customize.md)
# Set up a CRL for AWS Private CA
Before you can configure a certificate revocation list (CRL) as part of the [CA creation process](create-CA.md), some prior setup may be necessary. This section explains the prerequisites and options that you should understand before creating a CA with a CRL attached.
For information about using Online Certificate Status Protocol (OCSP) as an alternative or a supplement to a CRL, see [](create-CA.md#PcaCreateRevocation) and [Customize OCSP URL for AWS Private CA](ocsp-customize.md).
**Topics**
+ [
## CRL types
](#crl-type)
+ [
## CRL structure
](#crl-structure)
+ [
## Access policies for CRLs in Amazon S3
](#s3-policies)
+ [
## Enable S3 Block Public Access (BPA) with CloudFront
](#s3-bpa)
+ [
## Determining the CRL Distribution Point (CDP) URI
](#crl-url)
+ [
##
](#crl-ipv6)
## CRL types
+ **Complete** - The default setting. AWS Private CA maintains a single, unpartitioned CRL file for all unexpired certificates issued by a CA that have been revoked. Each certificate that AWS Private CA issues is bound to a specific CRL through its CRL distribution point (CDP) extension, as defined in [ RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9). You can have up to 1 million private certificates for each CA with complete CRL enabled. For more information, see the [AWS Private CA quotas](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca).
+ **Partitioned** - Compared to complete CRLs, partitioned CRLs dramatically increase the number of certificates your private CA can issue, and saves you from frequently rotating your CAs.
**Important**
When using partitioned CRLs, you must validate that the CRL's associated issuing distribution point (IDP) URI matches the certificate's CDP URI to ensure the right CRL has been fetched. AWS Private CA marks the IDP extension as critical, which your client must be able to process.
## CRL structure
Each CRL is a DER encoded file. To download the file and use [OpenSSL](https://www.openssl.org/) to view it, use a command similar to the following:
```
openssl crl -inform DER -in path-to-crl-file -text -noout
```
CRLs have the following format:
```
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=US/ST=WA/L=Seattle/O=Example Company CA/OU=Corporate/CN=www.example.com
Last Update: Feb 26 19:28:25 2018 GMT
Next Update: Feb 26 20:28:25 2019 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:AA:6E:C1:8A:EC:2F:8F:21:BC:BE:80:3D:C5:65:93:79:99:E7:71:65
X509v3 CRL Number:
1519676905984
Revoked Certificates:
Serial Number: E8CBD2BEDB122329F97706BCFEC990F8
Revocation Date: Feb 26 20:00:36 2018 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Serial Number: F7D7A3FD88B82C6776483467BBF0B38C
Revocation Date: Jan 30 21:21:31 2018 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Signature Algorithm: sha256WithRSAEncryption
82:9a:40:76:86:a5:f5:4e:1e:43:e2:ea:83:ac:89:07:49:bf:
c2:fd:45:7d:15:d0:76:fe:64:ce:7b:3d:bb:4c:a0:6c:4b:4f:
9e:1d:27:f8:69:5e:d1:93:5b:95:da:78:50:6d:a8:59:bb:6f:
49:9b:04:fa:38:f2:fc:4c:0d:97:ac:02:51:26:7d:3e:fe:a6:
c6:83:34:b4:84:0b:5d:b1:c4:25:2f:66:0a:2e:30:f6:52:88:
e8:d2:05:78:84:09:01:e8:9d:c2:9e:b5:83:bd:8a:3a:e4:94:
62:ed:92:e0:be:ea:d2:59:5b:c7:c3:61:35:dc:a9:98:9d:80:
1c:2a:f7:23:9b:fe:ad:6f:16:7e:22:09:9a:79:8f:44:69:89:
2a:78:ae:92:a4:32:46:8d:76:ee:68:25:63:5c:bd:41:a5:5a:
57:18:d7:71:35:85:5c:cd:20:28:c6:d5:59:88:47:c9:36:44:
53:55:28:4d:6b:f8:6a:00:eb:b4:62:de:15:56:c8:9c:45:d7:
83:83:07:21:84:b4:eb:0b:23:f2:61:dd:95:03:02:df:0d:0f:
97:32:e0:9d:38:de:7c:15:e4:36:66:7a:18:da:ce:a3:34:94:
58:a6:5d:5c:04:90:35:f1:8b:55:a9:3c:dd:72:a2:d7:5f:73:
5a:2c:88:85
```
**Note**
The CRL will only be deposited in Amazon S3 after a certificate has been issued that refers to it. Prior to that, there will only be an `acm-pca-permission-test-key` file visible in the Amazon S3 bucket.
## Access policies for CRLs in Amazon S3
If you plan to create a CRL, you need to prepare an Amazon S3 bucket to store it in. AWS Private CA automatically deposits the CRL in the Amazon S3 bucket you designate and updates it periodically. For more information, see [Creating a bucket.](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html)
Your S3 bucket must be secured by an attached IAM permissions policy. Authorized users and service principals require `Put` permission to allow AWS Private CA to place objects in the bucket, and `Get` permission to retrieve them.
**Note**
The IAM policy configuration depends on the AWS Regions involved. Regions fall into two categories:
**Default-enabled Regions** – Regions that are *enabled* by default for all AWS accounts.
**Default-disabled Regions** – Regions that are *disabled* by default, but may be manually enabled by the customer.
For more information and a list of the default-disabled Regions, see [Managing AWS Regions](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html). For a discussion of service principals in the context of IAM, see [AWS service principals in opt-in Regions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services-in-opt-in-regions).
When you configure CRLs as the certificate revocation method, AWS Private CA creates a CRL and publishes it to an S3 bucket. The S3 bucket requires an IAM policy that allows the AWS Private CA service principal to write to the bucket. The name of the service principal varies according to the Regions used, and not all possibilities are supported.
****
| PCA | S3 | Service principal |
| --- | --- | --- |
| Both in same Region | `acm-pca.amazonaws.com` |
| Enabled | Enabled | `acm-pca.amazonaws.com` |
| Disabled | Enabled | `acm-pca.Region.amazonaws.com` |
| Enabled | Disabled | Not supported |
The default policy applies no `SourceArn` restriction on the CA. We recommend that you apply a less permissive policy such as the following, which restricts access to both a specific AWS account and a specific private CA. Alternatively, you can use the [aws:SourceOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid) condition key to constrain access to a specific organization in AWS Organizations. For more information about bucket policies, see [Bucket policies for Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html).
If you choose to allow the default policy, you can always [modify](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) it later.
## Enable S3 Block Public Access (BPA) with CloudFront
New Amazon S3 buckets are configured by default with the Block Public Access (BPA) feature activated. Included in the Amazon S3 [security best practices](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html), BPA is a set of access controls that customers can use to fine-tune access to objects in their S3 buckets and to the buckets as a whole. When BPA is active and correctly configured, only authorized and authenticated AWS users have access to a bucket and its contents.
AWS recommends the use of BPA on all S3 buckets to avoid exposure of sensitive information to potential adversaries. However, additional planning is required if your PKI clients retrieve CRLs across the public internet (that is, while not logged into an AWS account). This section describes how to configure a private PKI solution using Amazon CloudFront, a content delivery network (CDN), to serve CRLs without requiring authenticated client access to an S3 bucket.
**Note**
Using CloudFront incurs additional costs on your AWS account. For more information, see [Amazon CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing/).
If you choose to store your CRL in an S3 bucket with BPA enabled, and you do not use CloudFront, you must build another CDN solution to ensure that your PKI client has access to your CRL.
### Set up CloudFront for BPA
Create a CloudFront distribution that will have access to your private S3 bucket, and can serve CRLs to unauthenticated clients.
**To configure a CloudFront distribution for the CRL**
1. Create a new CloudFront distribution using the procedure in [Creating a Distribution](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-creating-console.html) in the *Amazon CloudFront Developer Guide*.
While completing the procedure, apply the following settings:
+ In **Origin Domain Name**, choose your S3 bucket.
+ Choose **Yes **for **Restrict Bucket Access**.
+ Choose **Create a New Identity** for **Origin Access Identity**.
+ Choose **Yes, Update Bucket Policy** under **Grant Read Permissions on Bucket**.
**Note**
In this procedure, CloudFront modifies your bucket policy to allow it to access bucket objects. Consider [editing](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) this policy to allow access only to objects under the `crl` folder.
1. After the distribution has initialized, locate its domain name in the CloudFront console and save it for the next procedure.
**Note**
If your S3 bucket was newly created in a Region other than us-east-1, you might get an HTTP 307 temporary redirect error when you access your published application through CloudFront. It might take several hours for the address of the bucket to propagate.
### Set up your CA for BPA
While configuring your new CA, include the alias to your CloudFront distribution.
**To configure your CA with a CNAME for CloudFront**
+ Create your CA using [Create a private CA in AWS Private CA](create-CA.md).
When you perform the procedure, the revocation file `revoke_config.txt` should include the following lines to specify a non-public CRL object and to provide a URL to the distribution endpoint in CloudFront:
```
"S3ObjectAcl":"BUCKET_OWNER_FULL_CONTROL",
"CustomCname":"abcdef012345.cloudfront.net"
```
Afterward, when you issue certificates with this CA, they will contain a block like the following:
```
X509v3 CRL Distribution Points:
Full Name:
URI:http://abcdef012345.cloudfront.net/crl/01234567-89ab-cdef-0123-456789abcdef.crl
```
**Note**
If you have older certificates that were issued by this CA, they will be unable to access the CRL.
## Determining the CRL Distribution Point (CDP) URI
If you need to use the CRL Distribution Point (CDP) URI in your workflow, you can either issue a certificate use the CRL URI on that certificate or use the following method. This only works for complete CRLs. Partitioned CRLs have a random GUID appended to them.
If you use the S3 bucket as the CRL Distribution Point (CDP) for your CA, the CDP URI can be in one of the following formats.
+ `http://amzn-s3-demo-bucket.s3.region-code.amazonaws.com/crl/CA-ID.crl`
+ `http://s3.region-code.amazonaws.com/amzn-s3-demo-bucket/crl/CA-ID.crl`
If you have configured your CA with a custom CNAME, the CDP URI will include the CNAME, for example, `http://alternative.example.com/crl/CA-ID.crl`
##
By default, AWS Private CA writes CDP extensions using regional, IPv4-only `amazonaws.com` endpoints. To use CRLs over IPv6, do one of the following steps so that CDPs are written with URLs that point to [S3's dualstack endpoints](https://docs.aws.amazon.com/AmazonS3/latest/API/dual-stack-endpoints.html):
+ Set your [CRL custom name ](create-CA.md#PcaCreateRevocation) to the S3 dualstack endpoint domain. For example, `bucketname.s3.dualstack.region-code.amazonaws.com`
+ Set up your own CNAME DNS record pointing at the relevant S3 dualstack endpoint, then use it as your CRL custom name
# Customize OCSP URL for AWS Private CA
**Note**
This topic is for customers who want to customize the public URL of the Online Certificate Status Protocol (OCSP) responder endpoint for branding or other purposes. If you plan to use the default configuration of AWS Private CA managed OCSP, you can skip this topic and follow the configuration instructions in [Configure revocation](create-CA.md#PcaCreateRevocation).
By default, when you enable OCSP for AWS Private CA, each certificate that you issue contains the URL for the AWS OCSP responder. This allows clients requesting a cryptographically secure connection to send OCSP validation queries directly to AWS. However, in some cases it might be preferable to state a different URL in your certificates while still ultimately submitting OCSP queries to AWS.
**Note**
For information about using a certificate revocation list (CRL) as an alternative or a supplement to OCSP, see [Configure revocation](create-CA.md#PcaCreateRevocation) and [Planning a certificate revocation list (CRL)](crl-planning.md).
Three elements are involved in configuring a custom URL for OCSP.
+ **CA configuration** – Specify a custom OCSP URL in the `RevocationConfiguration` for your CA as described in [Example 2: Create a CA with OCSP and a custom CNAME enabled](create-CA.md#example_2) in [Create a private CA in AWS Private CA](create-CA.md).
+ **DNS** – Add a CNAME record to your domain configuration to map the URL appearing in the certificates to a proxy server URL. For more information, see [Example 2: Create a CA with OCSP and a custom CNAME enabled](create-CA.md#example_2) in [Create a private CA in AWS Private CA](create-CA.md).
+ **Forwarding proxy server** – Set up a proxy server that can transparently forward OCSP traffic that it receives to the AWS OCSP responder.
The following diagram illustrates how these elements work together.
![\[Custom OCSP topology\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/ocsp.png)
As shown in the diagram, the customized OCSP validation process involves the following steps:
1. Client queries DNS for the target domain.
1. Client receives the target IP.
1. Client opens a TCP connection with target.
1. Client receives target TLS certificate.
1. Client queries DNS for the OCSP domain listed in the certificate.
1. Client receives proxy IP.
1. Client sends OCSP query to proxy.
1. Proxy forwards query to the OCSP responder.
1. Responder returns certificate status to the proxy.
1. Proxy forwards certificate status to the client.
1. If certificate is valid, client begins TLS handshake.
**Tip**
This example can be implemented using [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/) and [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) after you have configured a CA as described above.
In CloudFront, create a distribution and configure it as follows:
Create an alternate name that matches your custom CNAME.
Bind your certificate to it.
Set `ocsp.acm-pca..amazonaws.com` as the origin.
To use IPv6 connections, use the dualstack endpoint `acm-pca-ocsp..api.aws`
Apply the `Managed-CachingDisabled` policy.
Set **Viewer protocol policy** to **HTTP and HTTPS**.
Set **Allowed HTTP methods** to **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**.
In Route 53, create a DNS record that maps your custom CNAME to the URL of the CloudFront distribution.
## Using OCSP over IPv6
The default AWS Private CA OCSP responder URL is IPv4-only. To use OCSP over IPv6, configure a custom OCSP URL for your CA. The URL can be either:
+ The FQDN of the dualstack PCA OCSP responder, which takes the form `acm-pca-ocsp.region-name.api.aws`
+ A CNAME record that you have configured to point at the dualstack OCSP responder, as explained above.