Application Proxy Blog

This blog provides additional information about the Application Proxy service of Windows Server and Azure Active Directory.

How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2

How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2

  • Comments 16
  • Likes

Welcome back everyone. In this blog we’re going to look at SNI which is an area we’re seeing a number of questions on so wanted to spend a bit of time explaining.

Server Name Indication (SNI) is a feature of SSL TLS and both Web Application Proxy and AD FS 2012 R2 use it to enable simpler deployment and remove networking prerequisites. Some client applications don’t support SNI but there is an easy way to workaround this using a fallback certificate. In this blog we will explain what SNI is, how it works and what to do if you have non-SNI capable clients.

What is this SNI of which you speak?

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

SNI relies on the client supporting SNI and sending the Server Name extension in the SSL Client Hello. If the SSL Client Hello does not contain the SNI header then http.sys is unable to determine which certificate to serve and will reset the connection.
While most clients do support SNI you may encounter non-SNI capable clients that you need to provide support for. Some non-SNI clients we have seen issues with include:-

-    Older browser versions or legacy operating systems (Internet Explorer on Windows XP, Mozilla prior to v2.0, Safari prior to v3.0 Mac OS X 10.5.6, etc.)
-    Some older versions of WebDAV
-    ActiveSync for Android
-    Internet connected devices without recent OS/TLS updates (VOIP conferencing devices, proxy devices, etc.)

We have also seen SNI related issues with various Hardware Load Balancers health check requests not sending the SNI header although this is often due to the necessary configuration not having been put in place. We’ll be covering Hardware Load Balancer health check requirements and other considerations in more detail in an upcoming blog.

If you want the full technical details on SNI you can read the relevant RFC - https://tools.ietf.org/html/rfc3546#section-3.1

 

How to tell if the client is sending an SNI header?

If you suspect an application is having connectivity issues through Web Application Proxy or to an AD FS 2012 R2 server a Network Monitor trace of the traffic either on the client or on the Web Application Proxy / AD FS is a good way to determine if an SNI header is being sent and, if you are getting a RESET back. The following is an SSL Client Hello taken from a Network Monitor trace with the Server Name (SNI) header present in the Client SSL Hello:-

- TLS: TLS Rec Layer-1 HandShake: Client Hello.
  - TlsRecordLayer: TLS Rec Layer-1 HandShake:
     ContentType: HandShake:
   + Version: TLS 1.2
     Length: 861 (0x35D)
   - SSLHandshake: SSL HandShake ClientHello(0x01)
      HandShakeType: ClientHello(0x01)
      Length: 857 (0x359)
    - ClientHello: TLS 1.2
     + Version: TLS 1.2
     + RandomBytes:
       SessionIDLength: 32 (0x20)
       SessionID: Binary Large Object (32 Bytes)
       CipherSuitesLength: 52
     + TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384   { 0xC0,0x28 }
     --------Cipher Suites trimmed-----------
     + TLSCipherSuites: TLS_RSA_WITH_RC4_128_MD5                { 0x00,0x04 }
       CompressionMethodsLength: 1 (0x1)
       CompressionMethods: 0 (0x0)
       ExtensionsLength: 732 (0x2DC)
     + ClientHelloExtension: Renegotiation Info(0xFF01)
     - ClientHelloExtension: Server Name(0x0000)
        ExtensionType: Server Name(0x0000)
        ExtensionLength: 21 (0x15)
        NameListLength: 19 (0x13)
        NameType: Host Name (0)
        NameLength: 16 (0x10)
        ServerName: adfs.contoso.com
     + ClientHelloExtension: Status Request(0x0005)
     + ClientHelloExtension: Elliptic Curves(0x000A)
     + ClientHelloExtension: EC Point Formats(0x000B)
     + ClientHelloExtension: Signature Algorithms(0x000D)
     + ClientHelloExtension: SessionTicket TLS(0x0023)

If the client supports SNI then all will be good and the standard Web Application Proxy and AD FS Server 2012 R2 certificate bindings will be fine. If the client does not send an SNI header in its SSL Client Hello then http.sys will send a TCP RESET on the connection. The following shows the network traffic you would see if this is the case:-

image

 

Supporting Non-SNI Capable Clients

As mentioned above, if you are having connectivity issues from a specific client application and you suspect the client may not be SNI capable, running a Network Monitor trace on your Web Application Proxy / AD FS 2012 R2 server while the client attempts to connect will show you if the client is sending an SNI header in the SSL Client Hello.
If you determine you have issues with non-SNI capable clients you have a few different options:

-    Do nothing. It may be that you make a deliberate decision not to support that browser/operating system/client and a valid choice is to decide not to support non-SNI clients
-    Upgrade the client to an SNI capable version. This may be the browser, OS, device firmware etc. An upgrade should be considered if possible.
-    Enable/configure SNI support on the client. Some clients like hardware load balancer health checks do support SNI but sometimes it is off by default.
-    Configure a fallback certificate in http.sys – see next section

 

Configuring an http.sys fallback certificate

Our current recommendation if you need to support non-SNI capable clients is to add a manual http.sys certificate binding for 0.0.0.0:443 using the following command:-

netsh http add sslcert ipport=0.0.0.0:443 certhash=certthumprint appid={applicationguid}

This configures http.sys with an IP Wildcard certificate binding which will be used as a fallback certificate. This would need to be run on each server in a farm.

When running the ‘netsh http add sslcert’ command the certhash parameter would be the certificate thumbprint for the certificate you want to use as the fallback cert. Please see the ‘How to determine a certificate’s thumbprint’ section below for additional details.

The appid parameter is the GUID of the application that created the binding but can also be manually set.  The following are the 2 application ID’s for Web Application Proxy and the AD FS service and using either of this would be fine:-

    {5d89a20c-beab-4389-9447-324788eb944a} – AD FS App ID
    {f955c070-e044-456c-ac00-e9e4275b3f04} – Web Application Proxy App ID

The command you would run would therefore look something like this:-

netsh http add sslcert ipport=0.0.0.0:443 certhash=3638de9b03a488341dfe32fc3ae5c480ee687793 appid={5d89a20c-beab-4389-9447-324788eb944a}

 

Fallback certificate considerations

As you can only configure a single certificate as the fallback cert it is important that the certificate you use covers all the FQDN’s that you need to provide SNI fallback support for which may include:-

-    AD FS service FQDN e.g. adfs.contoso.com
-    Enterprise Registration (Workplace Join) FQDN’s e.g. enterpriseregistration.contoso.com
-    Any Web Application Proxy published application External FQDN’s e.g. sharepoint.contoso.com

Using either a Subject Alternate Name certificate or a Wildcard certificate is supported. A Wildcard certificate may give greater flexibility when adding further published applications in the future.

Note - while using a fallback certificate is certainly going to be needed to support some clients and scenarios, please be aware that this is a manual binding that you are going to have to remember to maintain and update on each node as certificates expire and are replaced.

 

Can I use an IP Specific fallback binding?

The simple (and recommended) answer to this is No.

However, as with most things the reality is a bit more complicated.

http.sys does allow you to configure IP specific bindings e.g. 1.2.3.4:443 but you need to be very careful about going down this route as http.sys in Windows 2012 R2 uses the following order of precedence when determining which certificate to serve:-

Priority Name Parameters Description
1 IP IP, Port Exact IP and port match
2 SNI Hostname, Port Exact Hostname match (connection must specify SNI)
3 CCS Port Invoke Central Certificate Store provider
4 IPv6 Wildcard Port IPv6 wildcard match (connection must be IPv6)
5 IP Wildcard Port IP wildcard match (connection can be IPv4 or IPv6)


If an IP:Port binding is configured then, as per the above order of precedence, the IP specific binding will take precedence over all other bindings so any SSL traffic to that IP address will receive the certificate specified in the IP:Port binding.

Important: An IP specific binding is therefore not a fallback certificate – it becomes the exclusive certificate on the specified IP address and takes precedence over SNI bindings. 

This can therefore break any traffic relying on the SNI bindings and in particular, you risk breaking the Certificate Trust List used by AD FS 2012 R2 as this is defined in the AD FS SSL Service certificate binding.

Our advice if you do need to use an IP specific binding is as follows:

-    Do not use an IP Specific binding on the primary IP address of Web Application Proxy or AD FS 2012 R2. The primary IP address should be used for the majority of traffic and using SNI

-    If required, configure a fallback cert on 0.0.0.0:443 with a certificate that covers your AD FS service FQDN, EnterpriseRegistration FQDN’s and other Web Application Proxy published application External FQDN’s using a Subject Alternate Name or Wildcard certificate

-    If you need to use a different certificate for a specific FQDN then add a 2nd IP address to the Web Application Proxy server and use an IP specific certificate binding on this secondary IP. This certificate binding will then be exclusively used for all traffic to this IP without affecting traffic to the primary IP address and SNI bindings. For each additional certificate required add an additional IP address and bind the certificate to this.
You then just need to ensure your inbound traffic for the relevant service FQDN is sent to this secondary IP address either through DNS resolution or load balancer / firewall configuration.

Note: From an AD FS 2012 R2 perspective we would not expect an IP specific binding to be needed as you can just configure your AD FS SSL Service certificate as the 0.0.0.0:443 fallback cert.

Our general advice is to avoid IP specific bindings due to the complexities these introduce and the fact that you’re very much moving into a manual certificate binding management situation. It can be done but you need to understand the above points to avoid hitting issues. We expect that using a 0.0.0.0:443 fallback binding will solve the majority of scenarios.

 

How to determine a certificate’s thumbprint

There are many different ways to determine a certificates thumbprint. Here are few different options depending if you prefer scripting or GUI:-

1) Look at the Web Application Proxy application configuration

You can run the following PowerShell command on a Web Application Proxy server to identify the Certificate thumbprints in use for each of the Web Application Proxy publishing rules:-

Get-WebApplicationProxyApplication | fl Name, ExternalUrl, ExternalCertificateThumbprint

Sample output:-
Name                          : ClaimsApp
ExternalUrl                   : https://claimsapp.contoso.com/claimapp/
ExternalCertificateThumbprint : 1D96CD2450B01E5660F756D1BDDE3B49B4887035

2) Use PowerShell to review the installed Certificates on the server

You can run the following PowerShell command on a server to return the certificates installed in the Local Computer Certificate store :-

dir Cert:\LocalMachine\My

Sample output:-

Thumbprint                                Subject
----------                                -------
1FAAA1B7FA33D266E5CC54E4EBE41CB6C68E583B  CN=ADFS ProxyTrust - 2012R2-WAP01
1D96CD2450B01E5660F756D1BDDE3B49B4887035  CN=*.contoso.com

3) Review the existing http.sys bindings

You can check existing certificate bindings using the following command to identify the thumbprint of an existing binding already using the target certificate:-

    netsh http show sslcert

The following is an example of a binding for a Web Application Proxy published application:-

    Hostname:port                : claimsapp.contoso.com:443
    Certificate Hash             : 1d96cd2450b01e5660f756d1bdde3b49b4887035
    Application ID               : {f955c070-e044-456c-ac00-e9e4275b3f04}
    Certificate Store Name       : MY
    Verify Client Certificate Revocation : Disabled
    Verify Revocation Using Cached Client Certificate Only : Disabled
    Usage Check                  : Enabled
    Revocation Freshness Time    : 0
    URL Retrieval Timeout        : 0
    Ctl Identifier               : (null)
    Ctl Store Name               : (null)
    DS Mapper Usage              : Disabled
    Negotiate Client Certificate : Disabled
   
4) Use the Certificate MMC to look at the Certificate properties

You can also open the Certificate MMC, Local Machine, Personal store and open the relevant cert from there to identify the certificate thumbprint:-

image

 

Summary

Server Name Indication (SNI) is used both by Web Application Proxy and AD FS 2012 R2 in their http.sys certificate bindings. For Web Application Proxy in particular this allows multiple, disparate certificates to be hosted on a single IP/port and allows Web Application Proxy to publish multiple sites without the need for multiple IP address.

SNI relies on the client sending the Server Name header in its SSL Client Hello. If this is not supplied in the client TLS negotiation then http.sys will reset the connection.

If you need to support non-SNI capable clients then it is possible to bind a fallback certificate in http.sys to 0.0.0.0:443. This certificate will be served in the server hello to any non-SNI capable clients. As you can only have one fallback certificate bound to 0.0.0.0:443 this certificate should include all the necessary FQDN’s you need the fallback certificate to support.

It is possible to use IP specific bindings but these take precedence over SNI bindings and should be used with caution.

 

As always, let us know if you have any feedback or comments and if you have any requests for specific articles and we’ll see what we can do.

Ian Parramore, Senior Escalation Engineer, Web Application Proxy support team

Blog - Email Author
Contact - Application Proxy Blog
  • Send
Comments
  • Awesome information, saved our project with the fallback certificate for 0.0.0.0:443.
    Thanks and keep up the good background info work.

  • Thanks Ian - sure this will save many an implementation.

    I would really appreciate it if the WAP team could write-up something about session affinity (if any) and/or what the roadmap around this was for WAP.

  • Perhaps a small clarification on my request for more information regarding session affinity. I know that it's not (yet) possible to have multiple back-end endpoints listed although a write-up on this would be interesting when due.

    My question related to the load balancing happening in-front of a WAP cluster. Is session affinity recommended (given that ADFS proxy is 'stateless') or is there a significant performance improvement (at the cost of linear scalability) for employing stickiness? If affinity is recommended - on what basis (IP, cookie, etc)?

    Thank you

  • Hi Christiaan,

    Thanks for the feedback, session affinity is certainly a very interesting discussion. We are also aware of the current limitation in terms of only being able to publish a single endpoint.

    In terms of performance there is no difference from a WAP perspective for stickiness vs no-stickiness. Any node in the same WAP farm can use the EdgeAccessCookie and the exact same processing of this cookie will happen for each request regardless of whether you hit the same node or a different node.

    I do think it is worth us putting something together to talk through some of the considerations around affinity but from a pure WAP perspective we have no need for affinity. That said, application level affinity is always something you need to consider so you do have to understand if back-end affinity is required and, if so, how affinity will work end to end from client, through WAP and on to the backend server taking into account the load balancing used for WAP and web servers. There isn't therefore an easy answer for this as it will depend on the load balancing technology in use and the capabilities this provides.

    One thing to take into account from a WAP load balancing perspective is that some load balancing options may require SSL termination on the load balancer e.g. cookie based load balancing and this has an impact on certain features such as Workplace Join and SSL Client Cert auth. We're just about to publish a blog talking about SSL termination which will dive into this in a bit more detail.

    Thanks,

    Ian

  • Do you have a timeframe for the upcoming blog? Need a probe for a Cisco ACE LB that does not support SNI. A fallback certificate does not seem to work with WAP.

    "We have also seen SNI related issues with various Hardware Load Balancers health check requests not sending the SNI header although this is often due to the necessary configuration not having been put in place. We’ll be covering Hardware Load Balancer health check requirements and other considerations in more detail in an upcoming blog."

    Thanks,
    Mark

  • Hi Mark,

    Probably in 3 weeks or so. I've got a main draft done for this but am just about to head out on a couple of weeks vacation. If your Cisco HLB doesn't support SNI then adding the 0.0.0.0 fallback binding will 100% workaround this and definitely works with WAP.

    The other main thing we see people getting wrong though is not sending the correct host header in the probe request. This should be the ADFS Service FQDN and if you send the local WAP machine name or IP things will fail.

    The following link gives some examples of specifying host header in a health probe:-
    https://supportforums.cisco.com/discussion/10406021/setup-ace-probe-http-host-headers-multiple-sites-rservers

    SNI and Host Headers are not the same thing and having the 0.0.0.0 binding will rule out SNI (you can take a Network Trace to check). My guess is that you've not got the host header specified in the probe.

    Hope this helps,

    Ian

  • Thanks for this blog, doesn't seem to come up in searches for any of the problems...it came up under "windows xp scalability" as I was clutching at straws to see if there was such a problem as the dreaded scalability pack that was preventing our windows XP clients from connecting to Office 365 using ADFS 3.0.

    This blog proved a lot more helpful than Microsofts "sorry we don't support windows XP, go away, thankyou for choosing microsoft" mumbo.

  • Haven't tried this yet, but it appears to nail my current problem on the head perfectly. So from one Ian to another, thanks for this!

  • Good job done , This is a really a great news and it's news is very useful for all PC user.,

  • Can the fallback certificate method above be used in a single-server ADFS 2.0 setup with no proxy? We have a situation where Android users are getting 401 - Unauthorized errors from ADFS when they try to add OneDrive for Business support via the MS OneDrive app, and we were told that this workaround is the only option due to the lack of SNI support...but we're not running Win Server 2012 R2 w/ ADFS 3.0. Suggestions?

  • Hi Cory,

    It doesn't sound like you're hitting an SNI issue. A 401 is an HTTP Authentication Required error code which says to me that the SSL connection was successfully established and that your Android devices are failing to auth for some reason. If SNI was the issue you wouldn't get as far as even sending an HTTP request.

    I've not heard of the issue you're seeing before so it might be worth getting a support case into us so we can look into the issue with you.

    Thanks,

    Ian

  • Hi!
    I got here while investigating a similar problem, and will post my solution here in case someone else gets here by the same reason.
    We use ADFS 3.0 to enable Identity federation for OnPremise AD With Azure AD for Office 365. When adding a OneDrive for Business AD-account to the Android OneDrive app, the login process fails when you are redirected to the OnPremise Federated login site.
    The solution to this is found by following this process for adding Forms Based auth. to the Primary Authentication metod for internal requests: http://blogs.technet.com/b/bshastri/archive/2014/03/07/configuring-dynamics-crm-ifd-with-windows-server-2012-r2-ad-fs-i-e-ad-fs-3-0.aspx

    I also enabled the cert for fallback first, so I'm not sure if that is a requirement as well. But it Works With both Methods activated now :)

    Hope this helps someone else.

    Cheers,

    Jan Kristian Kristoffersen, Bergen Norway.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment