12.3 AWS Certificate Manager (ACM) & Private CA Architecture

12.3 AWS Certificate Manager (ACM) & Private CA Architecture

Securing data in transit across modern enterprise architectures requires pervasive TLS/SSL encryption across all network boundaries—from internet-facing content delivery networks down to internal microservice-to-microservice remote procedure calls. Establishing and maintaining a secure Public Key Infrastructure (PKI) has historically introduced substantial administrative friction, including manual certificate generation, key management risks, complex certificate revocation list maintenance, and catastrophic application outages caused by unexpected certificate expiration.

AWS resolves these PKI challenges through two integrated services: AWS Certificate Manager (ACM) and AWS Private CA (formerly ACM Private CA). ACM manages the automated provisioning, validation, and renewal of public and private X.509 certificates for integrated AWS services, while AWS Private CA enables organizations to build highly available, enterprise-grade private certificate authority hierarchies shared across multi-account AWS Organizations.

---

AWS Certificate Manager (ACM) Public Certificates

AWS Certificate Manager provides public SSL/TLS certificates at no additional cost for use with AWS-managed services. Public ACM certificates are signed by Amazon Trust Services (ATS), a globally recognized Certificate Authority trusted by all modern web browsers, operating systems, and mobile devices.

The Non-Exportable Key Security Boundary

Core Security Principle: A standard public certificate from ACM cannot be exported. Its private key stays inside ACM, so you can't install it on an Amazon EC2 instance running Apache, an on-premises web server, or an external container host.

Exportable public certificates (available since June 2025) are the exception. You choose export when you request the certificate and pay a per-certificate fee; ExportCertificate then returns the certificate, chain, and a passphrase-encrypted private key. ACM renews them, and you re-export and reinstall after each renewal. Existing certificates can't be converted to exportable ones.

Standard (non-exportable) public ACM certificates bind to integrated AWS resources:

• Elastic Load Balancing: Application Load Balancers (ALB), Network Load Balancers (NLB) with TLS listeners.
• Amazon CloudFront: Global content delivery network distributions.
• Amazon API Gateway: REST APIs, HTTP APIs, and WebSocket APIs using custom domain names.
• AWS App Runner and AWS Elastic Beanstalk.

The CloudFront Regional Placement Rule

A critical requirement frequently tested on the AWS Security Specialty exam is regional certificate placement for edge services:

• To attach an ACM SSL/TLS certificate to an Amazon CloudFront distribution, the certificate MUST be requested or imported in the us-east-1 (US East - N. Virginia) region.
• Certificates provisioned in any other AWS region (e.g., us-west-2 or eu-west-1) cannot be associated with a CloudFront distribution, even if the origin servers reside in those regional VPCs.
• For regional resources like Application Load Balancers and API Gateways, the certificate must reside in the exact same AWS region as the resource.

Domain Validation: DNS Validation vs. Email Validation

Before ACM issues a public certificate, the requesting party must prove ownership and administrative control over the fully qualified domain names (FQDNs) listed in the certificate. ACM supports two validation methods:

Exam Recommendation: Always use DNS validation for public ACM certificates. Email validation introduces operational fragility, manual renewal overhead, and the risk of unexpected certificate expiration if corporate mailbox forwarding fails.

---

AWS Private CA Architecture & PKI Hierarchies

While public certificates establish trust for external internet clients, internal zero-trust enterprise microservices, private VPC load balancers, VPN tunnels, and IoT device networks require an internal PKI. Public CAs cannot issue certificates for internal private namespaces (e.g., .corp, .internal, or .local), nor do enterprises want to expose internal service names in public Certificate Transparency (CT) logs.

AWS Private CA is an enterprise-scale, managed private certificate authority service that eliminates the undifferentiated heavy lifting of deploying, patching, and securing dedicated CA servers (such as Microsoft Active Directory Certificate Services or OpenSSL-based software).

Loading diagram...

Designing CA Hierarchies: Root and Subordinate CAs

Enterprise security architecture mandates a tiered hierarchy to enforce defense-in-depth and minimize the blast radius if an issuing key is compromised:

1. Root CA:
   • Sits at the apex of the cryptographic trust tree. It issues and signs subordinate CA certificates.
   • Validity Period: Configured with a long validity horizon, typically 10 to 20 years.
   • Operational Governance: In mature enterprises, the root CA key is locked down with strict SCPs, MFA delete protections, and multi-party approval workflows. It is never used to issue end-entity certificates directly.
   • External Root Support: Organizations can maintain their root CA on-premises in a physical HSM and use AWS Private CA solely for subordinate issuing CAs by signing the subordinate CSR with the on-premises root CA.
2. Subordinate (Issuing) CAs:
   • Signed by the root CA or an intermediate CA.
   • Validity Period: Configured with an intermediate validity period, typically 3 to 5 years.
   • Function: Actively issues end-entity leaf certificates to application servers, internal ALBs, Kubernetes pods, and client devices.
   • Subordinate CAs can be divided by environment (Production vs. Staging), geographic region, or business unit.

---

Certificate Revocation: CRLs and OCSP

When a private key is suspected of compromise, an employee departs, or a microservice is permanently decommissioned, the certificate must be revoked immediately before its natural expiration. AWS Private CA supports two complementary revocation verification mechanisms:

1. Certificate Revocation Lists (CRLs)

A CRL is a cryptographically signed file listing all revoked certificate serial numbers and revocation timestamps:

• S3 Publication: AWS Private CA automatically generates and updates the CRL file, depositing it into a designated Amazon S3 bucket.
• S3 Bucket Policy Requirements: The target S3 bucket must have a bucket policy granting write access to the AWS Private CA service principal (acm-pca.amazonaws.com), ideally scoped with aws:SourceAccount and aws:SourceArn:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "AllowPCAToWriteCRL",
        "Effect": "Allow",
        "Principal": {
          "Service": "acm-pca.amazonaws.com"
        },
        "Action": [
          "s3:PutObject",
          "s3:PutObjectAcl",
          "s3:GetBucketAcl",
          "s3:GetBucketLocation"
        ],
        "Resource": [
          "arn:aws:s3:::enterprise-pki-crl-bucket/*",
          "arn:aws:s3:::enterprise-pki-crl-bucket"
        ]
      }
    ]
  }
  

• Client Accessibility: Relying parties (client browsers, operating systems, internal curl clients) must be able to reach the S3 bucket to download the CRL. Either allow public read on the CRL objects or, as AWS recommends, keep S3 Block Public Access on and serve the CRL through a CloudFront distribution (with a custom CRL name in the CA configuration).

2. Online Certificate Status Protocol (OCSP)

CRLs can grow substantially in size over time, introducing download latency and network overhead during TLS handshakes. OCSP provides a real-time, lightweight alternative:

• AWS Private CA provides a fully managed, highly available OCSP responder.
• Instead of downloading the full list of all revoked certificates, the relying party sends an HTTP GET request containing the specific certificate's serial number directly to the OCSP responder URL embedded in the certificate's Authority Information Access (AIA) extension.
• The OCSP responder returns a definitive, signed status: Good, Revoked, or Unknown.

---

Cross-Account CA Sharing via AWS Resource Access Manager (RAM)

In multi-account AWS Organizations, provisioning a dedicated Private CA inside every single application account is cost-prohibitive (AWS Private CA carries a base fee of $400 per month per active CA) and creates severe PKI governance sprawl.

The enterprise standard pattern centralizes CA infrastructure within a Security Tooling or Shared Services Account and shares issuing capability across the enterprise using AWS Resource Access Manager (RAM).

How RAM Sharing Works

1. Create the Subordinate CA: The security team provisions the issuing subordinate CA in the central Security account.
2. Create a RAM Resource Share: The security team creates a resource share in AWS RAM, selects the Subordinate CA ARN as the shared resource, and specifies the principal (the entire AWS Organization ID or specific Organizational Unit ARNs).
3. Consumer Account Issuance: Inside member accounts, the shared CA appears directly in the local AWS Certificate Manager console.
4. Separation of Duties & Least Privilege:
   • Application developers in member accounts can call acm:RequestCertificate referencing the shared CA ARN to provision certificates for their internal Application Load Balancers and API Gateways.
   • Member accounts CANNOT modify the CA configuration, alter revocation settings, view private keys, or delete the CA.
   • Application teams achieve self-service certificate provisioning without compromising central PKI security governance.

---

Deploying Private Certificates: Managed Integration vs. Exportable Certificates

AWS Private CA supports two distinct deployment models depending on where the certificate is hosted:

1. ACM-Managed Private Certificates (Integrated Services)

When a private certificate is requested through ACM (acm:RequestCertificate specifying CertificateAuthorityArn), ACM manages the entire lifecycle:

• The certificate binds seamlessly to internal Application Load Balancers, API Gateways (supporting custom domains and mutual TLS / mTLS truststores), and Network Load Balancers.
• The key stays in ACM unless you export the certificate: ACM private certificates can be exported with ExportCertificate (private key encrypted with a passphrase) for use on EC2 or on premises.
• ACM automatically renews the private certificate prior to expiration and automatically updates the attached load balancers with the new certificate version.

2. Exportable Private Certificates via AWS Private CA API

When securing workloads that run outside ACM-integrated services—such as Apache/Nginx web servers running on Amazon EC2 instances, self-hosted Docker containers, Kubernetes ingress controllers, on-premises hypervisors, or client mTLS authentication devices—ACM cannot bind the certificate automatically.

For these use cases, engineers invoke the AWS Private CA API directly:

• acm-pca:IssueCertificate: Issues a certificate from a Certificate Signing Request (CSR).
• acm-pca:GetCertificate: Retrieves the signed X.509 certificate body and certificate chain.
• acm-pca:GetCertificateAuthorityCertificate: Retrieves the CA certificate and chain.
• Exportable Private Key: When using the Private CA API, the client generates their own private key locally, submits the CSR to Private CA, and receives the signed certificate. The private key resides securely on the EC2 instance or host server.
• Automation: Integrations such as the aws-privateca-issuer plugin for cert-manager on Kubernetes, AWS Private CA Connector for Active Directory, and HashiCorp Vault automate key generation, CSR submission, and certificate installation. Short-lived certificate mode CAs issue certificates valid for up to 7 days at a lower price.

---

Specialty Exam Pitfalls & Architectural Traps

1. CloudFront Regional Mismatch: Requesting a public ACM certificate in eu-central-1 or us-west-2 and attempting to attach it to an Amazon CloudFront distribution. CloudFront requires all SSL/TLS certificates to be provisioned in us-east-1. Regional certificates will not appear in the CloudFront distribution drop-down.
2. Blocking Public Access on the S3 CRL Bucket: Enabling S3 Block Public Access (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) on the S3 bucket designated for Private CA CRLs without configuring an alternate distribution mechanism (such as CloudFront). When external or internal clients attempt to validate certificate revocation during TLS handshakes, the CRL fetch fails, causing client connection terminations.
3. Assuming Every ACM Certificate Can Be Exported: A standard public ACM certificate can't be exported, and an existing one can't be made exportable. For EC2-hosted Nginx or Apache servers, request an exportable public certificate (for internet-facing names), export an ACM private certificate or issue one from AWS Private CA (for internal names), or terminate TLS on a load balancer.
4. DNS CNAME Deletion Causing Renewal Outages: Deleting the CNAME validation record from Amazon Route 53 after the public ACM certificate is successfully issued. While the certificate remains valid until its expiration date, deleting the CNAME record breaks ACM's automated renewal, which starts 45 days before expiry. When the renewal window opens, ACM fails validation and the certificate expires, inducing production application outages.