Comprehensive Guide with Traffic Flow Diagrams and CLI Commands
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.
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.
ACM provides free SSL/TLS certificates for AWS services with automatic renewal and domain validation.
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.
ACM PCA enables you to create and manage private certificate authorities for internal PKI infrastructure.
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.
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.
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.
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.
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
--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.
{ "KeyAlgorithm": "RSA_2048", "SigningAlgorithm": "SHA256WITHRSA", "Subject": { "Country": "US", "Organization": "MyCompany", "OrganizationalUnit": "IT Department", "CommonName": "MyCompany Root CA" } }
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.
# 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-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
--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.
# 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
--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.
# 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
{ "KeyAlgorithm": "RSA_2048", "SigningAlgorithm": "SHA256WITHRSA", "Subject": { "Country": "US", "Organization": "MyCompany", "OrganizationalUnit": "IT Department", "CommonName": "MyCompany Subordinate CA" } }
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.
# 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
--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.
# 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
--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.
# 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
{ "Changes": [ { "Action": "CREATE", "ResourceRecordSet": { "Name": "_acme-challenge.example.com", "Type": "CNAME", "TTL": 300, "ResourceRecords": [ { "Value": "validation-string.acm-validations.aws." } ] } } ] }
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.
# 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"
--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
--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.
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.
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.
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.
Command: aws acm-pca issue-certificate
Purpose: Creates the CA's own certificate using the CSR.
Next: Capture the certificate ARN for retrieval.
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.
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.
# 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
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.