AWS Certificate Manager & Private Certificate Authority

Comprehensive Guide with Traffic Flow Diagrams and CLI Commands

Table of Contents

Overview

AWS Certificate Manager (ACM) and AWS Private Certificate Authority (ACM PCA) work together to provide comprehensive certificate management solutions for both public and private infrastructure.

graph TB A[Certificate Requirements] --> B{Public or Private?} B -->|Public| C[AWS Certificate Manager
ACM] B -->|Private| D[AWS Private Certificate Authority
ACM PCA] C --> E[Public SSL/TLS Certificates] D --> F[Private SSL/TLS Certificates] E --> G[CloudFront, ALB, API Gateway] F --> H[Internal Applications, Microservices] D --> I[Root CA] I --> J[Subordinate CA] J --> K[End-entity Certificates]

Certificate Decision Flow

This diagram shows the decision process for choosing between ACM and ACM PCA. Public certificates from ACM are automatically validated and renewed, perfect for internet-facing services. Private certificates from ACM PCA provide complete control over certificate issuance and are ideal for internal infrastructure, microservices, and zero-trust architectures.

AWS Certificate Manager (ACM) Basics

ACM provides free SSL/TLS certificates for AWS services with automatic renewal and domain validation.

sequenceDiagram participant User participant ACM participant DNS participant Route53 participant ALB User->>ACM: Request Certificate ACM->>DNS: Create Validation Record DNS->>Route53: Add CNAME Record Route53->>ACM: Validation Complete ACM->>User: Certificate Issued User->>ALB: Attach Certificate ALB->>ACM: Certificate Validated Note over ACM: Auto-renewal every 60 days

ACM Certificate Lifecycle

This sequence diagram illustrates the complete lifecycle of an ACM certificate from request to deployment. The process includes domain validation through DNS records, automatic issuance, and continuous renewal. ACM integrates seamlessly with Route 53 for DNS validation and automatically renews certificates before expiration.

AWS Private Certificate Authority (ACM PCA) Basics

ACM PCA enables you to create and manage private certificate authorities for internal PKI infrastructure.

graph TD A[Root CA] --> B[Subordinate CA 1] A --> C[Subordinate CA 2] B --> D[Web Server Certs] B --> E[Client Certs] C --> F[Code Signing Certs] C --> G[Email Certs] H[Certificate Templates] --> I[Short-lived Certs] H --> J[Long-lived Certs] K[Revocation] --> L[CRL Distribution] K --> M[OCSP Responder] subgraph "PKI Hierarchy" A B C end subgraph "Certificate Types" D E F G end subgraph "Validation" L M end

Private CA Hierarchy and Certificate Types

This diagram shows a typical private PKI hierarchy with a root CA and subordinate CAs. The root CA is kept offline and secure, while subordinate CAs issue different types of certificates. Certificate templates define policies for different use cases, and revocation mechanisms ensure certificate validity can be checked in real-time.

Traffic Flow Diagrams

Public Certificate Traffic Flow

graph LR A[Internet Client] -->|HTTPS Request| B[CloudFront] B -->|SSL Termination
ACM Certificate| C[Application Load Balancer] C -->|HTTP/HTTPS| D[EC2 Instances] E[Route 53] -->|DNS Resolution| A F[ACM] -->|Certificate Provisioning| B F -->|Certificate Provisioning| C G[Certificate Manager] -->|Auto Renewal| F H[CloudWatch] -->|Monitoring| F subgraph "AWS Services" B C D E F G H end

Public Certificate Traffic Flow

This diagram shows how public ACM certificates are used in a typical web application architecture. Internet clients connect through CloudFront and ALB, both using ACM certificates for SSL termination. The certificates are automatically provisioned and renewed, with Route 53 handling DNS resolution and CloudWatch providing monitoring.

Private Certificate Traffic Flow

graph TB A[Private CA Root] -->|Issues| B[Subordinate CA] B -->|Issues| C[Service Certificates] D[Microservice A] -->|mTLS| E[Microservice B] C -->|Certificate| D C -->|Certificate| E F[Certificate Store] -->|Distribution| D F -->|Distribution| E G[OCSP Responder] -->|Validation| D G -->|Validation| E H[CRL Distribution Point] -->|Revocation List| D H -->|Revocation List| E subgraph "Certificate Authority" A B C end subgraph "Service Mesh" D E end subgraph "Validation Infrastructure" G H end

Private Certificate Traffic Flow

This diagram illustrates how private certificates enable secure communication between microservices using mutual TLS (mTLS). The private CA hierarchy issues certificates to services, which use them for authentication and encryption. OCSP responders and CRL distribution points provide real-time certificate validation and revocation checking.

Hybrid Certificate Architecture

graph TB A[Internet] -->|HTTPS| B[CloudFront + ACM Cert] B -->|HTTPS| C[ALB + ACM Cert] C -->|HTTPS| D[API Gateway] D -->|mTLS + Private Certs| E[Microservices] F[Public ACM] -->|Manages| B F -->|Manages| C G[Private CA] -->|Issues| H[Private Certificates] H -->|Deployed to| E I[Secrets Manager] -->|Stores Private Keys| E J[IAM] -->|Access Control| E subgraph "Public Tier" B C D end subgraph "Private Tier" E end subgraph "Certificate Management" F G H I J end

Hybrid Certificate Architecture

This diagram shows a hybrid approach where public ACM certificates secure internet-facing components (CloudFront, ALB) while private CA certificates secure internal microservice communication. This architecture provides the best of both worlds: easy management of public certificates and full control over private certificates for internal security.

Setup Commands & Configuration

1. Creating a Private Certificate Authority

aws acm-pca create-certificate-authority \
    --certificate-authority-configuration file://ca-config.json \
    --certificate-authority-type "ROOT" \
    --idempotency-token "unique-token-123" \
    --tags Key=Name,Value=MyRootCA Key=Environment,Value=Production
        

Create Certificate Authority Parameters

--certificate-authority-configuration: JSON file containing CA details including subject name, key algorithm, and signing algorithm.

--certificate-authority-type: Either "ROOT" for root CA or "SUBORDINATE" for subordinate CA.

--idempotency-token: Unique token to ensure request is processed only once.

--tags: Key-value pairs for resource tagging and organization.

CA Configuration File (ca-config.json)

{
    "KeyAlgorithm": "RSA_2048",
    "SigningAlgorithm": "SHA256WITHRSA",
    "Subject": {
        "Country": "US",
        "Organization": "MyCompany",
        "OrganizationalUnit": "IT Department",
        "CommonName": "MyCompany Root CA"
    }
}
        

CA Configuration Parameters

KeyAlgorithm: RSA_2048, RSA_4096, EC_256, or EC_384. RSA_2048 is most common.

SigningAlgorithm: Must match key algorithm. SHA256WITHRSA for RSA keys, SHA256WITHECDSA for EC keys.

Subject: Distinguished name components that identify the CA.

Usage: This configuration creates the CA's identity and cryptographic parameters. The subject name appears in all issued certificates.

2. Installing CA Certificate

# Get the CA ARN from the create command output
export CA_ARN="arn:aws:acm-pca:us-east-1:123456789012:certificate-authority/12345678-1234-1234-1234-123456789012"

# Get Certificate Signing Request
aws acm-pca get-certificate-authority-csr \
    --certificate-authority-arn $CA_ARN \
    --output text > ca.csr
        

Certificate Signing Request (CSR) Parameters

--certificate-authority-arn: ARN of the CA created in the previous step.

--output text: Returns the CSR in PEM format for signing.

Usage: The CSR is needed to create the CA certificate. For root CAs, you self-sign this CSR.

# Issue the CA certificate (self-signed for root CA)
aws acm-pca issue-certificate \
    --certificate-authority-arn $CA_ARN \
    --csr fileb://ca.csr \
    --signing-algorithm "SHA256WITHRSA" \
    --template-arn "arn:aws:acm-pca:::template/RootCACertificate/V1" \
    --validity Value=3650,Type=DAYS
        

Issue Certificate Parameters

--csr: File containing the certificate signing request.

--signing-algorithm: Must match the CA's signing algorithm.

--template-arn: Predefined template for root CA certificates.

--validity: Certificate lifetime. Root CAs typically have 10+ year validity.

Usage: This creates the CA's own certificate, enabling it to issue certificates to other entities.

3. Activating the Certificate Authority

# Get the issued certificate
aws acm-pca get-certificate \
    --certificate-authority-arn $CA_ARN \
    --certificate-arn $CERT_ARN \
    --output text > ca-cert.pem

# Import the CA certificate to activate the CA
aws acm-pca import-certificate-authority-certificate \
    --certificate-authority-arn $CA_ARN \
    --certificate fileb://ca-cert.pem
        

CA Activation Parameters

--certificate-arn: ARN returned from the issue-certificate command.

--certificate: The CA certificate in PEM format.

Usage: Activating the CA allows it to issue certificates. Until activated, the CA remains in PENDING_CERTIFICATE status.

4. Creating a Subordinate Certificate Authority

# Create subordinate CA
aws acm-pca create-certificate-authority \
    --certificate-authority-configuration file://subordinate-ca-config.json \
    --certificate-authority-type "SUBORDINATE" \
    --idempotency-token "subordinate-token-456" \
    --tags Key=Name,Value=MySubordinateCA Key=Environment,Value=Production
        

Subordinate CA Configuration (subordinate-ca-config.json)

{
    "KeyAlgorithm": "RSA_2048",
    "SigningAlgorithm": "SHA256WITHRSA",
    "Subject": {
        "Country": "US",
        "Organization": "MyCompany",
        "OrganizationalUnit": "IT Department",
        "CommonName": "MyCompany Subordinate CA"
    }
}
        

Subordinate CA Configuration

Certificate Authority Type: SUBORDINATE indicates this CA will be signed by another CA.

Subject Name: Should clearly distinguish from root CA while maintaining organizational hierarchy.

Usage: Subordinate CAs are used for operational certificate issuance while keeping the root CA offline and secure.

5. Issuing End-Entity Certificates

# Issue a certificate for a web server
aws acm-pca issue-certificate \
    --certificate-authority-arn $SUBORDINATE_CA_ARN \
    --csr fileb://server.csr \
    --signing-algorithm "SHA256WITHRSA" \
    --template-arn "arn:aws:acm-pca:::template/EndEntityCertificate/V1" \
    --validity Value=365,Type=DAYS
        

End-Entity Certificate Parameters

--certificate-authority-arn: ARN of the subordinate CA that will sign the certificate.

--template-arn: EndEntityCertificate template for server/client certificates.

--validity: Shorter validity period for end-entity certificates (typically 1 year or less).

Usage: End-entity certificates are used by applications, servers, and clients for authentication and encryption.

6. Requesting Public ACM Certificates

# Request a public certificate
aws acm request-certificate \
    --domain-name "example.com" \
    --subject-alternative-names "www.example.com" "api.example.com" \
    --validation-method DNS \
    --tags Key=Name,Value=ExampleComCert Key=Environment,Value=Production
        

Public Certificate Request Parameters

--domain-name: Primary domain name for the certificate.

--subject-alternative-names: Additional domain names covered by the certificate.

--validation-method: DNS or EMAIL validation. DNS is recommended for automation.

Usage: Public certificates are free and automatically renewed. They can only be used with supported AWS services.

7. Certificate Validation

# Get validation records for DNS validation
aws acm describe-certificate \
    --certificate-arn $PUBLIC_CERT_ARN \
    --query 'Certificate.DomainValidationOptions[*].ResourceRecord'

# Automatically add validation records to Route 53
aws route53 change-resource-record-sets \
    --hosted-zone-id Z1234567890123 \
    --change-batch file://validation-records.json
        

Validation Records JSON (validation-records.json)

{
    "Changes": [
        {
            "Action": "CREATE",
            "ResourceRecordSet": {
                "Name": "_acme-challenge.example.com",
                "Type": "CNAME",
                "TTL": 300,
                "ResourceRecords": [
                    {
                        "Value": "validation-string.acm-validations.aws."
                    }
                ]
            }
        }
    ]
}
        

DNS Validation Parameters

Action: CREATE to add new validation record, UPSERT to update existing.

Name: CNAME record name provided by ACM for domain validation.

Value: Validation string provided by ACM.

TTL: 300 seconds is recommended for validation records.

Usage: DNS validation proves domain ownership and triggers automatic certificate issuance.

8. Certificate Deployment

# Deploy certificate to Application Load Balancer
aws elbv2 modify-listener \
    --listener-arn $LISTENER_ARN \
    --certificates CertificateArn=$PUBLIC_CERT_ARN \
    --ssl-policy "ELBSecurityPolicy-TLS-1-2-2017-01"
        

Load Balancer Certificate Parameters

--listener-arn: ARN of the HTTPS listener to update.

--certificates: List of certificates to attach to the listener.

--ssl-policy: SSL policy defining supported protocols and ciphers.

Usage: Attaches the certificate to the load balancer for SSL termination.

# Deploy certificate to CloudFront distribution
aws cloudfront update-distribution \
    --id $DISTRIBUTION_ID \
    --distribution-config file://distribution-config.json
        

CloudFront Certificate Deployment

--id: CloudFront distribution ID to update.

--distribution-config: JSON file containing the updated distribution configuration.

Usage: Updates the CloudFront distribution to use the new ACM certificate.

Command Execution Flow

graph TD A[1. Create Root CA] --> B[2. Get CSR] B --> C[3. Issue CA Certificate] C --> D[4. Import CA Certificate] D --> E[5. Create Subordinate CA] E --> F[6. Get Subordinate CSR] F --> G[7. Issue Subordinate Certificate] G --> H[8. Import Subordinate Certificate] H --> I[9. Issue End-Entity Certificates] J[1. Request Public Certificate] --> K[2. Add DNS Validation] K --> L[3. Wait for Validation] L --> M[4. Deploy to AWS Services] subgraph "Private CA Flow" A B C D E F G H I end subgraph "Public Certificate Flow" J K L M end

Command Execution Order

This diagram shows the correct order for executing certificate management commands. The private CA flow requires creating the hierarchy (root, then subordinate CAs) before issuing end-entity certificates. The public certificate flow is simpler but requires DNS validation before deployment.

Detailed Command Flow

Step 1: Create Root CA

Command: aws acm-pca create-certificate-authority

Purpose: Creates the root certificate authority that will be the trust anchor for your PKI.

Next: Capture the CA ARN from the output for subsequent commands.

Step 2: Get Certificate Signing Request

Command: aws acm-pca get-certificate-authority-csr

Purpose: Retrieves the CSR that needs to be signed to create the CA certificate.

Next: Save the CSR to a file for the next step.

Step 3: Issue CA Certificate

Command: aws acm-pca issue-certificate

Purpose: Creates the CA's own certificate using the CSR.

Next: Capture the certificate ARN for retrieval.

Step 4: Import CA Certificate

Command: aws acm-pca import-certificate-authority-certificate

Purpose: Activates the CA by importing its certificate.

Next: CA is now active and can issue certificates.

Step 5: Create Subordinate CA (Optional)

Command: aws acm-pca create-certificate-authority

Purpose: Creates operational CAs for day-to-day certificate issuance.

Next: Repeat steps 2-4 for the subordinate CA.

Best Practices

Security Best Practices:
Important Considerations:

Monitoring and Automation

# Set up CloudWatch alarms for certificate expiration
aws cloudwatch put-metric-alarm \
    --alarm-name "CertificateExpiration" \
    --alarm-description "Alert when certificate expires soon" \
    --metric-name DaysToExpiry \
    --namespace AWS/CertificateManager \
    --statistic Minimum \
    --period 86400 \
    --threshold 30 \
    --comparison-operator LessThanThreshold \
    --evaluation-periods 1
        

CloudWatch Monitoring

Purpose: Monitors certificate expiration and sends alerts.

Threshold: Set to 30 days before expiration for adequate renewal time.

Usage: Automated monitoring prevents service outages due to expired certificates.