I have a c# web API that uses a client certificate in order to connect to a third party identification provider (BankID https://www.bankid.com/en/).
When running in Visual Studio the connection handshake works fine. But then I deploy it to IIS running on a Virtual Machine on Azure, and for some reason now it doesn't work as expected, and instead I get an Exception:
"The request was aborted: Could not create SSL/TLS secure channel."
I've installed Visual Studio on the VM, and verified that it works; and I've installed IIS on ly local machine and verified that it works. So it seems to be a combination if IIS on Azure VM:s.
At first I thought it could be that the client certificate was'nt picked up from the certificate store. But I added handling of "no certificate found", and this doesn't trigger.
I've also tried the alternative of picking up the certificate from file. But this doesn't work either.
Would appreciate some help!
I managed to figure out what the problem was. The IIS user (IIS_IUSRS) didn't have the permission to use the private key. So it wasn't actually related to Azure.
For anyone running into the same issue, look at the detailed answer here: https://stackoverflow.com/a/2647003/8721876.
Try putting this in your constructor:
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11;
Related
I am writing a Windows service to call a web API that I have previously written. Both are written in C#, targeting .NET 4.8, and the Windows service uses System.Net.WebClient to make calls to the web API.
I have successfully published my API to IIS on our testing server. IIS is set up to only accept HTTPS connections. Because our testing server is internal facing only and cannot be reached from the Internet, I have generated a self-signed certificate from IIS and have loaded it into the Trusted Certificate store on my development machine.
I am unable to get an SSL certificate from an external CA or use LetsEncrypt as the testing server cannot be reached from the outside world (that's not an option).
With the self-signed certificate in place, I can open a browser on my dev machine, and successfully connect to and retrieve data my Web API without any "not trusted" warnings, so the self-signed certificate appears to be working correctly.
I initially wrote and tested my Windows service code in a WinForms app to make sure everything is working correctly, before porting it to a service. When the code runs in an app on my dev machine, it can connect to the API on our testing server (using HTTPS).
I copied the exact same code to a Windows Service, and when that service is built, installed and started on my dev machine, it throws the exception "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel".
It appears that the service is not honoring the certificate in the Trusted Certificate store on my dev machine. I know the certificates are being honored by browsers, because when I remove it, the browser warns me about the web site not being secure. When I reinstall the certificate, the browser warning goes away.
I was expecting that the same self-signed certificate which allowed a browser to trust the server would allow my windows service to trust the server.
So, to sum up, I can reach my Web API running on our testing server from my dev machine via a browser (and HTTPS) without errors. I can reach the same API using code that is running in a desktop application. But as soon as that exact same code is in a Windows Service and installed on my dev machine, System.Net.WebClient suddenly has trust issues.
Do Windows Services have a different trust model or run with different privilege levels that I need to take into consideration? Or have I completely misunderstood certificates?
For what it's worth, the calling code is:
public class RequestHandler
{
private String URL { get; set; }
private WebClient Client { get; set; }
public RequestHandler(String url)
{
URL = url;
Client = new WebClient();
Client.Headers.Add(Constants.UserAgent, Constants.UserAgentValue);
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
}
public String GetData()
{
try
{
var response = Client.DownloadString(URL);
return (response);
}
catch (Exception e)
{
LogEvent(EventLogEntryType.Error, e.Message);
return (String.Empty);
}
}
I have azure VPN and installed certificates. My colleague has installed this same but he can not choose the certificate. He hasn`t got this field. Is possible to change something in VPN to get the list of certificates?
this is working when installing cert like this (checkboxes)
Please take a look at this page from Microsoft's documentation.
In a nutshell:
This problem occurs if the client certificate is missing from Certificates - Current User\Personal\Certificates.
I believe you've already installed the certificate on the first PC that connects successfully. Still, if you need to, you can generate and export certificates as follows: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site
I have designed a desktop application using windows forms app.
It will be receiving a pop-up message whenever an updated version is available on the server.
I have generated an API which consists of the updated version of the desktop application which is been used as the server with the help of the ngrok and I have enabled the SSL for the API. The SSL certificate is been installed into trusted root certification authority.
Now how to use the SSL for server validation(that is the clients who the SSL only need to hit the server and can download the updated version)?
Please, someone help me in solving this issue.
I want to publish my project but:
Error1
Web deployment task failed. (Could not complete the request to remote agent URL 'https://xxxxx:xxxx/msdeploy.axd?site=VoIP'.)
Could not complete the request to remote agent URL 'https://xxxxx:xxxx/msdeploy.axd?site=VoIP'.
The request was aborted: The request was canceled.
COM object that has been separated from its underlying RCW cannot be used.
Does anybody know what's wrong?
This is a bug and was fixed, but only if you have the Azure SDK:
Publish Wizard Errors in VS2010 and 2012
http://connect.microsoft.com/VisualStudio/feedback/details/773902/every-now-and-then-i-cant-publish-to-azure-get-com-object-that-has-been-separated-from-its-underlying-rcw-cannot-be-used
1) Open port 8172 on server if not
2) Make sure you have web deployment tools installed
In my case I found that internet proxy was enabled for the account, which was making the MSDeploy request to go to internet instead of local network.
In my case when I attempted to restart the Web Management service it would fail... Manually restarting using:
Net start wmsvc
gave me the response:
A service specific error occurred: 2147483656.
That led me to this article.
Effectively I had deleted the cert used by Management Services when updating my SSL certificates (forehead slap), and it didn't know which cert to use.
I went into IIS, clicked on the Server, double clicked the Management Service screen.
I then selected my new SSL Certificate, clicked apply, then restart and I was back in business.
I have a web service in production that is running over https using a certificate. I would like to deploy this to a staging server without a certificate.
So I believe my best approach is to migrate this to a http service on the staging server. I have modified the web.config and changed the security mode to none and can see the running in IE.
When I use a WebClient to access the service I get a 'The remote server returned an error: (403) Forbidden.' error message.
Can anyone give me some advice on this please?
Thanks
Al
I think it is a permission issue. Check all the permissions. If you had any more problems, you will get extensive error saying multiple things.
Check if you can connect using the WCF Test Client (you can find it inside Visual Studio's Common7 folder, or just search for wcftestclient.exe). If it can connect to the service, you can make it show you the .config files it uses (and you'll be able to cross-check them against yours).