Skip to content

How do I troubleshoot a 502 "The request could not be satisfied" error in CloudFront?

5 minute read
2

I configured an Amazon CloudFront distribution with a custom domain. I want to troubleshoot the 502 "The request could not be satisfied" error that I receive when I use CloudFront to request the alternative Canonical Name (CNAME) domain.

Resolution

CloudFront can't resolve the origin IP address

If CloudFront can't resolve the origin domain, then it returns the "The request could not be satisfied" error. Unless your distribution uses only Amazon Virtual Private Cloud (Amazon VPC) Origins, CloudFront must be able to resolve your origin domain through public DNS queries.

You don't need to make your origin publicly accessible, but you must be able to publicly query its domain. To troubleshoot this issue, use a dig or nslookup command to determine whether the origin domain resolves to an IP address.

If you use Linux, then run the following command:

dig ORIGIN_DOMAIN_NAME

If you use Windows, then run the following command:

nslookup ORIGIN_DOMAIN_NAME

Note: Replace ORIGIN_DOMAIN_NAME with your origin's domain name.

The commands return the IP address of the origin domain name. Use a DNS checker tool to check for DNS resolution across different geographies. For example, you can use the Check DNS propagation tool on the DNS Checker website. Check whether verification methods fail to query your origin's domain. Then, contact your public DNS provider to confirm that a publicly resolvable DNS record exists for the origin domain.

For more DNS troubleshooting, see How does DNS work, and how do I troubleshoot partial or intermittent DNS failures?

The SSL/TLS certificate doesn't match the domain name

The SSL/TLS certificate at the origin must include one of the following domain names:

  • The origin domain name in the certificate's Common Name field or Subject Alternative Names field.
  • The host header's domain name for incoming viewer host headers that the request forwards to the origin in the CloudFront distribution.

To check for the Common Name and Subject Alternative Names in the certificate, run the following command:

openssl s_client -connect DOMAIN:443 -servername SERVER_DOMAIN | openssl x509 -text | grep -E '(CN|Alternative)' -A 2

Note: Replace DOMAIN with the origin domain name and SERVER_DOMAIN with the origin domain name. If the request forwards the viewer's host header to the origin, then replace SERVER_DOMAIN with the incoming host header value.

You must configure the cache policy or origin request policy to include the host header in the following scenarios:

  • The origin's certificate includes the viewer host header value as either the SSL/TLS certificate's common name or the subject alternative name (SAN).
  • The request doesn't forward the host header to the origin.

The origin certificate is expired, not trusted, self-signed, or the certificate chain is in the wrong order

A trusted certificate authority (CA) must sign the certificate that you installed on the custom origin. For a list of trusted CAs, see Certificate authorities on the Mozilla website. CloudFront doesn't support origins that use self-signed SSL/TLS certificates.

To check whether your origin certificate is expired, run the following OpenSSL command:

openssl s_client -connect DOMAIN:443 -servername SERVER_DOMAIN | openssl x509 -text | grep Validity -A 3

Note: Replace DOMAIN with the origin domain name and SERVER_DOMAIN with the origin domain name. If the request forwards the viewer's host header to the origin, then replace SERVER_DOMAIN with the incoming host header value.

In the command's output, find the Not Before and Not After parameters. Confirm that the current date and time is within the certificate's validity period.

Missing intermediate CA certificates or an incorrect order of intermediate certificates cause communication to fail between HTTPS and the origin.

To check the certificate chain, run the following command:

openssl s_client -showcerts -connect DOMAIN:443 -servername SERVER_DOMAIN

Note: Replace DOMAIN with the origin domain name and SERVER_DOMAIN with the origin domain name. If the request forwards the viewer's host header to the origin, then replace SERVER_DOMAIN with the incoming host header value.

For more information, see Requirements for using SSL/TLS certificates with CloudFront.

CloudFront doesn't support the origin's cipher suite

SSL/TLS transactions between CloudFront and the origin fail when there's no common negotiated ciphers suite. To resolve this issue, you must use supported protocols and ciphers.

Use an SSL server test tool to check whether the list of supported ciphers includes your origin's cipher suite. For example, you can use the SSL server test on the Qualys website.

There are upstream origin issues

You can use a proxy Content Delivery Network (CDN) hostname or load balancer that's connected to the origin as a custom origin in the CloudFront distribution. If one of these intermediary services fails to connect to the origin, then you receive a 502 error. To resolve this issue, work with your origin service provider.

If you use an Application Load Balancer as your origin, then see How do I troubleshoot Application Load Balancer HTTP 502 errors?

If you use Amazon API Gateway, then see How do I resolve HTTP 502 errors from API Gateway REST APIs with Lambda proxy integration?

The Lambda@Edge function that's associated with the CloudFront distribution failed validation

If the Lambda@Edge function returns a response to CloudFront that isn't valid, then CloudFront returns a 502 error. To resolve this issue, check your Lambda@Edge function for the following issues:

  • The JSON object is returned.
  • Required fields are missing.
  • Objects in the response aren't valid.
  • The ability to add or update isn't allowed.
  • The headers are read-only.
  • You exceeded the maximum body size.
  • Characters or values aren't valid.

To resolve these issues, see Test and debug Lambda@Edge functions. Also, see How do I troubleshoot 502 and 503 errors caused by Lambda@Edge functions in CloudFront?

AWS OFFICIALUpdated 8 months ago
1 Comment

For me I needed to disable the default SSL site in apache in SSH:

sudo a2dissite default-ssl.conf

I assume Cloudfront was using the IP address and not the origin domain name, so it got sent to the default blank site instead, but that's just a guess.

replied a year ago