InvalidViewerCertificate
AWS InvalidViewerCertificate (Cloud Front Invalid Viewer Certificate) means the viewer certificate settings are invalid. In the CloudFront API, this error returns HTTP 400.
Last reviewed: May 4, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Invalid Viewer Certificate Mean?
CloudFront rejected the viewer TLS configuration, so distribution update cannot deploy until certificate, alias coverage, and TLS policy settings are valid.
Common Causes
- -Certificate ARN, SAN coverage, or alias mapping is invalid for the distribution.
- -TLS security policy and certificate settings are incompatible.
- -Certificate region/account prerequisites for CloudFront are not satisfied.
- -Distribution update references stale or incorrect certificate configuration.
How to Fix Invalid Viewer Certificate
- 1Use a valid certificate with alias coverage for all configured CNAMEs.
- 2Align TLS policy with supported CloudFront certificate options.
- 3Validate certificate status and ownership prerequisites before update.
- 4Retry distribution update after certificate settings are normalized.
Step-by-Step Diagnosis for Invalid Viewer Certificate
- 1Inspect viewer-certificate block and referenced certificate ARN.
- 2Check SAN/domain coverage against distribution aliases.
- 3Validate certificate status, chain, and CloudFront compatibility constraints.
- 4Compare failing config with a known-working certificate profile.
Certificate and Alias Coverage Validation
- -Verify certificate covers every configured alternate domain name (example: one CNAME missing from SAN list triggers InvalidViewerCertificate).
- -Confirm certificate source prerequisites for CloudFront (example: ACM certificate must be in us-east-1 for viewer certificate usage).
TLS Policy and Deployment Contract Checks
- -Audit viewer certificate block against allowed TLS policy combinations (example: minimum protocol policy conflicts with selected cert option).
- -Diff rendered distribution config against known-good certificate profile (example: stale cert ARN in one environment template).
Decision Shortcut: Region vs SAN Coverage vs Alias Conflict
- -If the ACM certificate is not in
us-east-1, replace it with a CloudFront-compatible viewer certificate before debugging aliases. - -If the certificate is in
us-east-1but aliases are missing from SAN coverage, reissue or select a certificate covering every alternate domain name. - -If SAN coverage is correct but the alias is already attached elsewhere, investigate
CNAMEAlreadyExistsrather than certificate validity.
Wrong Fix to Avoid
- -Do not bypass TLS validation by removing aliases from the distribution unless you also plan the DNS and user-facing hostname impact.
- -Do not attach a regional ACM certificate used by an ALB and expect CloudFront viewer TLS to accept it outside
us-east-1. - -Do not update DNS before CloudFront accepts the viewer certificate; clients can be routed to a distribution that cannot present the intended certificate.
Implementation Examples
DISTRIBUTION_ID=E1234567890ABC
CERT_ARN=arn:aws:acm:us-east-1:111122223333:certificate/abcd-1234
aws cloudfront get-distribution-config \
--id "$DISTRIBUTION_ID" \
--query 'DistributionConfig.{aliases:Aliases.Items,viewerCertificate:ViewerCertificate}'
aws acm describe-certificate \
--region us-east-1 \
--certificate-arn "$CERT_ARN" \
--query 'Certificate.{status:Status,domain:DomainName,sans:SubjectAlternativeNames,notAfter:NotAfter}'for host in www.example.com api.example.com; do
echo | openssl s_client -servername "$host" -connect "$host:443" 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
doneIncident Timeline
15:18 UTC
Deployment renders a new CloudFront distribution config
Signal: IaC includes alternate domain names and a viewer certificate ARN for the distribution update.
Why it matters: Capture the rendered aliases and certificate ARN together; certificate validity depends on the complete alias set.
15:20 UTC
CloudFront rejects viewer certificate settings
Signal: UpdateDistribution or CreateDistribution returns InvalidViewerCertificate before the config deploys to edge locations.
Why it matters: The failure is in certificate, alias, region, chain, or TLS policy validation, not in origin reachability.
15:28 UTC
Certificate profile is compared against aliases
Signal: ACM shows certificate region, status, SANs, and validation state; CloudFront config shows the aliases that must be covered.
Why it matters: The fastest fix is usually selecting or issuing the correct certificate, then rerunning the same distribution update.
15:45 UTC
Distribution update succeeds and TLS is verified at the edge
Signal: CloudFront accepts the config, deployment completes, and openssl s_client shows the expected certificate for each hostname.
Why it matters: Finish by adding pre-deploy SAN, status, region, and expiry checks so the next cert rotation fails before CloudFront update time.
Seen in Production
Distribution aliases include domain missing from certificate SAN list
Frequency: common
Example: Update fails because attached certificate does not cover all configured CNAME entries.
Fix: Issue/attach certificate with complete SAN coverage for every alias in distribution.
Certificate ARN points to unsupported region for CloudFront usage
Frequency: rare
Example: Deployment references non-us-east-1 ACM certificate and CloudFront rejects viewer certificate config.
Fix: Use CloudFront-compatible ACM certificate in required region and redeploy.
Wrong Fix vs Better Fix
DNS-first rollout vs certificate-first gate
Wrong fix: Point DNS at the distribution before CloudFront has accepted and deployed the viewer certificate.
Better fix: Validate certificate region, status, chain, SAN coverage, and TLS policy before changing DNS records.
Why this is better: Users avoid handshake failures because the edge is ready to serve the hostname before traffic arrives.
Partial SAN workaround vs complete certificate coverage
Wrong fix: Remove one failing alias from the deployment to make the update pass and handle it later manually.
Better fix: Issue or select a certificate that covers every configured alternate domain name and keep aliases/certificates checked in together.
Why this is better: The distribution config remains truthful, repeatable, and safe for future certificate rotations.
Debugging Tools
- -Certificate ARN/SAN checks
- -CloudFront distribution traces
- -AWS CLI --debug
- -TLS handshake validation tools
How to Verify the Fix
- -Re-run distribution update and confirm certificate config is valid.
- -Validate TLS handshake and certificate presentation at edge endpoints.
- -Confirm no repeated viewer-certificate validation errors.
How to Prevent Recurrence
- -Automate certificate-domain coverage checks before CloudFront deploys.
- -Track certificate expiry and renewal readiness with alerts.
- -Pin supported TLS policy/certificate combinations in templates.
Pro Tip
- -run pre-deploy certificate gate checks that validate SAN coverage, certificate status, and us-east-1 placement before any CloudFront update step.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.