How to update CRLs without public access using AWS Private CA

Certificates and the hierarchy of trust they create are the backbone of a secure infrastructure. AWS Private Certificate Authority is a highly available certificate authority (CA) that you can use to create private CA hierarchies, secure your applications and devices with private certificates, and manage certificate lifecycles.

A certificate revocation list (CRL) is a file that contains a signed list of certificates revoked before their scheduled expiration date. Certificates can be revoked for a variety of reasons, including unintended key exposure, or because of discontinued use.

AWS Private CA writes CRLs to an Amazon Simple Storage Service (Amazon S3) bucket that you specify. CRLs are public, fully qualified domain names (FQDNs), but you might have requirements for a CRL that is only accessible internally to your organization, or you might have security standards that require all S3 buckets to have Amazon S3 block public access enabled.

The recommended practice for S3 buckets is to enable Block Public Access, which enables only authorized and authenticated AWS accounts to have access to a bucket and its contents. However, because some public key infrastructure (PKI) clients retrieve CRLs across the public internet, a workaround might be necessary to serve CRLs without requiring authenticated client access to an S3 bucket. One recommended solution is to use Amazon CloudFront to provide access to the CRL. This will likely be the best solution for most customers. Our documentation specifically highlights CloudFront as the recommended implementation path. However, you might not be able to use CloudFront or might need another option.

You might need a solution where the CRL lookups don’t traverse the public internet. In this post, we go over two different approaches to achieve this.

By default, AWS Private CA writes CRLs to an S3 bucket that you specify. This solution consists of moving the CRL to a separate location that is internally accessible to your TLS clients, but not accessible via the public internet such as an on-premises server. A CRL distribution point (CDP) is a link that points to the location of the CRL where revoked certificates appear. However, when private certificates are generated by AWS Certificate Manager (ACM), the CDP universal resource identifiers (URI) in the certificates point by default to the S3 bucket initially specified.

This solution uses a custom CNAME in the CDP to indicate, during certificate generation, the location where the CRL will ultimately be located.

The steps in the solution are as follows:

1. Select the S3 bucket where the CRL will be stored.
2. Issue a certificate through the CA with a custom CNAME.
3. Create an AWS Lambda function that moves the CRL file from the S3 bucket to another specified location.
4. Create an Amazon Simple Notification Service (Amazon SNS) notification that alerts a user to the success metric of the CRL generation event.

For this walkthrough, you must have the following resources ready to use:

1. An AWS account with:
   • An AWS Identity and Access Management (IAM) role with permissions for Amazon S3, ACM Private CA, Amazon EventBridge, and Lambda
   • An ACM private CA root and subordinate CA configured in the same AWS Region
   • An S3 bucket for the CRL with permissions that allow the AWS Private CA service principal to PutObject, PutObjectACL, GetBucketACL and GetBucketLocation (see the following example bucket policy)

{     
    "Version": "2012-10-17",     
    "Statement": [         
        {             
            "Effect": "Allow",             
            "Principal": {                 
                "Service": "acm-pca.amazonaws.com"             
            },             
            "Action": [                 
                "s3:PutObject",                 
                "s3:PutObjectAcl",                 
                "s3:GetBucketAcl",                 
                "s3:GetBucketLocation"             
            ],             
            "Resource": [                 
                "arn:aws:s3:::<name-of-bucket>/*",                 
                "arn:aws:s3:::<name-of-bucket>"             
            ],             
            "Condition": {                 
                "StringEquals": {                     
                    "aws:SourceAccount": "<account-num-here>",                     
                    "aws:SourceArn": "<subordinate-ca-arn-here>"                 
                }             
            }         
        }     
    ] 
}

2. AWS Command Line Interface (AWS CLI) configured

With the prerequisites in place, you’re ready to deploy the first solution.

To enable CRL distribution:

1. Use your account to sign in to the AWS Management Console for AWS Private Certificate Authority.
2. Select the name of your subordinate CA. This should take you to another page with more details.
3. Scroll down and choose the Revocation configuration tab.
4. Choose Edit on the top right.


Figure 1: Edit the revocation configuration

5. Select Activate CRL distribution. Select the CRL S3 bucket you created prior to the walkthrough.


Figure 2: Enter a name for your CRL

6. Modify the CDP by expanding the CRL settings dropdown. In the Custom CRL Name field, enter the URL where you will eventually move the CRL. This should be a place that is accessible by your internal organization, but not accessible externally. If you use partitioned CRLs, select the Enable partitioning checkbox. To learn more about CRL partitioning, see Plan your AWS Private CA certificate revocation method.
7. Choose Save changes.

To create an SNS topic and Lambda function:

1. Go to the Amazon SNS console.
2. Create a standard SNS topic. Leave all options as default and subscribe an appropriate email to the topic.


Figure 3: Create an SNS topic

3. Go to the Lambda console.
4. Choose Create Function.
5. Enter a name for your function. Under Runtime, select Python 3.12 from the dropdown.


Figure 4: Create a Lambda function

6. Verify that the role associated with your Lambda function has permissions to get objects from the S3 bucket where AWS Private CA places the CRL (set when you configured the revocation details for the CA), copy objects in Amazon S3, then put objects in an S3 bucket (or wherever the new CRL distribution point specified in the certificate custom CNAME will be—for example, an internal-only accessible location), and publish to an Amazon SNS topic. The Lambda function also checks the success metric of a CRL generation event. If the event fails, an SNS topic will notify an admin. If the event is successful, a copy of the CRL in the original S3 bucket is created in the new specified location and an SNS topic will notify an admin.

Example code (Python 3.13):

import boto3 
import json 

def lambda_handler(event, context):     
	#create a s3 client     
	s3 = boto3.client('s3')          

	#create a sns client     
	sns = boto3.client('sns')     
    topicArn = "<sns-topic-arn-here>”     
    
    #get name of the CA from the CW event     
    caID = event['resources'][0].split('/')[-1]          
    status = event['detail']['result']     
    if status == 'success':              
    	
        source = '<ORIGINS3BUCKET>'         
        destination = '<DESTINATION-S3BUCKET>'         
        #See below note for more clarification on S3 CRL paths         
        folder = 'crl/'         
        file = caID + '.crl'         
        key = folder + file              
        
        try:             
        	copySource = {                 
            	'Bucket': source,                 
                'Key': key             
           	}                      
            
            s3.copy_object(                 
            	CopySource=copySource,                 
                Bucket=destination,                 
                Key=file             
          	)             
            response = sns.publish(                 
            	TopicArn=<sns-topicArn>,                 
                Message=f'Successfully moved {key} from {source} to {destination} in {caID}',                 
                Subject="CRL Upload Success"             
          	)                      
            
            return {                 
            	'statusCode': 200,                 
                'body': json.dumps(f'Successfully moved {key} from {source} to {destination} in {caID}')             
          	}                  
    	
        except s3.exceptions.NoSuchKey:             
        	response = sns.publish(                 
            	TopicArn=<sns-topicArn>,                 
                Message=f"Object {key} not found in {source}",                 
                Subject='CRL Upload Failure'             
          	)             
            return {                 
            	'statusCode': 404,                 
                'body': json.dumps(f'Object {key} not found in {source}')             
          	}                  
   		except Exception as e:             
    		print(e)             
        	response = sns.publish(                 
        		TopicArn=<sns-topicArn>,                 
            	Message=f'Error moving object: {str(e)}',                 
            	Subject='Failure Uploading CRL'             
     		)             
			return {                 
    			'statusCode': 500,                 
        		'body': json.dumps(f'Error moving object: {str(e)}')             
  			}     
    else:         
    	response = sns.publish(                 
        		TopicArn=<sns-topicArn>,                 
            	Message=f'Certificate Authority {caID} CRL creation {status}',                 
            	Subject='CRL Upload Failure'             
     		)         
        return {             
        	'statusCode': 200,             
            'body': json.dumps(f'Certificate Authority {caID} CRL creation {status}')         
      	}

Note: By default, the non-partitioned CRL path in S3 is <s3-bucket-name>/crl/<CA-ID>.crl. If you used a custom path, modify the path name to the CRL accordingly. Alternatively, if using partitioned CRLs, the path changes to <s3-bucket-name>/crl/<CA-ID>/<partition_GUID>.crl; in that case, you can loop over each file in the <CA-ID> path to achieve the same effect.

To create an EventBridge that deploys your Lambda function:

1. Go to the EventBridge console. Under Buses, select Rules.
2. Choose Create Rule.
3. Enter a name for your rule. Under Rule Type, select Rule with an Event Pattern and choose Next.
4. Under Events, select AWS events or EventBridge partner events as the Event Source.
5. For the Event pattern, select Use pattern form. For the Event source, select AWS services. For Event Type, select ACM Private CA CRL Generation.

Figure 5: Configure the event pattern

6. Choose Next.
7. Under Target types, choose AWS Service, and then select Lambda function from the Select a target dropdown and select the function that you created earlier.


Figure 6: Select the Lambda function as the target

8. Choose Next. Review your topic, then choose Update rule.

To test the success of the Lambda function:

1. To test the EventBridge topic, create and revoke a certificate. You can do this using the AWS CLI by getting the serial number of a certificate using openSSL:
   openssl x509 -in cert.pem -noout -serial
2. Use the following command to revoke the certificate:
   aws acm-pca revoke-certificate —certificate-authority-arn <CA ARN> \ —certificate-serial <SERIAL NUMBER RETURNED IN STEP 1> --revocation-reason “UNSPECIFIED”
3. To make sure that the Lambda function is triggered, wait 5–30 minutes. Check CloudTrail to make sure that RevokeCertificate was called, then monitor the CloudWatch log of the Lambda function. You should also get a notification message from your SNS topic.
4. You have now successfully moved your CRL to a new location.

Option 2: Implement Private CRL Access Through AWS Private CA

This solution provides private Certificate CRL access within AWS Private CA, avoiding the need for public internet exposure. The design centers on establishing root and subordinate CAs with CRL functionality enabled within a dedicated S3 bucket, combined with a private network infrastructure using Gateway VPC endpoints and private subnets. Security is enforced through an S3 bucket policy that accomplishes three critical objectives:

• Authorizing essential AWS Private CA permissions
• Constraining CRL access to a designated Gateway VPC endpoint
• Explicitly blocking access attempts from other sources.

The solution includes private DNS zone configuration for proper resolution and can be verified through access testing confirming successful CRL retrieval from private VPC instances while making sure that requests from public instances are denied, maintaining a strictly private PKI.

1. Create a root CA and subordinate CA with CRL enabled
2. Configure a dedicated S3 bucket for CRL storage
3. Issue private certificates through ACM
4. Set up a VPC with private subnets
5. Configure a Gateway VPC endpoint for Amazon S3
6. Set up route tables for local traffic only
7. Implement an S3 bucket policy with specific permissions
8. Configure private DNS resolution
9. Set up access controls through VPC endpoints
10. Test private access from within the VPC
11. Verify that public access is blocked

Prerequisites for CRL solution 2

For this walkthrough, you must have the following resources available:

• An AWS account with necessary permissions
• AWS CLI installed and configured
• OpenSSL installed for certificate operations
• Access to the following AWS services: ACM, AWS Private CA, Amazon Virtual Private Cloud (Amazon VPC), Amazon S3, and Amazon Route 53

Deploy CRL solution 2

With the prerequisites in place, you’re ready to use the console and AWS CLI to deploy the solution.

To deploy the solution:

1. Go to the AWS Private Certificate Authority console.
2. In the navigation pane, choose Create a Private CA.
   1. Under Mode options, select General-purpose.
   2. For CA type options, select root.
   3. For the Subject distinguished name options: Fill in at least one of the subject distinguished name options: Organization(O), Organization unit (OU), Country(C), State, Locality name, and Common name (CN).
      

      Figure 7: Create a private CA (root)

   4. Select Key algorithm options, for example, RSA 2046.
   5. Under Certificate revocation options, select Activate CRL Distribution, and select or create an S3 bucket for CRL storage.
   6. Under Pricing, select the checkbox to acknowledge pricing and then select Create CA.


Figure 8: Configure a private CA (root)


3. After creating a root CA, repeat all of step 2 to create a subordinate CA, selecting Subordinate CA under CA options (step 2-b). When completed, both the root CA and subordinate CA will be visible on the Private certificate authority page.



Figure 9: View of root CA and subordinate CA

With the root CA and subordinate CA in place, the next step is to create a VPC gateway endpoint for S3 access to enable private network communication.

To create a VPC gateway endpoint:

1. Go to the Amazon VPC console
2. In the left navigation pane, select Endpoints, and choose Create Endpoint.
3. Configure the Gateway VPC endpoint settings:
   1. Enter a descriptive name for your endpoint (optional).
   2. Type: Select AWS services.
   3. Services: Select the service name com.amazonaws.[region].s3 from the list.
   4. Type: Verify that Gateway is selected (automatically chosen for Amazon S3).
   5. VPC: Choose the VPC where you want to create the endpoint.
   6. Route tables: Select the route tables associated with the subnets that need Amazon S3 access.
   7. Policy: Select Full Access or create a custom policy to restrict access to specific S3 buckets or actions.
   8. Review your configuration and choose Create endpoint.


Figure 10: Gateway VPC endpoint configuration

4. Create two private subnets:
1. In the Amazon VPC console, choose Subnets and then Create subnet.
2. Select your VPC and enter the subnet details (name, Availability Zone, and CIDR block).
3. Repeat for the second subnet in a different Availability Zone.
5. Configure route tables:
1. Navigate to Route Tables and choose Create route table.
2. Create and name two route tables for your private subnets.
3. Associate each route table with its corresponding private subnet.
4. Make sure that each route table contains only local routes (VPC CIDR).
5. Remove any routes for internet access (0.0.0.0/0).


Figure 11: Private route table configuration

6. You can see now see under Resource Map that the Gateway VPC endpoint provides secure access to Amazon S3 resources within the private network.


Figure 12: VPC private instance configuration

7. Use the following example code to implement a bucket policy that enforces the following key security controls:
   • Grant AWS Private CA the necessary permissions for certificate management.
   • Restrict CRL access exclusively through the specified VPC endpoint.
   • Explicitly deny GetObject requests not originating from the designated Gateway VPC endpoint.


Figure 13: S3 bucket policy

The following is an example S3 bucket policy for private CA CRL access with VPC endpoint restrictions:

{     
    "Version": "2012-10-17",     
    "Statement": [         
        {             
            "Effect": "Allow",             
            "Principal": {                 
                "Service": "acm-pca.amazonaws.com"             
                },             
            "Action": [                 
                "s3:PutObject",                 
                "s3:PutObjectAcl",                 
                "s3:GetBucketAcl",                 
                "s3:GetBucketLocation"             
            ],             
            "Resource": [                 
                "<arn:aws:s3:::BUCKET_NAME>",                 
                "<arn:aws:s3:::BUCKET_NAME>/"           
            ],           
            "Condition": {               
                "StringEquals": {                   
                    "aws:SourceArn": "<arn:aws:acm-pca:REGION:ACCOUNT_ID:certificate-authority/CA_ID>",                   
                    "aws:SourceAccount": "<ACCOUNT_ID>"               
                    }           
            }       
        },       
        {           
            "Sid": "Allow Access to CRL",           
            "Effect": "Allow",            
            "Principal": "",             
            "Action": "s3:GetObject",             
            "Resource": "<arn:aws:s3:::BUCKET_NAME/crl/CA_ID.crl>",             
            "Condition": {                 
                "StringEquals": {                     
                    "aws:SourceVpce": "<VPCE_ID>"                 
                    }             
            }         
        },         
        {             
            "Sid": "Access-to-specific-VPCE-only",             
            "Effect": "Deny",             
            "Principal": "",            
            "Action": "s3:GetObject",           
            "Resource": [               
                "<arn:aws:s3:::BUCKET_NAME>",               
                "<arn:aws:s3:::BUCKET_NAME>/"             
            ],             
            "Condition": {                 
                "StringNotEquals": {                     
                    "aws:SourceVpce": "<VPCE_ID>"                 
                    }             
            }         
        }     
    ] 
}



Figure 14: S3 bucket CRL properties

Create a private hosted zone:

1. Go to the Route 53 console.
2. In the left navigation pane, choose Hosted zones.
3. Choose Create hosted zone.
4. Configure the following:
   1. Domain name: Enter s3.amazonaws.com
   2. Description: (optional) enter Private hosted zone for S3 CRL endpoint
   3. Type: Select Private hosted zone.
   4. VPC: For Region, select your VPC’s Region; for VPC ID, select your VPC from the dropdown list.
5. Choose Create hosted zone.

Create a record set:

1. Inside your new private hosted zone:
   1. Choose Create record.
   2. Select Simple routing policy.
   3. Choose Next.
2. Configure record:
   1. Record name: Enter your S3 bucket name.
   2. Record type: Select A – Routes traffic to an IPv4 address.
   3. Alias: Toggle Yes.
   4. Route traffic to: Select Alias to S3 website endpoint.
   5. Region: Select your Region.
   6. S3 endpoint: Select from dropdown list.
   7. TTL: Leave as default (300 seconds).
3. Choose Create record.


Figure 15: Hosted zone details

Verify configuration:

1. Go to the Amazon EC2 console and choose Launch instance.
2. Select Amazon Linux 2.
3. Choose Instance Type.
4. Select you VPC and subnet.
5. Under Network settings, select Create security group, then choose Allow SSH traffic from and enter your IP address.
6. Choose Launch instance.
7. After the instance is launched, select the instance and choose Connect.
8. Select EC2 Instance Connect and choose Connect.

Test the solution

To test private access from an EC2 instance within your private VPC, verify CRL access using:
curl -s https://<bucket-name>.s3.<region>.amazonaws.com/crl/<certificate-id>.crl | openssl crl -text -noout

If successful, the command completes the following steps, as shown in Figure 16:

1. Retrieves the CRL from Amazon S3
2. Decodes it using OpenSSL
3. Displays comprehensive CRL information including issuer details, update timestamps, revoked certificate list, signature algorithm, and other metadata


Figure 16: Public access verification

To validate your security controls, attempt access from a public EC2 instance using the following command:
curl https://<bucket-name>.s3.<region>.amazonaws.com/crl/<certificate-id>.crl

This should fail, receiving an access denied error confirming that the CRL cannot be accessed from the public internet, as shown in Figure 17.



Figure 17: Access denied error confirming that the CRL cannot be accessed from the public internet

Conclusion

In this post, we walked you through two solutions that you can use to make your CRLs accessible to your internal organization, but not publicly available. First, we showed you how to configure a custom CNAME in your CRL distribution point and deploy Lambda functions to automatically copy each newly generated CRL from the default S3 bucket into a private S3 store.

Next, we showed you a VPC architecture that uses an Amazon S3 VPC gateway endpoint, tightly scoped bucket policies, and private Route 53 DNS zones to make sure that CRL retrieval is confined to your VPC. We also covered the essential IAM and bucket policies that your clients need to access those CRLs securely. You can get started with setting up this solution on AWS Private CA today.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Certificate Manager forum or contact AWS Support.