Skip to content

HTTPS Hostnames and SNI

When connecting to a Velosity HTTPS endpoint, use its fully qualified hostname in the URL. Do not connect to an IP address.

Why the hostname matters

Several HTTPS applications can share one public IP address. Before the encrypted connection is established, the client sends the hostname it wants to reach using Server Name Indication (SNI). The proxy uses that hostname to select the matching TLS certificate.

Modern HTTP clients send SNI automatically when the URL contains a hostname, for example:

https://api.example.com/v1/customers

If a client connects by IP address, uses an older TLS library, or overrides TLS settings, it might not send SNI. The proxy must then return its default certificate, which can belong to a different application on the shared proxy. Certificate validation will fail because the requested hostname and certificate hostname do not match.

Integration guidance

  • Configure the integration base URL with the current HTTPS hostname.
  • Do not replace the hostname with an IP address.
  • Keep normal TLS certificate validation enabled.
  • If the integration pins certificates or restricts allowed hostnames, update those settings when the endpoint hostname changes.
  • During a hostname migration, update the integration to the new hostname instead of relying on the legacy endpoint's redirect. If the legacy endpoint must be used temporarily, the client must support HTTPS redirects.

Troubleshooting certificate-name errors

If an integration reports that it received a certificate for an unexpected hostname, verify the configured URL and TLS settings first. This usually indicates that SNI was omitted or the client connected to an IP address; it does not mean the request was routed to the application named in the unexpected certificate.