How to Install an SSL Certificate on AWS (ACM, ALB and CloudFront)

Where the certificate actually lives

On AWS the certificate sits in Certificate Manager, and the thing you configure elsewhere is a reference to it. ACM stores the certificate and its private key, returns an ARN, and hands the key material to integrated services on your behalf. The key itself is not readable back out of an imported certificate. Every place that needs to serve TLS asks for that ARN, not for a file path.

Two properties of that store shape everything else. ACM is regional, so a certificate imported into eu-central-1 is invisible to a load balancer in eu-west-1; the same PEM files have to be imported again, producing a second ARN. And CloudFront ignores your Region choice entirely: a distribution will only accept a certificate that lives in US East (N. Virginia). A team running ALBs in Frankfurt and Ireland behind a CloudFront distribution is looking at three imports of one certificate, which is worth knowing before you plan the renewal rather than during it.

EC2 is the exception that trips people who expect AWS to be consistent here. An instance running Nginx, Apache or HAProxy is not an ACM-integrated service, so there is no ARN to attach and the certificate has to exist as files on the instance. Either move TLS termination to a load balancer in front of it, or treat the instance the way you would treat any other server. The mechanics of that split are covered in our guide to TLS termination and SSL offloading.

Import your own, or use an ACM certificate?

ACM will issue you a free public certificate, and for a straightforward web application fronted by AWS services that is usually the right answer: it validates by DNS, renews itself, and costs nothing. Three situations push the other way. ACM's free public certificates are domain-validated only, so any requirement for a vetted organization identity rules them out. Certificates ACM issues are locked to AWS-integrated services unless you pay for the exportable variety. And a certificate you already own for a name served both on and off AWS is simpler to keep as one certificate than to split in two.

The exportable option is worth knowing about because it changed the calculus in 2025. Since June 17, 2025, ACM can issue public certificates whose private key you are allowed to export and install on EC2, containers or on-premises hosts, billed per name instead of free and unavailable for any certificate issued before that date. AWS repriced them in February 2026 when it cut default validity to 198 days to meet the new CA/Browser Forum ceiling.

If the requirement is organization validation, meaning a certificate that names your company after a CA has checked that the company exists, then importing is the route. That certificate comes from a commercial CA, not from AWS. Our OV SSL certificates are issued by Certum and arrive as the PEM files this import expects. Whichever you choose, the difference between validation levels is explained in OV vs EV SSL certificates.

Preparing the three files ACM accepts

ACM takes three PEM-encoded inputs and is strict about all three. The certificate field holds your certificate alone. The chain field holds the intermediates that lead back to a root, ordered so each certificate directly certifies the one before it, and your own certificate must not appear in it. The private key must be unencrypted, carry no passphrase, and stay at 5 KB or under. AWS also asks that you add no lines, spaces or other edits to a PEM file while copying it, which sounds pedantic until an editor silently strips a trailing newline.

Most CAs deliver a bundle that concatenates the leaf and the intermediates into one file. Splitting it is a two-minute job: the first BEGIN CERTIFICATE block is yours, and everything after it belongs in the chain file.

# Confirm what you were sent, and in what order
openssl crl2pkcs7 -nocrl -certfile bundle.pem \
  | openssl pkcs7 -print_certs -noout

# Check the private key matches the certificate before importing
openssl x509 -noout -modulus -in certificate.pem | openssl md5
openssl rsa  -noout -modulus -in private-key.pem | openssl md5

# Strip a passphrase if the key has one
openssl rsa -in private-key.pem -out private-key-plain.pem

The two modulus hashes have to match. When they do not, you are holding a key from a different CSR, and no amount of retrying the import will help; the certificate has to be reissued against the right key. If you are unsure which format your CA sent, our reference on SSL certificate formats covers converting PFX and P7B into the PEM files ACM wants.

One constraint worth checking before you generate the CSR at all: ACM accepts RSA at 1024, 2048, 3072 and 4096 bits and ECDSA on the P-256, P-384 and P-521 curves, but the services downstream accept less than that. CloudFront in particular supports a narrower set for connections to viewers, so a P-521 certificate can import without complaint and then fail to appear in the distribution's certificate picker. RSA 2048 or ECDSA P-256 avoids the question.

Importing the certificate

The import itself is one command or one console form, and it returns the ARN you will use everywhere else. In the console the path is Certificate Manager, Import certificate, then three text boxes matching the three files. From the CLI, pass each file with the fileb:// prefix instead of file://. Reading the files as binary sidesteps a class of encoding errors that otherwise surface as an unhelpful validation message.

aws acm import-certificate \
  --certificate       fileb://certificate.pem \
  --certificate-chain fileb://chain.pem \
  --private-key       fileb://private-key.pem \
  --region eu-central-1

# Returns:
# { "CertificateArn": "arn:aws:acm:eu-central-1:111122223333:certificate/6a1b…" }

Tag it while you are there. An imported certificate carries no record of where it came from, and in eighteen months the person renewing it will want to know which CA issued it and which internal ticket paid for it. A --tags argument at import time costs nothing and saves that archaeology.

Repeat the command once per Region that needs the certificate, adding a separate --region us-east-1 import if CloudFront is in the picture. Each returns its own ARN. Record all of them somewhere your renewal process will look, because the second Region is the one people forget.

Attaching it to an ALB or CloudFront

Attaching means creating or updating an HTTPS listener that references the ARN. On an Application Load Balancer you add a listener on port 443 with the certificate attached and a security policy chosen; the certificate has to be in the load balancer's own Region. On CloudFront you set the alternate domain names and pick the certificate from us-east-1. API Gateway custom domains and several other services follow the same shape.

# ALB: add an HTTPS listener using the imported certificate
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:eu-central-1:111122223333:loadbalancer/app/prod/… \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=arn:aws:acm:eu-central-1:111122223333:certificate/6a1b… \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:…

# Or attach an additional certificate to an existing listener (SNI)
aws elbv2 add-listener-certificates \
  --listener-arn arn:aws:elasticloadbalancing:… \
  --certificates CertificateArn=arn:aws:acm:…

A load balancer listener can hold more than one certificate and pick between them using SNI, which is how one ALB serves several unrelated domains. The first certificate you attach becomes the default, served to any client that does not send a server name.

Once the listener is live, check the chain from outside AWS rather than trusting the console's green tick. The console confirms that ACM holds a certificate; it says nothing about whether the intermediates you supplied are the ones clients need to build a path. Our SSL checker reports what the endpoint actually presents, and how certificate chains work explains what you are looking at if something is missing.

CloudFront updates are asynchronous. After you change or replace a certificate on a distribution, AWS notes that the change can take up to 24 hours to be reflected, so a distribution that still shows the previous certificate an hour later is normal rather than broken.

When TLS terminates on EC2 instead

An EC2 instance cannot use an ACM ARN, so the certificate has to reach the instance as files and the web server has to be told where they are. This is ordinary certificate installation, and the AWS-specific part is only how the files get there: an artifact store such as S3 with an instance role, a secret in Secrets Manager or Parameter Store read at boot, or a configuration-management run.

Two of the three routes onto an instance start with an ACM certificate anyway. An exportable public certificate can have its key downloaded and written to disk; a certificate from a commercial CA arrives as files already. Whichever you use, the renewal problem moves with it. A file on disk has to be replaced and the web server reloaded, and nothing in ACM does that for you. Our platform guides for Nginx and Apache cover the server-side configuration in full.

For containerized workloads the same logic applies one layer up. Fargate tasks behind an ALB let ACM hold the certificate and keep TLS out of the image entirely, which is usually the cleaner arrangement. On EKS, a controller can pull certificates in for you; the pattern is described in our guide to running cert-manager against a commercial CA.

Renewal: reimport to the same ARN

ACM does not renew certificates it did not issue. AWS is explicit about it: imported certificates have to be reissued by the CA and reimported before they expire, and no managed renewal is attempted. What ACM gives you instead is notice: daily expiration events published to EventBridge for every active certificate including imported ones, starting 45 days out. That 45-day window is the default and can be narrowed to as little as one day through the PutAccountConfiguration API, but not widened; for earlier warning you build your own EventBridge rule or CloudWatch alarm.

The detail that decides how painful this is arrives at the moment you have the replacement in hand. Import it as a new certificate and you get a new ARN, which means finding every listener, distribution and Terraform reference pointing at the old one. Reimport it into the existing ARN and AWS preserves both the ARN and the certificate's service associations, then deploys the new certificate to those attached resources itself. The command is the same one you already ran, with the ARN added.

aws acm import-certificate \
  --certificate-arn   arn:aws:acm:eu-central-1:111122223333:certificate/6a1b… \
  --certificate       fileb://certificate-2027.pem \
  --certificate-chain fileb://chain-2027.pem \
  --private-key       fileb://private-key-2027.pem \
  --region eu-central-1

Reimport comes with one condition worth planning around: the replacement has to cover the same domain names and subject alternative names as the certificate it replaces. Adding a hostname means a fresh import and a new ARN, so a certificate whose SAN list changes every quarter is a poor candidate for this pattern. Keeping the name list stable is what lets you treat the ARN as a permanent fixture in your infrastructure code.

The arithmetic behind that figure is what turns a minor operational preference into a decision. Under CA/Browser Forum ballot SC-081v3, the maximum lifetime of a public TLS certificate fell to 200 days on March 15, 2026, drops to 100 days on March 15, 2027, and reaches 47 days on March 15, 2029. A 200-day certificate needs replacing about twice a year; a 47-day one, roughly eight times. Multiply by the Regions holding a copy and the ALB estate in each, and a process that was a calendar reminder becomes something that needs a script.

One quota is worth a glance at that point. ACM's defaults allow 2,500 imported certificates in a Region and 5,000 imports into that Region across a rolling 365 days, and reimports count toward the second number. At two replacements a year that ceiling is irrelevant. At eight, a Region holding several hundred certificates is inside the same order of magnitude as the annual limit, and a quota increase through Service Quotas is much easier to request before you need it. Our broader notes on preparing for 47-day certificates cover the same shift outside AWS.

Why ACM rejects a certificate that looks fine

Import failures cluster into a handful of causes, and the error text rarely names the real one. The single most common is a chain field containing your own certificate. The bundle from the CA went in whole, so the leaf appears twice and ACM reports that the certificate field holds more than one certificate, or that the chain cannot be validated. The second is an encrypted private key, which is any key with a passphrase. The third is a certificate outside its validity window, since ACM refuses anything not yet valid or already expired.

When an import that worked last year fails today with unchanged tooling, look at the files, not at ACM. A CA that changed its issuing intermediate between orders will have sent a different chain, and a chain assembled from last year's saved copy no longer leads anywhere.