Skip to content

← Blog

CDN SSL Mismatch: How to Find and Fix It

By Nick Phillips, Founder

CDN SSL Mismatch: How to Find and Fix It

Hand-drawn CDN and certificate title card

A CDN SSL mismatch means the certificate presented on one leg of the connection doesn’t cover the hostname being asked for. That leg is either browser to CDN or CDN to origin. Fixing it starts with working out which leg is failing, then reading the certificate that leg actually serves. Replacing certificates at random doesn’t help. Below is the sequence we use, with the error codes you’ll meet on Cloudflare and CloudFront.

Otterwatch
otterwatch.dev
Catch Certificate Expiry Before It Breaks
Otterwatch watches your SSL certificates and checks that your sites are up, sending a friendly warning before certificates expire.
Visit Otterwatch

TL;DR

  • There are two TLS connections behind every CDN site: visitor to CDN edge, and CDN edge to your origin. A mismatch can live on either one, and they need separate checks.
  • Name mismatch means the hostname requested isn’t listed in the certificate’s SAN entries. Typical culprits are a missing apex name, a wildcard that’s one level too shallow, or an origin reached under a different name than the one you issued for.
  • Read the certificate the CDN actually serves (with openssl s_client or a checker) before you change anything.
  • Never fix this with “proceed anyway” in the browser. Fix the certificate or the origin mapping, then retest from an outside network.

Table of Contents

Two connections, two places to mismatch

A CDN sits in the middle, so there are two handshakes. First the visitor’s browser connects to the CDN edge and sends the hostname it wants (via SNI, Server Name Indication). The edge answers with a certificate. Second, the CDN opens its own connection to your origin server, using whatever origin hostname you configured, and your origin answers with a certificate of its own.

A mismatch on the first leg shows up in the browser as a name error (NET::ERR_CERT_COMMON_NAME_INVALID in Chrome, for example). A mismatch on the second leg usually shows up as a CDN error page instead: a 502 or a 5xx code from your CDN, while the browser’s own padlock looks fine.

That’s why “my certificate is valid” and “my site is broken” can both be true. You tested one leg. The other one failed.

Symptom Likely leg First thing to check
Browser warning about the name on the certificate Visitor to CDN SANs on the edge certificate vs. the hostname in the address bar
Cloudflare Error 1013 or HTTP 421 Visitor to CDN SNI hostname vs. HTTP Host header
CloudFront 502 with X-Cache: Error from cloudfront CDN to origin Origin certificate vs. the configured Origin Domain or Host header
Cloudflare 526 CDN to origin Whether the origin certificate is valid and trusted
Only some subdomains fail Visitor to CDN Wildcard depth, missing apex, missing custom hostnames

What the error codes actually tell you

Cloudflare 1013 and 421

Per Cloudflare’s documentation, Error 1013 means the hostname in the TLS SNI extension doesn’t match the HTTP Host header. A browser or proxy sending the wrong SNI is a common cause. The same docs explain that the related 421 Misdirected Request can appear when a request reaches a server that can’t answer for that scheme and authority. It can also come from HTTP/2 or HTTP/3 connection reuse across origins.

In plain terms: the client said “I’m connecting to a.example.com” at the TLS layer and “give me b.example.com” at the HTTP layer. The edge refuses to guess.

CloudFront 502

AWS documents that a 502 from CloudFront can come from a failed TLS negotiation with a custom origin. If the origin’s certificate name doesn’t match the configured Origin Domain (or the Host header CloudFront forwards), the handshake fails and you see a 502 with X-Cache: Error from cloudfront. Your origin may look perfect when you open it directly, because you’re using a different name than CloudFront does. AWS’s guidance on HTTPS requirements makes the same point: test both legs with the exact names configured in the distribution.

CloudFront origin TLS name mismatch flow

Cloudflare 526

If you’re on Cloudflare with a strict SSL mode, Error 526 means Cloudflare couldn’t validate the certificate on your origin. That covers expired certs, self-signed certs and name mismatches alike. The fix is a valid origin certificate, not dropping to a looser SSL mode and hoping.

Step by step: find the failing leg

Here’s the sequence. It takes about ten minutes once you’ve done it a couple of times.

  1. Write down the exact failing hostname. Not the domain, the full name: www.example.com, api.example.com, shop.eu.example.com. Mismatches often hit one name while the rest of the site loads fine.
  2. Read the certificate the public edge serves. Run this against the hostname visitors use:
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

You want to see your hostname in the SAN list, valid dates, and an issuer you expect. If you’d rather skip the terminal, our free SSL certificate checker shows the same details in plain language. 3. Compare SANs to the hostname. Browsers match against the SAN entries, not the old Common Name field. If the name isn’t in the SAN list, that’s your mismatch. 4. Check DNS and CDN routing. Cloudflare’s HTTPS origins troubleshooting suggests checking the A, AAAA and CNAME records and the route’s service URL. A record pointing at the old host, or a CNAME that never moved to the CDN, will show you someone else’s certificate. Our guide on fast DNS to CA troubleshooting with curl and openssl walks through that angle. 5. Test the CDN-to-origin leg with the configured names. Use the origin hostname from your CDN settings as both the connect target and -servername, then repeat with the Host header the CDN forwards. If one passes and the other fails, you’ve found it. 6. Fix, then retest from outside. Use a network that isn’t your office or VPN, since cached DNS or a split-horizon setup can hide the problem.

The usual suspects

The apex is missing

You issued a certificate for www.example.com, and someone types example.com. Or you issued a wildcard and assumed it covers the bare domain. It doesn’t. A wildcard like *.example.com covers www and api, but not example.com itself. AWS’s alternate domain name docs say the alternate domain must be covered by the certificate, so list the apex explicitly if you serve it. We wrote a short guide on confirming one certificate covers both www and apex.

The wildcard is one level too shallow

A wildcard matches a single label at its level. *.example.com covers app.example.com, but not marketing.product.example.com. If you have nested names (regional, staging or per-customer), you need either a wildcard at that level or SAN entries for each name. Not sure which is right for you? See wildcard vs SAN certificates.

The CDN picks a different certificate than you expected

This one confuses people: you upload a new certificate and nothing changes. Cloudflare’s certificate and hostname priority rules say the edge chooses by hostname specificity first, so an exact-hostname certificate wins over a wildcard. Zone specificity, certificate type and deployment priority come after. An older, more specific certificate can quietly beat the fresh one you just added. Work out which hostname the client sent and which certificate the edge picked before you replace anything.

Origin name and public name aren’t the same

With Cloudflare Tunnel, the public hostname, the service URL, the Host header and the origin SNI are separate values. Cloudflare notes that a Tunnel showing as healthy only proves cloudflared can connect to Cloudflare. It doesn’t prove the routed service is right. If the names differ on purpose, your origin certificate has to be valid for the SNI name actually sent. The same logic applies to CloudFront’s Origin Domain.

The certificate chain or dates are the real problem

Sometimes the “mismatch” is really something else. Browsers treat name mismatch, expiry, an untrusted chain and protocol problems as distinct TLS failures, and the messages can look alike to a stressed human. If the dates in step 2 are in the past, you’re in expiry territory (see what actually happens when your SSL certificate expires). For a wider list of causes, we also keep a domain certificate mismatch guide.

Version or cipher mismatch

An ERR_SSL_VERSION_OR_CIPHER_MISMATCH is a different animal: client and server couldn’t agree on a TLS version or cipher. It’s often tied to a hostname the CDN doesn’t have a certificate for, so it can show up on a brand new subdomain before the certificate is issued. MDN’s implementation guide covers TLS 1.2 and 1.3 as the versions you should be serving. If only old clients fail, check your minimum TLS setting at the CDN.

Why you shouldn’t click through

It’s tempting to tell yourself (or your customers) to click “Proceed anyway.” Don’t. MDN says browsers block these connections because the communication could be compromised and recommends fixing the certificate. On sites using HSTS, browsers don’t offer the bypass at all, so visitors are simply locked out until you serve a valid certificate. The same goes for flipping your CDN to a mode that skips origin validation: it hides the symptom and leaves the connection unverified.

Why you shouldn't click through — overview diagram

If your site is a headless or composable build, with a CMS, a frontend host and a CDN each holding their own hostnames, there are more places for a name to drift. A technical checklist for headless CMS setups is a useful companion when you’re auditing every hostname that serves pages.

A fix checklist you can paste into a ticket

  • Failing hostname: ______
  • Certificate served at the edge (subject, SANs, issuer, expiry): ______
  • Does the SAN list include this exact hostname? yes / no
  • DNS (A, AAAA, CNAME) points where we expect? yes / no
  • CDN origin hostname and forwarded Host header: ______
  • Origin certificate valid for that name? yes / no
  • Fix applied (reissue with correct SANs, correct origin mapping, remove stale exact-match cert): ______
  • Retested from outside network: yes / no

Our perspective: why mismatches keep sneaking back

We built Otterwatch because certificate trouble rarely announces itself. Almost every mismatch we hear about from small teams has the same shape: something changed quietly. A DNS record moved, a new subdomain went live, someone added a custom hostname for a client, and nobody re-read the certificate afterward.

Our view is that a mismatch isn’t a one-off bug. It’s what happens when the certificate and the list of hostnames you actually serve drift apart. The fix on the day is the easy part. The lasting fix is to check what’s served on a schedule, so the first person to notice isn’t a customer.

That’s also why we keep Otterwatch calm. You get a plain email from Otis, our park ranger otter, when a certificate is close to expiring or a site stops answering. No wall of red, no graphs to interpret. For a solo founder or a two-person agency, that’s the right amount of attention.

— Nick Phillips

Keep an eye on it so you don’t redo this

The quickest first step is the free SSL certificate checker: paste the failing hostname and see the served certificate in plain language. When you want that watched continuously, Otterwatch’s Free plan covers up to five sites with expiry and uptime alerts by email, no credit card required. The Pro plan is $15 per month and adds deeper certificate monitoring. See the pricing page for what’s included.

For a broader routine, our SSL debugging checklist for developers and signs your certificate is failing are good bookmarks, and the full list lives on our blog.

FAQ

How do I fix an SSL certificate name mismatch behind a CDN?

Find out which hostname fails, then read the certificate served for it and compare its SAN entries to that exact name. If the name is missing, reissue the certificate with it included and attach it to the CDN. If the name is present, look at DNS, CDN routing and the origin mapping instead.

Why does my site work directly on the origin but fail through the CDN?

The CDN usually connects to your origin using a different hostname or Host header than the one you use when testing. Your origin certificate may be valid for one name and not the other. Test with the exact Origin Domain and Host header configured in the CDN.

Does a wildcard certificate cover my bare domain?

No. *.example.com covers one label, such as www or api, but not example.com and not deeper names like a.b.example.com. Add the apex as a SAN, and add any deeper names you serve.

I installed a new certificate and the error didn’t change. Why?

Your CDN may still be selecting a different certificate. On Cloudflare, an exact-hostname certificate takes precedence over a wildcard, so a stale specific one can win. Check which certificate the edge returns for that hostname, and retest from a network that hasn’t cached the old result.

Can I just tell users to bypass the warning?

No. Browsers block these connections on purpose, and sites with HSTS don’t allow the bypass at all. Fix the certificate or the origin configuration instead.

Sources

Catch the next cert expiry before your users do.

Otterwatch checks your SSL certificates daily and emails you 30 days before they expire. Five sites free.

Start watching →