We are getting following error in Microsoft EDGE in our Dev environment when we run our ASP.NET Application Hosted in IIS 8 in Windows 2012 R2 Server.
Error:
XMLHttpRequest: Network Error 0x800c0019, Security certificate required to access this resource is invalid.
Following are more details about implementations and environments.
Our application runs on 2 different secured ports (HTTPS). In IIS both apps are hosting as different Web Applications and using same certificate. The certificate is generated using OpenSSL SHA2 encryption and it has been added in Secured Certificate Store.
From `Microsoft EDGE when we first load our application, it issues certificate warning message, and we are allowing to proceed. Once page is loaded, on a button click we are calling an API using AJAX call and that is hosted on different port.
In EDGE it is not allowing to proceed that API and giving above mentioned error.
In Chrome and IE 11 also, we are getting same warning message but from there it is allowing to execute next API.
Any help would be appreciated to fix the issue.
If you know your certificate is valid, a possible reason this might happen is if you have a tool running in the background somewhere that hijacks the SSL connections through a proxy, such as Fiddler.
Since such a tool is effectively using a man-in-the-middle attack to report the requests, the warnings are "normal". It's pretty easy to forget them running, too.
Related
I have a Blazor Server Application that is invoking a 3rd party API using IHttpClientFactory. When I execute the calling code on my local Windows 11 machine I receive the exception below. However, If I run the same code from an Azure Web App, the API is called successfully.
Error: System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
System.Security.Authentication.AuthenticationException: Authentication failed because the remote party sent a TLS alert: '112'.
I have attempted setting the Security protocol to TLS1.2 using the ServicePointManager, however, this does not make a difference. I have run Wireshark to glean some additional information, but all I can see is that my machine is initiating the call with TLS 1.2.
Does anyone have an idea as to why my code works in Azure, but not in my local development environment?
According to the behavior in azure web app, I think the issue should related to environment.
And if you have another os version pc, you can test it, and it should be work normally.
And I found the workaround in win11. You can add the registry key and removed the code to set the protocol to TLS1.2, and the TLS handshake worked from your Windows 11 system.
We have run into a problem with IIS, TLS 1.2 and domain users. I searched SO and other forums, but all possibly related topics didn't lead me to a solution.
Please don't judge the configuration, it wasn't invented by me, I just need to solve this problem.
What happens is the following:
We have an old web application, that opens an executable with Process.Start and that executable calls an external webservice. This used to work fine with TLS 1.0, but in the near future, the external webservice demands TLS 1.2.
So now we are trying to make this work, and we are almost there: we upgraded the executable's .Net Framework version to 4.7.2 and enabled TLS 1.2 on the Windows Server 2008 R2. The web app's .Net Framework version is set to 4.6.1. It seems to me that this should be everything there is to it.
And indeed, when we run the executable stand alone (not called by the web app) from the server, so owned by the domain user logged on to the server (with RDP), everything works as expected; we receive the proper answer from the web service.
Also, when we call the executable by the web app and in IIS the application pool identity is set to a build in account: ApplicationPoolIdentity, everything works as expected as well.
But, when we set the application pool identity to a dedicated domain account (so a different one than the one that executed the executable earlier), the trouble begins. Connecting the web service fails with the following exception:
System.ServiceModel.EndpointNotFoundException: There was no endpoint
listening at https://<some url>/<some webservice name>.asmx that could
accept the message. This is often caused by an incorrect address or
SOAP action. See InnerException, if present, for more details. --->
System.Net.WebException: Unable to connect to the remote server
---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond ...
Now the question is of course, what could be causing this?
I like to believe that the failing domain account is configured correctly, but it seems it is not. Or could it be something else, that I don't even know the existence of...
EDIT:
I managed to narrow it down to a permissions issue: when the dedicated domain account runs the application stand alone, it works as it should. When the dedicated account runs it from within the IIS context (started by the web app), it doesn't work, but when the dedicated account is given admin rights, it also works as expected.
That leaves me to the question: what additional permissions does IIS need to allow this setup? Maybe in combination with TLS 1.2 thingies.
Any help would be greatly appreciated.
Followed the instructions in https://msdn.microsoft.com/en-us/library/gg492140.aspx
SSAS is running on a hosted server. No domain.
Able to connect with anonymous authentication, but when basic is enabled, neither SSMS or Excel will connect.
Error from SSMS is "The remote server returned an error (401). Unauthorized"
Credentials are set up on the remote machine as DOMAIN:443
Credentials have admin privileges on the server.
Excel says "connection cannot be made to remote machine or SSAS is not running"
HTTP or HTTPS doesn't matter.
When it connects with anonymous, no cubes are returned so it is apparently doing nothing with the userid/password. Just connecting.
When I connect via port 2383 using the same credentials, I have no problem in SSMS or Excel.
Help is GREATLY appreciated. Thanks.
This was partially solved by starting over and following the steps in this article:
https://technet.microsoft.com/en-us/library/cc917670.aspx
Honestly, I can't pin down the exact resolution, but I believe it has to do with using a different folder structure (other than inetpub/wwwroot...) on my D drive and therefore losing the standard security configuration.
I created an OLAP folder on C:/inetpub/wwwroot and it works... with the exception of SSL which still does not work.
HTTP connects fine, but not HTTPS. Still working on that.
There are many versions of this question on stackoverflow. I have tried a lot of the solutions suggested there - but none of these work for me.
I have a VB ASP.NET application running on IIS on Windows Server 2008. It calls a webservice. The Server running the Web Service has a self signed certificate. I have imported the Cert into the Trust Store of the IIS machine. I can see the certificate in IE->Options->Content->Certificates->Trusted Root Certification Authorities.
When the webservice is called, an exception is thrown
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The same IIS VB ASP.NET Application runs fine on another machine with a similar setup.
These are the different basic things I have checked
The URL used to call the webservice is the same as the CN on the Cert imported into the Trusted Root CA.
Time is synced between the calling machine and the webservice host
The Cert isn't expired.
The IIS machine has Proxy settings in IIS, but Webservice Host machine as added to list of exceptions where Proxy should not be used.
I wrote a small command line test program in VB.NET calling the same webservice which runs fine.
After importing the Cert into the Trusted CA store, I have done a iisreset.
Only thing I haven't tried yet is rebooting the IIS machine - this is production machine & I cannot reboot it for at least a couple of days.
What else can I try?
Internet Explorer certificate settings apply only to the current user. It's highly unlikely that the same user you're logged in as when operating IE is the same as the one being used to host the IIS application. You could add the certificate to the trusted certs for the appropriate service account, but a simpler approach would be to add it to the "Local Computer" trusted certs.
Run Microsoft Management Console (type "mmc" in run dialog) File > Add / Remove Snap-Ins > Certificates, chose "Computer account" for the certificates to manage. This way, any user or service account on the server will see the certificate as trusted.
Alternatively, depending on how you're accessing the web-service, you could add an exception within the application itself. I would recommend code that checks the thumbprint / hash of the certificate though, as opposed to allowing it to connect to any un-trusted certificate.
How do i check the client browser SSL certificate in my ASP.net code behind
I want to ensure that if any https proxy like fiddler is running then my application does not load
I have done the following till now without any success:
My site is on Https
In IIS i have set
Require SSL= true
Require 128 bit encryption =true
accept certificate = true
in my default.aspx Page_Load i am trying to read the value of Request.ClientCertificate, the collection is coming as empty.
There is no way to do what you're trying to do unless you run an ActiveX control on the client.
Internet Explorer and other browsers do not expose the server's SSL certificate information to the JavaScript in the page, meaning that there's no way for your page, running on the client, to know whether or not it was delivered with your certificate or another certificate.
Having said that, even if such a method was offered, it probably wouldn't help you anyway. Presumably, you want to do this to prevent viewing/modification of your traffic, but there are other tools that plug into the browser directly (post HTTPS-decryption, pre HTTPS-encryption) that can view/modify traffic without resigning it as Fiddler and other proxies do.
Furthermore, your code would fail in corporate environments where the edge proxy (e.g. BlueCoat, Forefront) does content-inspection using the same mechanisms that Fiddler uses.
Are you expecting the client to have a certificate installed? Most users do not have client certificates installed.
Nonetheless, I'm not sure how exactly a client certificate is going to protect you in the situation you describe...