Introduction

Modern origins often host multiple TLS sites on the same IP address and depend on SNI to choose the correct certificate. If a client, proxy, or CDN connects without sending the expected SNI hostname, the origin may return the wrong certificate or fail the handshake entirely. The fix is to trace which upstream component is opening the TLS connection and what server name it actually presents.

Symptoms

  • The origin serves a default certificate instead of the hostname-specific certificate
  • Proxy-to-origin TLS handshakes fail while direct browser access works
  • One hostname behind a CDN or load balancer fails, but direct access to the origin does not
  • SSL tests show a mismatch only for proxied or backend connections
  • The problem appeared after adding a proxy, changing upstream hostnames, or consolidating listeners

Common Causes

  • The proxy or CDN connects by IP or generic backend name without sending the public hostname as SNI
  • Upstream configuration uses the wrong server name for TLS verification and certificate selection
  • The origin expects SNI for virtual host mapping but the client stack does not send it
  • Backend hostname overrides changed the intended SNI value silently
  • A default listener catches the TLS connection when SNI is absent or incorrect

Step-by-Step Fix

  1. Identify which component is connecting to the origin over TLS and whether it should be using a hostname-specific connection.
  2. Capture the certificate served by the origin during the failing connection and compare it with the expected hostname.
  3. Review proxy, CDN, or load balancer settings for the upstream server name or TLS host override used on origin pulls.
  4. Confirm the SNI value being sent matches the hostname whose certificate the origin is configured to serve.
  5. Check whether the origin listener has a default certificate that is masking the missing-SNI problem with the wrong fallback site.
  6. Correct the upstream TLS hostname or SNI configuration and reload the affected proxy or service.
  7. Re-test the backend handshake and confirm the origin now presents the right certificate for that hostname.
  8. Validate all related hostnames behind the same origin IP if they rely on SNI selection.
  9. Keep origin pull hostname settings explicit so future routing changes do not silently drop or change SNI behavior.