The certificate has been issued, the browser shows a padlock, and the site works on your own computer. Yet support tickets still arrive: an older phone cannot open the site, a desktop application reports a certificate error, or the CDN occasionally returns a 502 response.

In many cases, the problem is not whether a certificate was installed. The real issue is that different clients or network paths receive different certificates, different certificate chains, or different TLS policies.

Do not rely on a single browser refresh when troubleshooting. A browser may have cached an intermediate certificate, and repeated tests may keep reaching the same CDN edge. First determine whether the failure occurs between the client and the CDN edge or between the CDN and the origin. Then check the certificate chain, SNI, hostname coverage, TLS versions, and network path.

Narrow Down the Failure by Symptom

Record the failing device, network, time, hostname, and complete error message. “The site does not open” is not enough to distinguish a DNS, TCP, TLS, or HTTP problem.

Step 1: Confirm Which Certificate the Client Actually Receives

Run the following command from a network where the failure can be reproduced:

curl -Iv https://www.example.com/

Check the connected IP address, negotiated TLS version, certificate subject, issuer, validity dates, verification result, and final HTTP status.

Next, inspect the certificate list returned by the server:

openssl s_client \
  -connect www.example.com:443 \
  -servername www.example.com \
  -showcerts \
  -verify_return_error </dev/null

The -servername option sends SNI, while -showcerts displays the certificates actually provided by the server. Do not stop after checking the expiration date of the leaf certificate. Confirm that the correct intermediate certificate or certificates follow it.

You can also extract commonly needed fields:

openssl s_client \
  -connect www.example.com:443 \
  -servername www.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName

If the requested hostname is missing from subjectAltName, clients will reject the certificate even if it has not expired.

Step 2: Check Whether the Certificate Chain Is Complete

A server normally sends the leaf certificate together with the required intermediate certificates. It should not depend on clients receiving the root certificate as part of the served chain.

If only the site certificate is configured, a desktop browser may still work because it cached or fetched the missing intermediate. Older devices, Java applications, command-line clients, and restricted environments may fail instead.

The usual fix is to use the full-chain file supplied by the certificate authority. In Nginx, for example, the file referenced by ssl_certificate should contain the site certificate first, followed by the intermediate certificates in signing order:

server {
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
}

Back up the existing configuration and certificate files before making changes. Then validate and reload Nginx:

sudo nginx -t
sudo systemctl reload nginx

Reload only after nginx -t succeeds. Never upload a private key to an online test service or paste it into a support ticket or chat.

When a CDN is involved, verify two separate chains: the chain presented by the CDN edge to visitors and the chain presented by the origin when the CDN connects over HTTPS. A valid edge certificate does not prove that the origin certificate is valid.

Step 3: Troubleshoot SNI and Hostname Binding

A single server or CDN edge can host many HTTPS domains. During the TLS handshake, SNI tells the server which hostname the client wants, allowing the server to choose the correct certificate.

A client may receive the default certificate when the hostname is not bound to the correct virtual host, a CDN deployment is incomplete, or an application connects to an IP address without sending SNI.

Compare a request with SNI and one without it:

# Normal hostname-based request
openssl s_client -connect 203.0.113.10:443 \
  -servername www.example.com </dev/null

# Simulate a client that does not send SNI
openssl s_client -connect 203.0.113.10:443 \
  -noservername </dev/null

If the two commands return different certificates, review the Nginx or Apache virtual hosts, CDN hostname and certificate bindings, SAN coverage, and any health checks or origin rules that use an IP address incorrectly.

When testing an origin by IP, let curl keep the correct hostname and SNI value:

curl -Iv --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/

This is much closer to a real request than opening https://203.0.113.10/ directly.

Step 4: Verify TLS Versions and Security Policies

Some older systems do not support TLS 1.3, and some can negotiate only obsolete protocols or cipher suites that should no longer be enabled. At the other end of the spectrum, current clients may reject weak signatures, short keys, or insecure algorithms.

Problems often become concentrated on one device family after a CDN security policy is changed. Test TLS 1.2 and TLS 1.3 separately:

openssl s_client -connect www.example.com:443 \
  -servername www.example.com -tls1_2 </dev/null

openssl s_client -connect www.example.com:443 \
  -servername www.example.com -tls1_3 </dev/null

If TLS 1.2 fails while TLS 1.3 works, check whether the CDN or server minimum version has been set too high. If legacy terminals must remain supported, do not immediately re-enable obsolete protocols. First identify the affected devices and security impact. Prefer client upgrades, a separate compatibility hostname, or a tightly restricted access policy.

Step 5: Check DNS, IPv4/IPv6, and Multiple Nodes

Intermittent failures usually indicate more than one access path. Inspect the A, AAAA, and CNAME records, then test each address family:

dig +short A www.example.com
dig +short AAAA www.example.com
dig +short CNAME www.example.com

curl -4Iv https://www.example.com/
curl -6Iv https://www.example.com/

If IPv4 works but IPv6 fails, verify that the service behind the AAAA record has the same certificate and TLS configuration. For load-balanced or multi-origin deployments, check every backend rather than assuming that all nodes received the renewed certificate.

Also allow for CDN propagation time after a configuration change. Record the connected IP address and repeat the test from more than one network so that a single edge result is not mistaken for the global state.

Step 6: Separate Edge Handshake Failures from Origin Handshake Failures

When a visitor cannot complete TLS with the CDN edge, the client will usually see a certificate, protocol, or handshake error. When the visitor completes HTTPS successfully but the CDN cannot establish TLS with the origin, the public response is more likely to be a 502, 503, or another gateway error.

For CloudFront HTTPS origins, the origin certificate must meet requirements for hostname matching, validity, certificate chain, and a trusted certificate authority. If the certificate returned by the origin does not match the configured Origin Domain Name or the forwarded Host header, CloudFront may return a 502 response.

Use this troubleshooting order:

1. Inspect the edge certificate from the public internet.

2. Test the origin separately with the correct SNI and Host values.

3. Confirm the CDN origin hostname, port, and protocol.

4. Check whether the origin logs received the request.

5. After the fix, retest both the edge path and the origin path.

How to Verify the Fix

Complete at least the following checks:

• OpenSSL verification succeeds and the server sends the complete certificate chain.

• The apex domain, www, and required application subdomains are included in the SAN list.

• TLS 1.2 and TLS 1.3 support matches the intended client base.

• IPv4, IPv6, and major CDN paths return consistent results.

• The origin certificate matches the hostname used by the CDN.

• The previously failing device, or a representative test environment, can connect again.

• Certificate renewal is followed by automatic loading or deployment to the web server and CDN.

The most common mistake in HTTPS troubleshooting is assuming that a successful test in one browser proves the deployment is complete. Reliable HTTPS requires consistent hostnames, certificate chains, SNI handling, TLS policy, DNS paths, and origin settings. Test the edge and origin separately, then repeat the check across the affected device and network types.

References

1. AWS CloudFront Developer Guide: Requirements for using SSL/TLS certificates with CloudFront   https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-requirements.html

2. AWS CloudFront Developer Guide: HTTP 502 status code (Bad Gateway)   https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html

3. OpenSSL Documentation: openssl-s_client   https://docs.openssl.org/master/man1/openssl-s_client/

4. curl Documentation: SSL certificate verification   https://curl.se/docs/sslcerts.html

5. NGINX Documentation: Configuring HTTPS servers   https://nginx.org/en/docs/http/configuring_https_servers.html

6. Let’s Encrypt: Chain of Trust   https://letsencrypt.org/certificates/

Sources checked on September 16, 2026.