I have a website that is hosted using IIS7 when deployed, but we are seeing strange behavior with a web service we use that requires a client certificate. So what I'd like to do is debug our website locally to step through the code and take a closer look at the issue.
The problem is that I cannot figure out how to have the website accept client certificates when I'm running it locally (debugging it). If I just run it locally and perform an operation on the website that uses my client cert, it is clearly not pulling it from the browser because I'm getting "m_safeCertContext is an invalid handle" errors.
Is there a way to have the website accept client certificates when running locally? I have IIS7 installed on the same machine that has Visual Studio 2010 Professional installed, and the OS is Windows 7.
Thanks.
Related
I have incorporated Azure authentication in to a .NET application on my local development machine. When I debug/run the application in Visual Studio the app runs just fine.
I have deployed the application to IIS on my local development machine and have configured a new site binding of type HTTPS which uses an SSL certificate that I have created locally and added to my "Trusted Root Certification Authorities" store. When I try to browse the application through IIS, I get a generic error message that is generated by the Application_Error method in my global.asax.cs file.
Is it possible for me to use a debugger to "step through" code that has been actually deployed in IIS? I think that I have found MSDN documentation that describes doing this for a .NET Core application (https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/development-time-iis-support?view=aspnetcore-2.1) but I my app is written in .NET 4.8 so I don't think it applies for me.
To debug an ASP.NET application that has been deployed to IIS, install and run the remote tools on the computer where you deployed your app, and then attach to your running app from Visual Studio.
For more information about "Remote Debug ASP.NET on a Remote IIS Computer", you can refer to this link.
TF400324:Team Foundation services are not available from server xxxx
Technical information (for administrator):
The request was aborted: Could not create SSL/TLS secure channel
Some of our developers are getting the error above whilst working with TFS but only after having Visual Studio open for about 5-10 minutes. We are currently working around this issue by closing and opening Visual Studio as it seems to be connecting fine just after openning.
Note that this is not all of our developers and all developers are on the latest version of visual studio version 15.9.1 and the TFS server is 2015.
Our tfs website where we manage our sprint boards is fine and the certificate is valid until 2020. We recently updated our certificate to a wildcard e.g. *.mywebsite.com.
What we have tried:
IIS Crypto 2.0 from Nartac Software to check Protocols/Ciphers on clients and servers
Clearing the TFS cache folders on the client machines
A complete fresh install of visual studio, sign in and connection to TFS
Regedit HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319: SchUseStrongCrypto for both 32bit and 64 bit. Found here https://johnlouros.com/blog/enabling-strong-cryptography-for-all-dot-net-applications
Using a different microsoft login (also verified that mine works on other machines)
None of the above have solved the issue. What is puzzling me the most is that it works for a period of time before displaying the error, once the error has been displayed it seems that it never tries to reconnect to the TFS server so requires a fresh instance of visual studio before it attempts and successfully reconnects.
I found the answer here: https://developercommunity.visualstudio.com/content/problem/356394/tls-10-the-request-was-aborted-could-not-create-ss.html
The issue happens because VS 15.9 attempts to use system defaults for TLS handshake, but it is being to set to TLS1.2 somewhere within VS. While Microsoft works on a fix, you can work around this by setting this registry key
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000000
This should force .net to use system defaults (rather than TLS 1.2) and that should help negotiate gracefully down to TLS 1.0 if the TFS server is set to support only TLS 1.0.
That worked for me for VS 15.9.3 just fine (needed to restart VS though).
I'm using Visual Studio 2015 and Browser Link doesn't work with Firefox.
IE and Chrome work perfectly with Browser Link.
Just got a new machine, but that didn't help either.
I tried the prerequisites mentioned in the browserlink dashboard (for static files, enable debugging) and I use IIS express, so .NET 4.0 is there.
Are there any more settings needed in Firefox?
In the network view, I just don't receive a response from the server, 0 bytes transferred.
Network trace:
Found it, the main website was running on 44300, browserlink seems to run on 44399 (although that port isn't visible in IIS express)
Browse to https://localhost:44399 gave me the Firefox "This Connection is Untrusted" screen, where I needed to trust("confirm security exception") the self signed IIS certificate (just like what I had done on the https://localhost:44300 site)
So it seems Firefox remembers trusted certificates per port number, not per DNS/IP/Name like IE and Chrome seem to do.
Now the browserlink is working and downloading the files.
I don't have IIS running locally, but ran into a similar problem running the app locally with Visual Studio 2019.
The suggestion by Erik fixed the problem for me as well. Browsing to https://localhost:44399/ and accepting the certificate worked in Firefox Developer.
Some more details from Microsoft regarding self-signed certificates:
https://learn.microsoft.com/en-us/iis/extensions/using-iis-express/handling-url-binding-failures-in-iis-express
I developed a large web application with VS2008 installed on an old Win2k3 server. I now have Visual Studio 2010 installed on Win7 Pro and work on the application fine.
Parts of my web application need to switch into and out of SSL which they did on the Win2k3 server using the IIS tool that creates a private SSL cert.
However I now need to make changes to those parts and now need to be able to test it on the VS2010 internal web server as I no longer have a dev web server like I used to. Is there any way I can do this or is it definitely a no no?
Please take a look here. It is mentioned:
This sample [some sample using HTTPS]
only works when hosted on IIS and
cannot work on Cassini – Visual Studio
Development Server because Cassini
does not support HTTPS.
As this sample is related to .Net Framework 4, I assume that Visual Studio 2010 does not support SSL.
EDIT: The good news is that you can enable SSL for IIS 7.0 (and above). You can find detailed instructions here.
When are done you should be able to access your website over SSL, but browsers will display a warning that says that your certificate is not trusted. However, this can be easily solved in the following way:
1) The common name (CN) for the self-signed certificate that you create for the website should match the computer name that runs IIS and you should access the site using the computer name (https://computerName/ not https://localhost/ or https://IP/)
2) Export the certificate from IIS and import it in the browsers certificate stores. For Internet Explorer the certificate must be added to Windows Certificate Store at Local Computer / Trusted Root Certification Authorities (use Windows Management Console). For other browsers, because they use custom certificate store, the certificate must be imported in their specific location. For example, in case of Firefox to import a certificate go to Tools->Option->Advanced->Encryption->View Certificates->Authorities->Import.
With the release of VS2010SP1 & IIS Express you can now to debug code that uses with https/SSL without having to use a FULL IIS server.
I'm debugging a vb.net windows program which I've upgraded to a VS 2010 solution, targeting Framework 2. I need to step into a webservice's code. The web service is framework 3.5, also vb.net, running on a windows 2003 server on our LAN. I've seen a ton of crap on the Net about it, mostly other people who couldn't get it working either.
The error I get in VS2010 is the exact same one I got before upgrading the project from VS 2005:
Unable to automatically step into the server. Connecting to the server
machine [servername] failed. The Microsoft Visual Studio
Remote Debugging Monitor (MSVSMON.EXE) does not appear to be
running on the remote computer. Please see Help for assistance.
So I did what Help said to do and ran the VS 2008 remote debugging wizard on the host server. I have verified that the remote debugger is running as a service on that machine. And it still fails.
Little help? THANKS
Just in case anyone comes here looking for this answer, here it is. No goofy 'Attach to Process', no weird bad instructions
from websites going off on a million stupid tangents. This answer has been FALKENIZED.
When on the same LAN and on the same domain, remote debugging from Visual Studio 2010 works when you do the following steps.
on web service host machine, share the web application folder where the web service lives; give yourself 755 permissions.
oops, give yourself wrxr permissions.
on local development machine, map a network drive to the [web service host machine][web app] folder you just shared.
copy the Visual Studio 2010 remote debugger folder (containing msvsmon.exe + support files) to web service host machine.
Make sure you get the correct platform for your host server, e.g. x86, x64, etc. Remote debugger is found here:
C:\Program Files\Visual Studio 2010\Common7\IDE\Remote Debugger[platform]
on web service host machine, drag a shortcut from the newly-copied debugger to the desktop, then start the remote debugger
on local development machine, step thru code. when reaching a call to the web service, you'll be prompted to navigate
to the location of requested web service code file, which will then be available in your mapped path. Do it.
Finally after 1000000 headaches, you may start debugging your web service. CONGRATULATIONS