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:-
|
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:-
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 : 1D96CD2450B01E5660F756D1BDDE3B49B48870352) 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.com3) 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 propertiesYou can also open the Certificate MMC, Local Machine, Personal store and open the relevant cert from there to identify the certificate thumbprint:-
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