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

  • Question

  • 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) SNI?


    Microsoft Partner

    Monday, October 6, 2014 10:15 PM

Answers

  • 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.

    Wednesday, October 8, 2014 4:12 PM
    Answerer
  • 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.


    Microsoft Partner

    • Marked as answer by rEMOTE_eVENT Tuesday, October 14, 2014 10:56 PM
    Tuesday, October 14, 2014 10:55 PM

All replies

  • 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.

    Wednesday, October 8, 2014 4:12 PM
    Answerer
  • Were you able to take the network traces to see if client is sending SNI? Any update on this?

    Tuesday, October 14, 2014 5:40 PM
    Answerer
  • 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.


    Microsoft Partner

    • Marked as answer by rEMOTE_eVENT Tuesday, October 14, 2014 10:56 PM
    Tuesday, October 14, 2014 10:55 PM
  • 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-/

    Thursday, November 20, 2014 6:09 AM
  • 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.


    Microsoft Partner

    Thursday, November 20, 2014 12:31 PM
  • 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.

    Wednesday, May 6, 2015 8:33 PM