AWS Certificate Manager (ACM): SSL/TLS Certificates for ALB and CloudFront

What ACM does, without the jargon

A TLS certificate does two things: it proves your website is really yours (not a fake), and it encrypts traffic between the browser and your server. Without one, browsers show a “Not Secure” warning and block HTTPS connections entirely.

Traditionally, getting a certificate meant buying one from a Certificate Authority, downloading it, uploading it to your server, and repeating the whole process every year when it expired. Miss the renewal and your site throws certificate errors for every visitor. ACM replaces all of that. AWS acts as the CA, issues the certificate for free, stores the private key securely inside AWS, and renews it automatically. You never see or touch the private key, which is also why ACM certificates can only be used with AWS-managed services that handle TLS termination on your behalf (ALB, CloudFront, API Gateway, and similar).

By the end of this page you will be able to request an ACM certificate, prove domain ownership via DNS, attach the certificate to an ALB HTTPS listener, understand the CloudFront region rule, and set things up so your certificate renews itself indefinitely without any manual work.

When to use ACM and when not to

ACM-issued public certificates are the right tool whenever AWS handles TLS termination for you:

• Application Load Balancers: HTTPS listeners on an ALB accept ACM certificates directly. This is the most common use case.
• CloudFront distributions: ACM is the standard way to attach a custom TLS certificate to a CloudFront distribution. See the region requirement section below.
• API Gateway: custom domain names on API Gateway use ACM certificates.
• Elastic Beanstalk, App Runner, and other AWS-managed compute: any AWS service that supports TLS termination accepts ACM certificates.

ACM-issued public certificates are not the right tool in these cases:

• You need to install the certificate directly on an EC2 instance, Nginx, Apache, or any software that requires the private key file on disk.
• You are running an on-premises server that needs a certificate.
• You are using a third-party CDN or service that lives entirely outside AWS.

For those cases, get a certificate from an external CA (like Let’s Encrypt or DigiCert), and if you want it accessible through the AWS console, you can import it into ACM. ACM does not auto-renew imported certificates, so renewal becomes your responsibility.

How ACM works: the five-step flow

1. Request certificate. Tell ACM which domain names to cover (e.g., example.com and *.example.com). Choose DNS validation.
2. Prove domain ownership. ACM gives you a CNAME record to add to your DNS. Adding it proves you control the domain.
3. Wait for ISSUED. Once ACM detects the CNAME in DNS, it issues the certificate. Status changes from PENDING_VALIDATION to ISSUED. This usually takes a few minutes after the CNAME is publicly visible.
4. Attach to the AWS service. Select the certificate when creating an HTTPS listener on an ALB or configuring a custom domain on a CloudFront distribution.
5. ACM auto-renews. As long as the DNS validation CNAME stays in place, ACM renews the certificate automatically 60 days before it expires. You do nothing.

DNS validation vs email validation

When you request a public ACM certificate, you must choose how to prove you own the domain. There are two options, and one of them is almost always the right choice:

Step-by-step: request, validate, and check status

# Step 1: Request a certificate for the apex domain and all subdomains
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names "*.example.com" \
  --validation-method DNS \
  --region us-east-1

# Step 2: Get the certificate ARN
CERT_ARN=$(aws acm list-certificates \
  --query 'CertificateSummaryList[?DomainName==`example.com`].CertificateArn' \
  --output text \
  --region us-east-1)

# Step 3: Retrieve the validation CNAME record to add to DNS
aws acm describe-certificate \
  --certificate-arn $CERT_ARN \
  --region us-east-1 \
  --query 'Certificate.DomainValidationOptions[0].ResourceRecord'

The output includes the CNAME name and value. Add this record to your DNS provider exactly as shown. If your domain is managed in Route 53, the AWS console shows a “Create records in Route 53” button that adds the CNAME automatically. That is the fastest path.

# Step 4: Add the validation record via CLI in Route 53
# Replace the hosted zone ID and record values with the exact values ACM provides
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDE \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_abc123def456.example.com",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [{"Value": "_ghi789jkl012.acm-validations.aws"}]
      }
    }]
  }'

# Step 5: Poll until status is ISSUED
# Usually a few minutes after the CNAME is publicly visible
aws acm describe-certificate \
  --certificate-arn $CERT_ARN \
  --region us-east-1 \
  --query 'Certificate.Status'

Once the output shows “ISSUED”, the certificate is ready to attach to your ALB or CloudFront distribution. If it stays at “PENDING_VALIDATION” for more than 30 minutes, verify the record is publicly visible: dig _abc123def456.example.com CNAME. No result means the record is missing or not yet propagated.

Attaching a certificate to an ALB

Once the certificate is ISSUED, attach it to your ALB by creating an HTTPS listener on port 443. The ALB terminates TLS at the load balancer, meaning it decrypts the HTTPS traffic and forwards plain HTTP to your backend targets.

# Create an HTTPS listener with the ACM certificate
aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTPS \
  --port 443 \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --certificates CertificateArn=$CERT_ARN \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN

The ELBSecurityPolicy-TLS13-1-2-2021-06 TLS policy enforces TLS 1.2 and TLS 1.3 only, disabling older insecure protocol versions. This is the recommended policy for new ALBs and satisfies most compliance requirements. For a full breakdown of TLS policies and cipher suites, see the network security best practices guide.

An ALB HTTPS listener can hold multiple certificates, which is useful when the same ALB serves multiple domains. The ALB uses Server Name Indication (SNI) to select the correct certificate based on the hostname the client sends in the TLS handshake.

Wildcard certificates: what they cover and what they don’t

A wildcard certificate for *.example.com covers all single-level subdomains: api.example.com, app.example.com, admin.example.com. Anything one level deep below the domain.

It does not cover:

• The apex domain (example.com itself). This is the most common wildcard assumption that breaks HTTPS on the root domain. The asterisk covers subdomains only.
• Multi-level subdomains. v2.api.example.com is not covered by *.example.com.

The practical solution: request a single ACM certificate with example.com as the primary domain and *.example.com as a Subject Alternative Name (SAN). This one certificate covers both the apex domain and all single-level subdomains. The request in the step-by-step section above does exactly this, which is why it includes both —domain-name example.com and —subject-alternative-names “*.example.com”.

CloudFront vs ALB: certificate region requirements

If you need the same domain protected on both a CloudFront distribution and a regional ALB, you need two separate ACM certificates: one in us-east-1 for CloudFront and one in the ALB’s region. The DNS validation CNAME record is the same for both requests, so you only need to add it once in DNS. Both certificates can share the same validation record.

Automatic renewal: how it works and what breaks it

ACM starts the renewal process 60 days before a certificate expires. It checks that the DNS validation CNAME record is still publicly resolvable, then issues a new certificate and automatically deploys it to all attached services. The entire process is invisible: no action required from you, no downtime, no certificate swap.

What breaks renewal: deleting the validation CNAME record. If ACM cannot find the CNAME during the renewal attempt, the renewal fails. ACM sends notification emails to the AWS account root email address, but these are easy to miss if the root account email is not actively monitored. Eventually the certificate expires, HTTPS stops working, and every visitor gets a browser certificate error.

ACM-issued vs imported certificates

# Import an external certificate into ACM
aws acm import-certificate \
  --certificate fileb://certificate.pem \
  --private-key fileb://private-key.pem \
  --certificate-chain fileb://chain.pem \
  --region us-east-1

After importing, the certificate appears in ALB and CloudFront configuration alongside ACM-issued certificates. Set a calendar reminder for renewal: ACM will not do it for you.