SNI Support

Never used it myself...but it seems to me all ingredients are present .
Adding a "business Application rule" , web-server-protection (WAF) , gives you https checkbox, and allows domain name and matching certificate to choose.  Each https site will require its own waf rule, and its own certificate

It doesn't work.  It does a "round robin" approach where it will route it to a (seemingly) random host and you get a certificate error, rightfully so since the certificate that is being used to connect doesn't match the host you are sending it to.  

It works fine for wildcard certs, which makes sense since every subdomain matches the wildcard cert, however it does not work for different domains.  Even though it is configurable, I think this interface is for wildcard certs and not SNI.

I don't think XG Firewall does SNI, which it needs in order to know which host to route it too.  Since it connects to SSL before requesting the host, it can only listen on one port (443) and route to one host after the connection (unless a wildcard) unless they use SNI where the client can ask for the host during the SSL handshake, then XG Firewall will know which virtual host to send it to, even for a different domain.  I suspect they will also need to do this if they ever want to support Let's Encrypt cert management on XG firewall.

If it isn't supported on XG, I heard it is supported on UTM, however that doesn't help.  If that's the case I will just stand up nginx down stream, manage my certs there, and start evaluating other products.

I added the idea, but it would be nice to know if there is a bug or it doesn't work intentionally.

http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/17906929-server-name-indication-sni-multiple-ssl-one-ip

Thanks.

It doesn't work.  It does a "round robin" approach where it will route it to a (seemingly) random host and you get a certificate error, rightfully so since the certificate that is being used to connect doesn't match the host you are sending it to.  

It works fine for wildcard certs, which makes sense since every subdomain matches the wildcard cert, however it does not work for different domains.  Even though it is configurable, I think this interface is for wildcard certs and not SNI.

I don't think XG Firewall does SNI, which it needs in order to know which host to route it too.  Since it connects to SSL before requesting the host, it can only listen on one port (443) and route to one host after the connection (unless a wildcard) unless they use SNI where the client can ask for the host during the SSL handshake, then XG Firewall will know which virtual host to send it to, even for a different domain.  I suspect they will also need to do this if they ever want to support Let's Encrypt cert management on XG firewall.

If it isn't supported on XG, I heard it is supported on UTM, however that doesn't help.  If that's the case I will just stand up nginx down stream, manage my certs there, and start evaluating other products.

I added the idea, but it would be nice to know if there is a bug or it doesn't work intentionally.

http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/17906929-server-name-indication-sni-multiple-ssl-one-ip

Thanks.

TimothyStewart,

you opened the feature request on the wrong area (under UTM9 and not XG).

Please make sure to open it under XG Firewall.

I will give you my vote.

Regards

Created: http://ideas.sophos.com/forums/330219-sophos-xg-firewall/suggestions/17906929-server-name-indication-sni-multiple-ssl-one-ip

I realise this is an old thread, but it seems to be causing confusion and I want to set the record straight.

SNI is supported by XG Firewall for Web Server protection.

When you create a Business Application firewall rule using the Web Server Protection template, and select HTTPS, you can specify the certificate to use and the hostnames that apply for that rule.

If you create multiple of these rules using the same port and IP address, but with different certificates and hostnames, it will select the correct rule based on the SNI in the TLS handshake that is sent by the end-user's browser.

Note that this approach can't work for port forwarding or DNAT rules, where the WAF is not used and TCP packets are just forwarded directly to the server.