Server Name Indication and Hybrid Access Gateway

SNI is an extension to TLS that has been around for a while, since 2003, but is becoming more and more important as installations become multi tenant with customers from completely different organizations.

To save resources it has for a long time been popular to host multiple applications on one application server (virtual servers). If the server is listening to one interface and one port, there is no way to differentiate between the applications based on IP and port. Therefor the hostname has been used, one server with several hostnames, and this works fine when TLS is not used. When TLS is used a certificate with the hostname needs to be presented before the application layer protocol, e.g. HTTP, comes in to play providing the host name. To solve this, one can use a wildcard certificate valid for all names hosted by the server, or one can use a certificate including a list of all hosts. The first option, wildcard certificate, e.g. *.nexusgroup.com, is a good idea if the hosting is only for one organization with names such as mail.nexusgroup.com and intranet.nexusgroup.com. When having a cloud service that hosts services for multiple customers, that is not a good enough solution. It would be possible to do it like this: customer1.nexusgroup.com and customer2.nexusgroup.com and so on. This is a solution can be see in many places, e.g. in payment service integrations. However it is not preferable as it confuses the end user that came from a different domain, e.g. customer1.com or customer2.com.The second alternative with subject alternative names for all hosted names could work. Then a certificate with the name of all customers would be requested in one certificate, e.g. idp.customer1.com and idp.customer2.com and so on, but every time a new customer is added a new certificate would need to be requested. Since the customer owns the domain it might not even be practically possible to do it this way.

To solve this, SNI was added to TLS, it enables the connecting client to indicate the name of the server it is connecting to. And when having the target server name at the TLS level it is easy for the server to do a lookup among a list of certificates to find a matching one. For technical details on SNI see the RFC6066

Hybrid Access Gateway has previously had the option with multiple names in a certificate or wildcard certificate bound to one of its listeners. With the 5.6 release we added support for SNI in a very convenient way. Everything works as previously but at the DNS pool names it is now possible to select a certificate for a specific host name. And if none is selected it will fallback to the listener certificate.

One could imagine several useful application areas but the one closes to mind when talking about the Hybrid Access Gateway is of course hosting an IdP for multiple customers in one system. With the old branding possibilities and SNI we can create a truly seamless experience for the users without having separate installations for all customers or cumbersome interface configurations, it just works.