“\\syXXXXXXXXXXXXX.ro@SSL\DavWWWRoot is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. A device attached to the system is not functioning.”
Recently on one of my SharePoint farms I noticed the “Open with Explorer” is not working. After couple of minutes of digging into the settings and performing network traffic captures I realized is not the SharePoint farm fault. In fact is the Microsoft Windows WebDAV Client who’s not capable to handle the Server Name Indication (SNI).
From Wikipedia: “Server Name Indication (SNI) is an extension to the TLS protocol that indicates to what hostname the client is attempting to connect at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 virtual hosting for HTTPS.”
When you have only one IP address available, you host multiple domains, multiple services and all of the communication traffic must be encrypted, then the only solution is to use Server Name Indication (SNI).
Let’s start with what IETF (Internet Engineering Task Force) RFCs are saying about Server Name Indication:
RFC 3546 – Transport Layer Security (TLS) Extensions (June 2003)
RFC 4366 – Transport Layer Security (TLS) Extensions (April 2006)
RFC 6066 – Transport Layer Security (TLS) Extensions: Extension Definitions (January 2011)
“TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting. It may be desirable for clients to provide this information to facilitate secure connections to servers that host multiple ‘virtual’ servers at a single underlying network address.
In order to provide any of the server names, clients MAY include an extension of type “server_name” in the (extended) client hello. The “extension_data” field of this extension SHALL contain “ServerNameList”
A server that receives a client hello containing the “server_name” extension MAY use the information contained in the extension to guide its selection of an appropriate certificate to return to the client, and/or other aspects of security policy. In this event, the server SHALL include an extension of type “server_name” in the (extended) server hello. The “extension_data” field of this extension SHALL be empty.”
According with the latest update (RFC 6066 – Transport Layer Security (TLS) Extensions: Extension Definitions), the client has an important role – to include an extension of type “server_name” that will help the server to identify the appropriate certificate that will be used to secure the connections. If the client doesn’t provide this “server_name” extension, the server will not know what certificate to use and most likely will reply with a default one (which could be not issued for the FQDN the client is connecting to – case in which the communication channel should not be trusted).
SNI is not a recent extension. It was mentioned since June 2003 by the RFC 3546 – Transport Layer Security (TLS) Extensions. However not all the clients (majority of them web browsers) are compliant with SNI. This is a sad. Why does the software companies are not really taking serious these standards?
Microsoft Internet Explorer is SNI compliant starting with Microsoft Windows Vista and Internet Explorer 7.
I highlighted the key sections from the RFC, now let’s see how IE 11 and Microsoft Windows WebDAV behave with SNI. This will demystify the problem.
IE11 and IIS 8 (with/without SNI)
|Request & response between IE 11 and IIS 8 (without SNI)||Request & response between IE 11 and IIS 8 (with SNI)|
As we see, IE 11 always sends extension “server_name” and IIS 8 responds with extension “server_name” only when is configured to use SNI.
Microsoft Windows WebDAV Client and IIS 8 (with/without SNI)
|Request & response between MS WebDAV and IIS 8 (without SNI)||Request & response between MS WebDAV and IIS 8 (with SNI)|
- Microsoft Windows WebDAV Client does not support Server Name Indication (SNI).
- If you troubleshoot “Open with Explorer” from SharePoint, have look over the SNI configuration.
So far I found only one thread on the MSDN forums regarding Microsoft Windows WebDAV Client and SNI compliance. Unfortunately the moderator closed that thread due to lack of understanding.
For those who would like to read more about TLS:
RFC 2246 – The TLS Protocol Version 1.0 (January 1999)
RFC 4346 – The Transport Layer Security (TLS) Protocol Version 1.1 (April 2006)
RFC 5246 – The Transport Layer Security (TLS) Protocol Version 1.2 (August 2008)
4 thoughts on “Microsoft Windows WebDAV Client does not support Server Name Indication (SNI)”
This is one of the best technical posts I have ever read. Very well done, thank you.
This Article may help: https://blogs.technet.microsoft.com/applicationproxyblog/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2/
The article suggested by you is in the context of Web Application Proxy and AD FS 2012 R2 – where the trick is to assign the same SSL certificate for the IP + PORT used by the Web Application Proxy and AD FS service to listen (basically not add the SNI – a.k.a setup a fallback certificate).
My article is talking about WebDav Clients (in general) without the intention to propose solutions.
Indeed the fallback certificate can be applied in this case as a solution for the old WebDav protocol (who is not SNI capable). So, if you are in a setup where you have a single IP assigned per machine and multiple SSL aplications to be published (the case that made me to write the article), the options are:
1. Use SNI – but WebDav will not work.
2. Use a fallback wildcard certificate (without SNI) – case in which the WebDav will work.
Thanks for your article, it helped a lot!..
I have the same issue with Windows 10 and a Nextcloud deployment. I resorted of configuring the Haproxy default backend to point to the Nextcloud site in order to solve this.