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.
Related
I have an Authentication service built on Identity Server 3 and a set of WebAPI services using BearerTokenAuthentication. On startup, each of the WebAPI services makes a call to the Authentication service's .well-known/openid-configuration. That has been working fine until we recently configured the firewall between the WebAPI services and the Authentication service to only allow traffic with the TLS 1.2 protocol. Now the WebAPI services all fail to start and report that they cannot access the Authentication .well-known/openid-configuration because they "Could not create SSL/TLS secure channel".
Update: The problem described is occurring in my Test environment and is eliminated when we modify the firewall to allow TLS 1.0. In my Dev and Staging environments, the firewall is configured to require TLS 1.2 and that configuration is not producing the above symptoms. Something else is different. I just haven't figured out yet what it is.
Based on this latest update, I have a different question. Any suggestions on what to look for in the server/environment that would cause the TLS 1.2 requirement not to work in one environment while working in the other two? I've started to look at the registry settings that control the server's use of SSL and TLS protocols, but haven't found a difference there when comparing a working server to the non-working one.
Final Update: I never did figure out what was different. Someone from the systems group rebuilt the Test server, which was exhibiting the problem, by cloning the Staging server, which was not exhibiting the problem. The rebuilt server handles TLS 1.2 just fine. So it was clearly something in the server, not the code. But that's about all we know.
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.
I have an ASP.NET webservice which is deployed on Server2008 IIS7. We use two servers, Production and UAT (test server) and this webservice is deployed on both servers, the same compile is on both of them (no code changes, revisions etc, pure copy/paste from one to another).
The only difference between the applications is a connection string in web.config, one points to PROD database, the other UAT.
If I make a call to the test webservice I get an expected response and all is well, but when I do the same thing on the production webservice I promptly get and error
Server was unable to process request. ---> Object reference not set to an instance of an object.
I am suspecting there must be a configuration issue as the webservices are running under their own Pool which is run by a service account/user (local admin on the servers) and they are set to only run through SSL (https:// only) on a special port.
I tired sniffing with Fiddler and got two identical SOAP requests, the only difference being the server name in URL. I can access the WSDL of both webservices from IE browser, I can successfully refresh my web reference in Visual studio (for both prod and uat services).
Does anyone have any hints what should I be looking at, perhaps someone had a similar problem?
This is resolved. As I suspected the error was in production server configuration. When the sys team added a service user into the local Administrators they added it through Active directory groups, which as I am told requires a logoff/logon or a restart.
Server restart was the solution in my case.
I'm struggling to setup the environment in IIS8, I searched a lot but couldn't find a right solution.
I checked the error logs, but no idea.
C:\Windows\System32\LogFiles\HTTPERR
2013-10-09 09:28:39 192.168.43.205 60172 192.168.43.205 80 HTTP/1.1
GET / 503 2 AppOffline qa.hti.local
2013-10-09 09:28:39 192.168.43.205 60192 192.168.43.205 80 HTTP/1.1
GET /favicon.ico 503 2 AppOffline qa.hti.local
Then in Event Viewer:
WARNINGS:
A listener channel for protocol 'http' in worker process '11188'
serving application pool 'qa.hti.local' reported a listener channel
failure. The data field contains the error number.
A listener channel for protocol 'http' in worker process '7492'
serving application pool 'qa.hti.local' reported a listener channel
failure. The data field contains the error number.
A listener channel for protocol 'http' in worker process '9088'
serving application pool 'qa.hti.local' reported a listener channel
failure. The data field contains the error number.
A listener channel for protocol 'http' in worker process '9964'
serving application pool 'qa.hti.local' reported a listener channel
failure. The data field contains the error number.
A listener channel for protocol 'http' in worker process '7716'
serving application pool 'qa.hti.local' reported a listener channel
failure. The data field contains the error number.
I don't understand what the warning means.
ERROR: Application pool 'qa.hti.local' is being automatically disabled due to a series of failures in the process(es) serving that
application pool.
Note: I learned that consecutive 5 failures leads to APP Pool crash, and this can increased. I also tried increasing this but no success.
Please share your thoughts.
I came across this question as I was experiencing a similar issue and searching for a solution.
My problem specifically had to do with our IIS shared configuration. We had enabled a feature in IIS on one of the servers (Http Redirect) that was not installed on any of the others so the server 'features' were out of sync with all the servers.
I was able to resolve the issue by uninstalling the new addition on the first server so it was back to matching the others. An IIS reset later and the AppPools were no longer going down and all was back to normal.
So if you are using IIS Shared Configuration and the IIS is creating 'Service Unavailable' errors and the AppPools are going down, this can be a symptom of the system configuration being out of synch which is corrupting the shared configuration. Hopefully this post will help someone find the solution faster than I was able to.
I had a similar problem, and it was due to another error (2282 IIS-W3SVC-WP) that the pool stopped itself. My problem was that de module owssvr.dll could not be loaded due to a configuration problem.
The solution for me was to set the setting "Enable 32-bit applications" from True to false.
I was deploying a solution on Sharepoint 2013 on a Windows Server 2012 with Visual studio 2013.
I know this was supposedly a very specific problem, but I want to help all those with the same problem.
Propably you do not have the permissions to read the directory.
The directory (and the files) need to have read-access for either windows-group "USERS" or windows-grou "IIS_IUSRS" and also for your apppoolidentity.
This occurred for me too on Windows 10 1803 after an update.
Earlier in the event log there were errors to do with missing DLLS, specifically iiswsock.dll and compstat.dll.
After turning on the following Windows features (under IIS > WWWServices > Performance Features and AppDev Features):
Dynamic and Static Content Compression, and
WebSocket Protocol Windows features
those errors disappeared after an IIS restart.
503 2
Is that 2 the substatus code? If so, you might want to make sure your site is not being hit with excessively (5000+) # of requests.
http://support.microsoft.com/kb/943891
The data field contains the error number.
what's the error number?
This also can be caused by you're software vendor not realizing that they installed the 32bit version of the application pool apps on your 2008 R2 server. After a little troubleshooting my server because they wanted me to reinstall IIS i checked the windows app logs and emailed them the x86 architecture error for their app.
This can occur if a piece of IIS is missing (e.g. one of the many IIS modules has not been installed on the new server).
The thing to do is to carefully compare the IIS config of the source and target, and add the missing pieces to the target.
In a recent IIS8.5->8.5 migration, I had this issue. Went through the whole stack. The last piece was that the Web Cert auth piece of IIS was missing.
To install:
powershell
import-module servermanager
add-windowsfeature Web-Cert-Auth
I reinstalled server and copied applicationHost.config to new server, but not installed corresponding modules, and got this error. I fixed that by check modules in IIS manager and ensure modules are installed.
Update: In Windows Logs-> Application, there're some info about which module is missing.
In case this helps anyone else: We run multiple https sites on an IIS 10 server. One of the steps in configuring a new site is to give the new application pool permission to the system certificate. In the registry, under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\MY, grant the application pool on the local machine full control. That fixed this issue for us.
I had the same problem and solved it by adding the domain account the application pool was using as an identity to the local group of Administrators on a web server. Perhaps it would also do the trick to grant access to the application directory for the application pool identity account, as #Lisa-Berlin stated above.
I just got IIS7 set up on a Windows Server 2008 R2 machine in VirtualBox. After doing so, I could not connect from any other client, though http://localhost worked. For that matter, I was unable to even ping the server.
After doing some research, I found that enabling File and Print Sharing on the server solved the problem, but surely there has to be a better way, and I would much prefer to learn to use the best method, rather than the easiest one.
What, specifically, should I do to enable both pinging of the server as well as access to the web server running on it?
Isn't it that the inbound web HTTP port is blocked by default? I'm not a server guru but can remember going to the firewall to allow it through. Should already be there.
Out of the box on Windows Server 2008/2008R2 firewall is installed and users cannot access resources or services on the server unless you configure exceptions to the firewall. There is one exception to this are services/resources on this server that you make available through the GUI tools (Initial Configuration Tasks Wizard, Server manager) - these automatically create firewall required exceptions for you.
So in your case either upon File and Print Sharing installation or upon using File and Print Sharing config wizard/Shared resource provision wizard (most likely the later) required firewall exception was created for you. The rule in question is: File and Printer Sharing (Echo Request – ICMPv4-In) - actually allows ping, but I guess Windows also uses it for network resources discovery and other things implied by the role you installed.
Nothing prevents you from not enabling File and Print Sharing and just enabling mentioned firewall exception manually.