Consolidation of multiple HTTP access services under one IP address
The HTTP listener supports configuring multiple HTTP services, each with its own service URL, to use the same IP address and port.
For example, in an environment that supports HCL Connections, HCL iNotes, and HCL Sametime, you might create HTTP access services similar to the ones in the following table:
Application | Service name | External URL | TCP listening port |
---|---|---|---|
Connections | http-service0 | https://connections.renovations.com |
443 |
iNotes | http-service1 | https://inotes.renovations.com |
443 |
Sametime | http-service2 | https://sametime.renovations.com |
443 |
The URLs for all three applications resolve to the same external IP address. The HTTP listener on the SafeLinx server receives traffic for all three URLs on port 443.
Starting with SafeLinx 1.3, the Service Name Indicator (SNI) TLS extension is supported and used by default. With SNI, a client indicates which host name it is attempting to connect to at the start of the TLS handshake. SNI support allows you to configure an X.509 certificate and other TLS attributes separately for each HTTP service that shares an IP address and port. TLS options are part of the service properties. A TLS context is created for each resource so each can have its own cipher and version specifications as well as its own certificate/certificate chain.
SafeLinx will use the SNI provided by the client in the TLS handshake as the first method to determine which http-service, nomad-web-proxy, or verse-ha resource to route the traffic through. If the SNI is not provided, SafeLinx falls back to the "Host" token in the http header to make the routing decision.