Idea Details

Server Name Indication  (SNI) support

Last activity 28 days ago
Michael_Mueller's profile image
02-15-2017 10:16 AM

Hi Team,

 

just a question to you concerning a topic that  I've been asked  from colleagues several times.

 

We have the necessity to call the api gateway  with different second level domains. E.g. ***.yyy.com (as it is today) and yyy.io for future use. If we use https we need to present different certificates to the client for this. Up to now the CA API gateway supports just one cert. 

 

Webhoster use a feature called SNI to solve this. Wouldn't this be a cool feature in the gateway as well?

Regards


Comments

11-16-2018 01:25 PM

SNI handlinkg will be no use if gateway can't handle multiple certificates, along with multiple SANs, on the same listener.

So:

- Add option to choose one or multiple certificates on "Requires SSL/TLS", thus overriding listening port configuration.

- Add option to select CA for "with Client Certificate" so that Server Hello protocol will send back proper request to client

- Add option to handle SNI to enables early in-API logic rerouting

     At least one

         All must

               Compare variable ${request.tls.sni} = "api.somedomain.com"

               .....

         All must

               Compare variable ${request.tls.sni} = "foobar.otherdomain.com"

               .....

etc.

03-12-2018 04:21 AM

Actually what you are describing seems to be more in links with SAN and DNS Aliases, ie the ability to support multiple domain/host names with a single certificate and a single listener.

* on SAN: Subject Alternative Name - Wikipedia  and Multi-Domain (SAN) Certificates | DigiCert.com )

* on DNS Aliases: CNAME record - Wikipedia 

I think that the policy having access to the Host header of the request can also change its behavior based on the requested host name. Worst case one can deploy multiple listeners, each with its own server certificate, and using a LLB to establish port mapping.

My understanding is that support for SNI would rather allow the gateway to route the request to a specific policy based on the requested hostname (regardless of the requested uri) as part of the TLS connection. I guess that this would allow to implement the "Associate port with published service (bypass configuration)" feature of the listeners configuration based on the host name rather than the listening port - although this can also be easily implemented programmatically again using the "Host" header of the request.

03-02-2018 09:56 AM

Another customer is also asking for SNI support.

Is it planned to be supported as far as you know?

 

Regards,

Enrico

02-05-2018 06:29 AM

And another important question, what about the support on the serverside, meaning the connection from the API gateway towards the backend/provider? Here the API gateway acts as the client and also needs to support SNI, where it has to transmit the hostname in cleartext during initial SSL ClientHello packet.

Or is this already in place and working?

Thank you!

 

Ciao Stefan

04-05-2017 05:30 PM

So much yes here, especially for a service acting as a proxy. The standard has been out for what 10+ years now? No reason web servers and apps today should not support this...really simplifies overall implementation and provides flexibility for cert management / hosting multiple hostnames and services on single systems.

03-07-2017 09:32 AM

Out use of the API Gateway involves a lot of users who are served by various ASP's. Fot them SNI supoort would mean a big step head. Is SNI eprhaps on a roadmap? And when can we expect it?

02-15-2017 03:18 PM

I've had several customers and prospects ask for this.

It wouldn't surprise me if the underlying software already or can easily be updated to support this but that we just need to have a way to configure this as part of the listen ports config.