Visual Studio 2015 "The request was aborted. Could not create SSL/TLS secure channel" when Signing In or NuGet? Check your IE Settings...
As you all know VS 2015 was released on Monday, 7/20. [Missed the event? No you didn't! Catch it all here On Demand on Channel 9, Visual Studio 2015 Final Release Event]
Being me, I of course downloaded the RTM bits as soon as they were released and installed it on my main work machine.
Install was smooth, no errors, just installed.
I fire it up, try to sign in and...
... sigh. Okay, maybe it's just a hiccup?
Let's fire up a project and, hey check NuGet for updates...
...Doh!
Fall back to VS 2013, NuGet and all still works like a charm. Access the https://api.nuget.org in IE, works like a charm.
Fiddler was installed with it's awesome HTTPS support, maybe that's it? Turn off Fiddler HTTPS, remove cert, uninstall, reboot. VS 2015 Sign-in/NuGet for work now? Nope.
Repair VS 2015. Reboot. Work? Nope.
Devenv.exe /resetsettings help? Nope.
Look at the /Log, ActivityLog.xml and see anything that stands out (except the big red errors when I try to use the NuGet Package Manager. Nope.
Add Nuget.org to IE's trusted sites? Nope.
Anyone else here on the same network have VS 2015 yet (so I can see if it's just me)? Nope.
I was about to throw in the towel and ping the ALM MVP's when I tried one more thing. Was I using a proxy? OH, I am! My "Use automatic configuration script" was checked. Hum... Let's uncheck that and see if THAT helps.
YES! That was it.
The proxy, setup up by my company, seemed to make VS 2015 an unhappy camper. Unchecked, everything in VS 2015 worked like a charm!
I was able to easily repro this, checking, broke VS 2015, unchecking, VS 2015 was happy (of course restarted VS 2015 between all these checks/unchecks).
Morale of the Story: If you install VS 2015 and get some weird behavior when access web resources, like "The request was aborted. Could not create SSL/TLS secure channel," check your IE Settings.
Posts
3 comments:
I got a similar issue when my code attempted to query a 3rd party REST api over HTTPS. This article gave me the appropriate config settings to diagnose it. In my case it turned out that the server hosting the client required a higher version of TLS than the server was capable of supplying so no HTTPS connection could be negotiated.
Not helpful in this instance, but if you get a general TLS error, another thing to check is your clock. A number of times I've been in a VM or something and wondering why my SSL has broke only to realise that I had my clock set back (or forwards) months or years to help me test something. This was always a particular issue with the ALM Demo VM which deliberately has the clock disconnected from real time for some very good reasons.
It appears this is a bigger problem - Visual Studio 2015 has problems behind corporate proxies as well - see my question on StackOverflow: http://stackoverflow.com/q/31571224
Post a Comment