The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.

Before reading this, I assume you've done all the proper troubleshooting and you are 100% sure the CDN and backend server is configured correctly.

This can often happen with load balancer's and CDNs if the CDN/balancer to backend server don't use the same ports.

Let's use this example.

On CDN Provider, you define Backend/Origin Server A for www.cooldomain.com

When a user hits CDN Provider with their request host as www.cooldomain.com,your CDN then translates that to a backend server.

Let's say the backend server is 1.2.3.4 on port 30000.

Usually the real backend service listens on say Apache port 443 for SSL, you are getting this as an SNI error because the port doesn't match.  Apache or whatever service wants to know the real user port is 443, but you are being redirected from port 30000 which breaks SNI essentially.  Another way of thinking of this is that NAT is involved or some port translation if you are hitting port 30000 and being redirected to port 443 on an internal/LAN IP.  This is where things are getting broken.

How do we fix this?

Make sure the SNI is sent forcefully such as in haproxy add this:

server server1 1.2.3.4:30000 ssl verify none sni req.hdr(host)
 

If that doesn't work you will need to use more public IPs but this breaks some applications as sometimes the backend server is reallly just another load balancer too unless you have multiple public facing IPs for the load balancers.

requested, server, indication, sni, ve, troubleshooting, cdn, backend, configured, correctly, balancer, cdns, ports, provider, define, origin, www, cooldomain, user, translates, listens, apache, ssl, doesn, redirected, essentially, nat, translation, lan, ip, forcefully, haproxy, verify, req, hdr, ips, applications, reallly, multiple, balancers,

Latest Articles