AWS ALB listener certificate expired

aws alb ssl certificate expired means the Application Load Balancer listener—not your Auto Scaling instances—presents a leaf past notAfter on the hostname customers resolve in Route 53.

ALBs terminate TLS on the listener certificate and optional additional certificates selected by SNI host-header rules. Target groups speak HTTP or separate TLS to backends; renewing a cert on EC2 does not update what browsers see on the ALB DNS name or your branded alias.

ACM often auto-renews in us-east-1 or regional accounts, but attachment to the listener still fails when validation records lapse or teams import a new cert without swapping the listener ARN. Incidents look like uniform 502 or TLS warnings across every target.

You will map the listener, list certificates, renew or import in ACM, modify listener bindings, and openssl the Route 53 alias your users type.

What to check

Identify the public hostname (customer DNS) and whether it aliases the ALB or a CloudFront distribution in front. Openssl must use that hostname with SNI, not the internal target hostname.

Collect the load balancer ARN, HTTPS listener ARN, default certificate ARN, and any rule-priority SNI certificates. Default listener cert may differ from the cert served for api.example.com on rule priority 10.

For ACM certificates, confirm status ISSUED and that DNS validation CNAMEs still exist in the authoritative zone. EXPIRED or VALIDATION_TIMED_OUT in ACM explains listener attachment of stale material.

Compare with load balancer presenting an expired certificate when multiple cloud edges stack—only the outermost listener matters for browser errors.

Tag load balancers and listeners in AWS Resource Groups so on-call can find ARNs during pager events. Export a monthly report from AWS Config or your CMDB that pairs Route 53 alias targets with listener default certificate ARNs. Hybrid estates that terminate TLS on both ALB and CloudFront need two renewal tracks; this guide covers ALB only.

Step-by-step

Confirm expiry externally

HOST=app.example.com
echo | openssl s_client -connect "${HOST}:443" -servername "${HOST}" 2>/dev/null \
  | openssl x509 -noout -dates -serial -subject

Find the ALB and listener (AWS CLI)

aws elbv2 describe-load-balancers --names my-alb --query 'LoadBalancers[0].LoadBalancerArn' --output text
LB_ARN="arn:aws:elasticloadbalancing:region:acct:loadbalancer/app/my-alb/..."
aws elbv2 describe-listeners --load-balancer-arn "$LB_ARN" \
  --query 'Listeners[?Port==`443`].[ListenerArn,Certificates[0].CertificateArn]' --output table

Save LISTENER_ARN from output.

List all certificates on the listener

aws elbv2 describe-listener-certificates --listener-arn "$LISTENER_ARN" --output table

Match CertificateArn values to the serial openssl showed (via ACM describe) or note which ARN still maps to expired material.

Inspect ACM status

aws acm describe-certificate --certificate-arn "$CERT_ARN" \
  --query 'Certificate.{Status:Status,NotAfter:NotAfter,DomainName:DomainName,Validation:DomainValidationOptions}' \
  --output yaml

If status is not ISSUED, fix DNS validation records Route 53 or your DNS vendor hosts, then wait for reissuance.

Attach renewed certificate

When ACM issued a replacement cert with a new ARN:

aws elbv2 add-listener-certificates --listener-arn "$LISTENER_ARN" \
  --certificates CertificateArn="$NEW_CERT_ARN"
aws elbv2 remove-listener-certificates --listener-arn "$LISTENER_ARN" \
  --certificates CertificateArn="$OLD_CERT_ARN"

To change the default certificate:

aws elbv2 modify-listener --listener-arn "$LISTENER_ARN" \
  --certificates CertificateArn="$NEW_CERT_ARN"

Console path (same operations)

In EC2 → Load Balancers, select the ALB → Listeners tab → select the HTTPS:443 listener → View/edit certificates. Add the new ACM certificate, set it as default if needed, remove the expired ARN, and save.

Verify after change

curl -vI --connect-timeout 10 "https://${HOST}/" 2>&1 | grep -Ei 'expire|SSL certificate|subject'

Re-run openssl; serial and notAfter must change. No target group deregistration is required for cert-only swaps.

SNI rules when only one hostname fails

aws elbv2 describe-rules --listener-arn "$LISTENER_ARN" --output table

Rules with host-header conditions may attach alternate certificate ARNs. Renew the ARN referenced on the failing rule priority, not only the default listener certificate.

Route 53 alias sanity

aws route53 list-resource-record-sets --hosted-zone-id ZONE_ID \
  --query "ResourceRecordSets[?Name=='app.example.com.']"

Confirm the alias target matches the load balancer you updated. Stale aliases to retired load balancers produce openssl results that look like a failed cert swap when you edited the wrong ARN.

How to read the output

describe-listener-certificates shows IsDefault true on the cert browsers get when SNI does not match a more specific rule. Listener rules with Host header conditions may attach alternate ARNs—grep rule priorities in describe-rules when only one hostname fails.

ACM NotAfter in describe-certificate is authoritative for managed certs. If ACM shows future NotAfter but openssl does not, you are still attached to the wrong ARN or hitting a different load balancer via stale DNS.

ELB DNS name check: openssl against the load balancer DNS without matching ServerName may show the default cert’s dates—always pass the customer hostname.

Health checks over HTTPS on targets are unrelated to listener expiry, yet tickets bundle them. Clarify in the incident channel that target group health can stay green while listener TLS fails—executives understand faster when you openssl the customer hostname first.

Change records should cite both old and new certificate ARN and attach openssl before and after transcripts. auditors and partner integrations use those attachments when proving contract compliance after aws alb ssl certificate expired events.

Common mistakes

Renewing on instances while the listener still references last year’s default certificate ARN.

Importing a renewed cert into ACM as a new ARN without removing the expired listener binding—both appear until you remove-listener-certificates.

Letting ACM validation CNAMEs lapse during a DNS migration, so auto-renew never completes while the old cert expires.

Forgetting us-east-1 only applies to CloudFront-associated ACM certs—regional ALBs need certs in the same region as the load balancer.

Testing only the amazonaws.com DNS name of the ALB when users hit a Route 53 alias with different SNI rules.

Assuming AWS ACM automatic renewal failed messages mean listeners self-update without describe-listener-certificates proof.

Using describe-load-balancers in the wrong region—ALB ARNs are regional; CLI profiles must match the workload region.

Closing incidents without saving listener ARN and certificate ARN in the ticket—same failure repeats next year because nobody recalls which rule held api.example.com.

When to use automation

Elastic architectures recreate targets hourly; the stable TLS identity is the listener ARN set. Track live TLS on the customer hostname in Route 53, not inventory tags on EC2.

ssldays presents the live leaf (issuer, SANs, chain, expiry) and alerts at 30, 14, 7, and 1 days. RDAP on the registration helps when validation needs a healthy apex zone. Email on all plans; Slack and Discord on Starter and Pro; three domains daily free, twenty-five hourly Starter, one hundred Pro.

Probe from /check after every listener change, then /register for ongoing watches. If CloudFront sits in front, also read CloudFront custom SSL certificate expired.