Does TMG 2010 Work with Server Name Indication (SNI) Feature of IIS8?

Hi,

I am trying to publish Microsoft Azure Pack Tenant Websites using SSL 443 for multiple sites with the recent Server Name Indication (SNI) feature. For the life of me I cannot get this working (no denied traffic on TMG).

does TMG 2010 SP2 UR5 support (sorry work with)&nbs

October 6th, 2014 6:18pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 12:14pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

October 8th, 2014 12:14pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 4:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

October 8th, 2014 7:12pm

From what I understand SNI is largely reliant on client support. It is just an extension of the TLS SSL protocol. One of our Escalation Engineers wrote up a pretty good post explaining SNI.

http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

"SNI is an extension to the TLS SSL protocol that allows the client to include the Hostname the client is connecting to in the SSL Client Hello. A server can then use the SNI header to determine which certificate to serve to the client. A key benefit of SNI is that is allows a server to host multiple certificates on the same IP/port pair instead of needing an IP per certificate (assuming you are using port 443)."

A few questions I would have is what client and browser combination have you attempted on this? Also, are you using a wildcard certificate on your Web Listener? Have you taken network traces to see if client is sending SNI? Ian does a good job of explaining how to do that in his blog post.

Free Windows Admin Tool Kit Click here and download it now
October 8th, 2014 7:12pm

Were you able to take the network traces to see if client is sending SNI? Any update on this?

October 14th, 2014 8:40pm

Hi Keith,

Many thanks for the reply... I also looked into this in great detail and you are 100% correct that its a client browser technology.
Turns out I had to create multiple web publishing rules (all with the same listener with wildcard ssl cert) to get it to work.

So I can confirm TMG does indeed work with publishing to sites that have SNI configured so long as there is a published rule for each site.

Free Windows Admin Tool Kit Click here and download it now
October 15th, 2014 1:55am

Sorry, but this is incorrect.  TMG is not SNI aware.  By using a wildcard certificate on the listener, you are avoiding the issue/benefit of SNI.  In your example, TMG ignores the SNI, sends the wildcard cert which matches the domain the user is requesting, the tunnel comes up and the HTTP request is made, TMG finds out the host in the request and matches it against one of the public names in the list of TMG Firewall Rules, many of which can use the same listener as you indicated, and the request is forwarded to the correct site or farm.

The genius of SNI would be that you don't even need a wildcard certificate.  The benefit would be that one could have a listener object with a pool of certificates that are 'valid' for that listener and TMG would get the request host from SNI and supply the single-subject-name certificate from the pool of valid certs that matched it.  Obviously, TMG was not designed with this in mind, so it makes no use of SNI.

/-djs-/

November 20th, 2014 1:12am

I never said that TMG was SNI aware, only asked the question ;-) but using my method it does allow me to publish multiple https sites that use SNI on a single IIS server with a single IP address... without SNI this isn't possible, right?

Appreciate your response.

Free Windows Admin Tool Kit Click here and download it now
November 20th, 2014 7:36am

Sorry, remote_event, but you are wrong. It's just like DJ Saltarelli said, when you deploy a wildcard certificate there is no SNI in place. Also, like he said, SNI is not a CLIENT TECHNOLOGY and TMG DOES NOT INDEED support it.

I am building an certificate test tool which has SNI support and TMG doesn't reply to me as a SNI enabled server (like Apache Httpd with OpenSSL 0.9.8+) would do.

For the sake of correctness, I'm replying to this old post.

May 6th, 2015 4:34pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics