1

I am trying to get a developer site up and running that uses SSL only with 3 web applications that use SNI. Everything except "openwith explorer"

The error I get is:

We're having a problem opening this location in File Explorer. Add this web site to your Trusted Sites list and try again.

Doing what was suggested in the error message had no effect on the symptoms.

UPDATE:
A production system that had the Web Applications created using HTTP and later had HTTPS with SNI added, work perfectly over SSL. The original Farm mentioned in my question was a development environment where we created the Web Applications/root sites using SSL only. That's the only important distinction between the two systems.

Improve this question
3
  • I'm setting up a new SP environment using SNI and I'm finding I'm having the exact same problem. Setting the site in trusted sites does not fix the problem, nor does setting the trusted sites security level to the lowest setting. What version of IE are you running?
    – user24313
    Commented Mar 26, 2014 at 22:01
  • IE 11 and I always add sites to the trusted before I do anything else.
    – Robert Kaucher
    Commented Mar 26, 2014 at 22:22
  • 1
    I've done some internal testing and I've verified the behavior on IE10 (Win7) and IE11(Win8.1). Behavior is verified on SP2013 Dec'13 rollup and SP2013 SP1. I did find this link: support.microsoft.com/kb/2629108 relating to similar behavior, but it's relating to SP in Office 365, the hotfix to remediate it was for IE10, and the hotfix was already incorporated in the IE10 version I was testing with. I'll continue to research this.
    – user24313
    Commented Mar 27, 2014 at 13:58

2 Answers 2

Reset to default
2

I've been doing a great deal of research into this the past couple days as I'm in a similar situation. The evidence looks pretty strong that WebClient, the Windows service that is used by software to connect to a WebDAV resource does not support SNI. A SharePoint MVP echoed my suspicions that this is the case on another thread on the MSDN forums.

At this point, I see a couple options, listed below. Please humor if the descriptions are a little overly complete, I'm hoping that this post can serve as documentation for the next person to come along with the same issue.

  1. Configure each of the sites on a different IP/Port combination. This is the most obvious solution and would then allow for each Web Application to take its own cert w/o SNI. Obvious downside, either consuming multiple IPs or using nonstandard ports.

  2. Use a UC Cert. Much like a star cert, a UC cert is valid for multiple hostnames (foo.example.com, bar.example.com, etc.) but for a specific, finite set of hostnames. These tend to be cheaper than star certs and potentially more secure, as a stolen UC cert couldn't then impersonate mail.example.com unless it was on the cert. Disadvantages include much higher cost of a UC cert compared to a single name cert and a finite number of hostnames that must be set up in advance.

Neither are terribly perfect solutions, but they are both options. Hopefully, Microsoft will update WebClient at some point to support SNI, but in the mean time, I think we're stuck with workarounds.

Edit to add Eric Law's comment to answer.

I tested this today and found that Windows 8.1 does not send the SNI extension but Windows 10.10240 does. twitter.com/ericlaw/status/624281014685319171 -EricLaw

Improve this answer
8
  • That was the exact conclusion I was coming to as well. Oddly, though, I can't even seem to get WebDav to work an a web app that doesn't use SSL but this one is "extended" with an AAM so it's likely the same issue, though.
    – Robert Kaucher
    Commented Mar 27, 2014 at 21:04
  • Robert, could you expand on your issues that you're having? I'm unable to get open with explorer to work at all on an SSL web app. I had been trying a similar build to yours, with an extended web app with the extension being SSL, but even after deleting the web application completely and re-creating it, I still get an error message indicating the path is inaccessible and it might be a permissions issue, followed by a cryptic message about "A device attached to the system is not functioning."
    – user24313
    Commented Mar 28, 2014 at 16:46
  • @ user24313 - That's definitely not what I am seeing. The only message I am getting is "We're having a problem opening this location in File Explorer. Add this web site to your Trusted Sites list and try again."
    – Robert Kaucher
    Commented Apr 15, 2014 at 20:36
  • I just updated my question with some details regarding a working config using SNI. So I don't think it's the client.
    – Robert Kaucher
    Commented Apr 15, 2014 at 20:44
  • 1
    I tested this today and found that Windows 8.1 does not send the SNI extension but Windows 10.10240 does. twitter.com/ericlaw/status/624281014685319171
    – EricLaw
    Commented Jul 23, 2015 at 20:58
0

I have the same issue, one site collection built from http and https added after - Open with Explorer works fine in Https. The second site collection (separate web app and database) built on port 443 from the start - Open with Explorer does not work.

The only solution I can see is backing up the content, creating the site collection again from scratch but on http, then adding https after as on the other site collections, then restoring the content. Not too bad to do but a pain in the a for something so trivial!

HMMMMPF!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.