Module set response error status

HTTP Error 500.0 — Internal Server Error

The page cannot be displayed because an internal server error has occurred.

During the course of my work i have observed that troubleshooting client certificate authentication seems bit challenging as there is not much tools to collect appropriate data for it. However i am correlating a list of check points which has always helped me.

When you have enabled client certificate authentication either using AD client certificate authentication or IIS client certificate mapping authentication you can follow the below steps in general.

The most common error or status code you would face with respect to client certificate authentication is 403.7 which means the server is expecting a client certificate but the client is not sending it.

Follow the steps in order to check what the issue might be

1) Make sure you have set Require for client certificate in SSL settings in IIS

2) When using IIS client certificate mapping we either use one to one mapping where we map individual certificate to an user or many to one mapping where we map all the certificates matching a criteria to a single user. The one to one mapping or the many to one mapping should be created at the site level. The most common mistake, I have seen is if people want to use client certificate authentication to a specific application under a site, they create the mappings at the application level which is wrong. You will have to create the mappings at the site level and enable client certificate authentication at the required level. The mappings will only be read at the site level and any mapping at the application level will be ignored. This is not mentioned in most of the internet articles.

3) On the client machine in IE make sure you go to Internet Options->Security->Intranet or Internet(Based on the type of site)->Miscellaneous->Don’t prompt for client certificate when only one certificate is disabled. We need to make sure it is disabled so that at least we get to know if we get a prompt for certificate selection and if this fails out after clicking on certificate or without even sending a certificate.

4) In the client machine, confirm that the client certificate has a private key. You can check this by going to mmc->Add or remove snapin->Certificates(My User Account)->Personal->Certificates and then select the client certificate which you have installed for authentication. If the certificate is proper then you should be able to see the private key as below. ALso you can run the below command to check the validity of the certificate

certutil –verifystore my <Thumbprint of the certificate>

5)  Also go to details tab of the certificate and click on Enhanced Key usage where you should see that this certificate is intended for client certificate authentication which also validates the certificate to be a genuine client certificate.

6) If you go to the Certification Path tab in the certificate, you will be able to see the certificate chain. Double Click on each certificate in the chain and make a note of it.

7) In the certification path the certificate at the top is called the Root Certificate and the certificates in between the Root CA and the actual certificate in the chain are called Intermediate CA’s. In the above image there is a single intermediary CA but there can be more than one intermediary CA as well. In the server machine and as well as the client machine go to mmc->Add or Remove Snapin->Certificates Local Computer->Trusted Root Certification Authorities->Certificates, make sure the Root CA is present in this location. Next go to Intermediate Certification Authorities->Certificates and make sure the Intermediate CA’s are present there. This step is important because during SSL handshake when the server requests for the client certificate it sends the list of Trusted Issuer List which will contain the list of the Trusted Root CA’s installed on the server to the client and based on the that the client certificate to be sent is chosen.

Note: By default as mentioned above the Trusted issuer list is sent along with the certificate request during SSL handshake but this behaviour changed from windows 2012 or IIS 8 and onwards. In IIS 8 and onwards by default we don’t send any Trusted Issuer list. If we don’t send any Trusted Issuer List then the client has the freedom of selecting any client certificate in its store.

The feature of sending the CTL or trusted list can also be controlled by setting the below registry key which can be used from windows 2008 and onwards. If the value is set to 1 then the list is send and if the value is 0 then the list will not be sent. In windows 2012 and onwards the default value is 0 and in the lower versions the default value is 1 if the key is not present.

9) There is one more thing you need to cross check if this is a windows 2012 (IIS and higher machine. By default the CTL is off, if the CTL is on and if in the server mmc->Add or Remove Snapin->Certificates Local Computer->Trusted Root Certification Authorities->Certificates you have a non-self signed certificate then you might receive a 403.7 error as well. More details on the issue is logged in the below kb. The solution is to delete the non-self signed certificate from the Trusted Root Certification Authority

https://support.microsoft.com/en-in/kb/2802568

Note: A self-signed certificate is a certificate where the issuer and issued to fields will be same. A root certificate authority will always have a self signed certificate and hence if there are non-self signed certificates in the Trusted Root Certificate Store then that certificate is not a valid Root CA.

10) Thanks to Daniel Stolt, i had missed out a point. If the client is a web application or a web service and you are sending the client certificate from the code then the additional thing you will have to check is if the identity of the client application has permissions on the machine key for the client certificate. There are 2 ways you can do it.

Method A: Go to mmc->Add or Remove Snapin->Certificates Local Computer or Current User->Personal->Certificates. Right Click on the correct client certificate->Manage Private Keys and give permissions to the identity or user under which the client application is running.

Method B: This is bit complicated but interesting method. In this method we find out the machine key linked with the client certificate and then give the proper permissions required.

a. Download and install «find private key» application
http://blog.rhysgoodwin.com/windows-admin/findprivatekey-exe-pre-compiled/

b.  Find the Thumbprint of the client certificate
Run -> MMC -> File-> ADD or REMOVE SNAP IN->certificates-> Local Computer or Current User->Ok
Expand Personal->Certificates->Choose the appropriate certificate and open it
In the certificate->details tab->Thumbprint->Copy it

c. find the private key path for the certificate suing the thumbprint copied
Syntax:
FindprivateKey.exe My LocalMachine -t «THumbprint of the certificate»

d. Next, we need to provide permissions to application pool account to certificate

syntax (account to use : app pool identity — in our case it is NetworkService):
icacls «private key file path» /grant «Account»:R

11) Also several times i have seen that 403.7 is just masking the actual error. On the client you get a 403.7 but there might be a different error before that. For this please check the logs. One common scenario i have seen is as below. We see a 500 just before the 403.7 error and this is visible in logs as below

2015-09-06 15:46:29 W3SVC1 — GET / – 443 – 10.10.10.100 Mozilla/5.0+(compatible;+MSIE+10.0;+Windows+NT+6.1;+WOW64;+Trident/6.0) – — chiranth.com 500 0 64 0

If we take Failed request traces for the 500 we see below

In this scenario normally you would have got a prompt for the certificate in IE but you end you getting 403.7 still in the end because the certificate was not read completely. Normally when we just set certificate to Require in SSL settings, the client certificate negotiation happens in later part of the request. To avoid the above error we have to enable clientcertificatenegotiation so that the negotiation happens during ssl handshake during the server hello is sent. To enable client cert negotiation you can follow the below blog

http://blogs.iis.net/rickbarber/require-client-certificates-in-iis-7-5

The blog talks on how to enable by deleting and recreating the bindings from command prompt. There is also a hack which we can follow as below.

For example if you have a SSL binding for IP: PORT 10.10.10.10:443 then traverse to the registry path HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesHTTPParametersSslBindingInfo10.10.10.10:443

Create a DWORD called DefaultFlags and set the value to 2. The commands mentioned in the blog also does the same

The above changes require a machine reboot to take effect.

12) The above steps sums up the configuration part from the client and server perspective. But i have seen 403.7 error pop because of network issues as well. I have seen the issue happen If there is some intermediary device or firewall or proxy which doesn’t support client certificate authentication or negotiation. If we have set clientcertificatenegotitation as above then we will be able to see the client certificate request in the earlier stage of the handshake itself as below

if we don’t have clientcertificatenegotiation then we might not be able to see the certificate request(Server Hello) in the handshake as it might happen later and it will be encrypted.

If you have the setting enabled and you still don’t see the client certificate request and see something like below then this is a possible issue with a network device

As one more final step you can also try enabling SCHANNEL logging. Steps are in the below link

https://blogs.msdn.microsoft.com/chiranth/2014/02/18/ssl-troubleshooting-troubleshooting-steps-for-s…

Hope this helps

Author: Chiranth Ramaswamy

HttpStatus=»500″, HttpReason=»Internal Server Error», HttpSubStatus=»0″, ErrorCode=»The filename, directory name, or volume label syntax is incorrect. (0x8007007b)», ConfigExceptionInfo=»»

Does anyone have any idea where I can go to correct the apparent flaw in the path? I have checked the web.config file and several other configuration files but can’t find where this path is being picked up. I am fairly certain that I can resolve the problem if I can target the source unless it is actually being generated within another dll.

I am running Windows Vista Ultimate with SP1, .NET 3.5 and IIS 7.0.

I’ve tried ASPNET forums but I figured since this is an SSRS app that this forum may be more appropriate for the post.

Any assistance or advice toward resolving this problem would be greatly appreciated.

Источник

Troubleshoot IIS7 errors like a pro

So you just moved your application to an IIS7 server, and now you are getting an error when you make a request to it. This seems to be a popular theme on IIS.NET forums these days, and after answering a hundred or so of these posts, I figured I should do something to help people track down and fix their issues with a little less frustration.

It can be very hard to link generic IIS errors to underlying issues that you can fix. Head over to LeanSentry to get a comprehensive application checkup. We’ll find your actual IIS and ASP.NET issues, and even show you how to fix them in code.

Server software, and web servers specifically, are very complex and highly configurable systems that support multi-tier applications using a variety of technologies and subsystems, and endure further complexity due to security, performance, and reliability demands, so it’s a wonder it all works as well as it does in the end. IIS7 strives to improve the experience of diagnosing and solving problems when they do occur, so knowing how to use the new IIS7 diagnostics features can come a long way in helping you become a pro at troubleshooting server problems.

First things first – what’s the problem?

I often find myself asking this question on the forums when someone posts something like “Help, I moved to IIS7 and now my application doesn’t work!”. Huh, what doesnt work? When your site stops working, the first thing you need to do is determine what the error actually is before we can move any further. IIS7 has much better error messages that will often tell you exactly what the problem is, and help you fix it.

Unfortunately, sometimes getting to this error is the main challenge. Let’s look at a few things you may need to do to get there:

1) Disable IE “Friendly HTTP error messages”
IE will by default replace the actual error messages coming from the server with a “friendly” error message, which hides the error contents we need to see. For example, for a 404 Not Found error, you may instead see the following:

To disable this and see the real error coming from the server, you need to go to “Tools > Internet Options”, choose the Advanced tab, and clear the “Show friendly HTTP error messages” checkbox. Then, close the browser, open it again, and re-request the page.

Now, suppose you are still seeing the generic “cannot display the webpage” or “page not found” error. This is typically caused by IE failing to connect to your website, so there is no server error message to look at here. I have a detailed guide to troubleshooting this condition here: Where did my IIS7 server go? Troubleshooting “server not found” errors .

An aside : If you don’t want to mess with IE for troubleshooting (especially if you suspect you are getting cached pages, due to IE’s super- aggressive caching), the best thing to do is break out a trusty simple http tool of choice and make the request with it. I recommend WFETCH, which is included in the IIS6 Resource Kit tools (you can install on XP/Windows 2003 only, and can either run it from there or copy wfetch.exe to your Vista/LHS box).

2) Enable IIS7 detailed errors
IIS7 introduces a new custom errors feature, which by default hides the error responses issued by the server to remote clients, replacing them with a basic error message. This is critical for security of your site, as errors frequently contain sensitive information that you don’t want others to see, but makes getting to the bottom of the problem harder since you cannot see those very error details. So, if you are requesting your site from another machine, you may still get a basic error that looks like this:

You have two options here:

1) Make the request locally from the server machine.
By default, you will get the detailed error.

2) Enable detailed errors for remote clients.
First, if your error is an ASP.NET exception (you can tell if it says “Runtime Error” and has the framework version), please be aware that ASP.NET overrides the IIS custom error mechanism with its own implementation of custom errors, so you should turn the ASP.NET custom errors off to see detailed ASP.NET exceptions. You DO NOT have to configure IIS7 custom errors for ASP.NET exceptions (it would be silly to have to do it in two places). To turn off ASP.NET custom errors, place the following in your web.config:

If the error is not an ASP.NET error, turning off IIS7 custom errors will allow error responses from your application to be sent to remote clients without being censored by the IIS7’s custom errors module.

You can do this from the IIS7 Admin tool by running “Start>Run>inetmgr.exe”, selecting your website/application/virtual directory in the left-hand tree view, clicking on the “Error Pages” icon, clicking “Edit Feature Settings” action, and then selecting “Detailed Errors”.

You can alternatively do this from an elevated command line prompt (Run as Administrator):

> %windir%system32inetsrvappcmd.exe set config “Default Web Site/yourapp” /section:httpErrors /errorMode:Detailed

Where “Default Web Site” should be replaced with your site’s name if different, and “/yourapp” with the virtual path you’d like to enable detailed errors for.

NOTE: When you are done debugging, please return the settings back to custom errors for remote requests, or the security of your website may be compromised. Here is how to do it with AppCmd:

> %windir%system32inetsrvappcmd.exe set config “Default Web Site/yourapp” /section:httpErrors /errorMode:DetailedLocalOnly

Now, you should be getting detailed errors back – for example, the error I was getting before now looks like this (this is the Vista error page – Longhorn Server and Vista SP1 error pages will look much nicer, see this for an example ):

Notice that this error contains quite a bit of useful information:
1) The heading contains the substatus code, 404.0, which is an IIS specific code that further describes the problem. The majority of common errors has a unique . combination that you can easily google for additional information.
2) The page indicates what module (IIS Web Core), and in what notification (MapRequestHandler) an error occurred. This information is critical whenever you are debugging server problems, especially on the IIS7+ world when most of them occur in one of the modules that take part in the processing of the request.
3) The page shows you some useful request information, such as the requested url and the physical path to which it resolved. Most 404 errors will be resolved right here, by seeing that the request is being made to a wrong url or resolving to a wrong physical path due to incorrect virtual directory mapping.
4) The “most likely causes” and “what you can try” sections offer the most likely explanation for the error and what you can do about it. They are dead on for the majority of common IIS7 errors.

NOTE: When you are coming to the forums with an error, we expect you to have gotten this far and that you will provide the detailed error to help us with your problem. For more information about the custom errors support in IIS7, check out http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Diagnostics-in-IIS7/Deciphering-Error-Messages/How-to-Use-HTTP-Detailed-Errors-in-IIS7 .

3) Detour – the 503 “Service Unavailable” error
Sometimes, you will get an error that looks like this:

This error most likely either indicates a critical misconfiguration of the server that is causing IIS to fail to start a worker process/process your request, or a system overload condition that is causing requests to be rejected early, so no further error information will be available in the response. If you are getting this error, please follow my detailed guide: Where did my IIS7 server go? Troubleshooting “service unavailable” errors .

Deeper diagnostics with Failed Request Tracing (formerly known as FREB)

If the error alone is not sufficient to diagnose the condition, or more information is needed to determine what lead up to the error occurring, or, there is no error (for example, request times out), you can take advantage of the wonderful IIS7 feature called “Failed Request Tracing”.

This feature can be used to generate a detailed trace of events leading up to the failure, much like ETW, but now with more/more useful events and significantly easier to turn on and use for troubleshooting.

More importantly, you can configure Failed Request Tracing to only trace requests that encounter a specific failure condition, such as a specific response status/substatus codes, an event of specific verbosity, or a timeout.

To do this, you are going to need to install it first (if you haven’t already):
On Vista : Control Panel, Programs, Turn Windows Features on or off, check Internet Information ServicesWorld Wide Web ServicesHealth and DiagnosticsTracing.
On Windows Server 2008 : Start>Run>Server Manager, Roles, Web Server(IIS), Add Role Services, check Web ServerHealth and DiagnosticsTracing

Then, to enable IIS to generate these logs, you need to do two things:
1) Enable Failed Request Tracing for the site you want to trace

In InetMgr, select your site in the left-hand tree view, then under Actions on the right click “Failed Request Tracing …”. There, select the Enable box.

2) Create a Failed Request Tracing rule with the events and failure definition of choice

In InetMgr, select the site/application/virtual directory that you’d like to trace in the tree view, click the “Failed Request Tracing Rules” icon, click the “Add…” action, and follow the wizard to create the rule.

You will be asked what content you’d like to trace (based on an extension), when to consider the request as failed (a list of response status codes, and in Longhorn Server, also event verbosity) or a timeout, and finally the events you’d like to trace. I recommend to leave all events selected by default, unless you are sure you know what you are looking for.

Now, when you make a request, if it meets the failure definition, the detailed trace will be logged as an XML file that you can inspect (or send to us for inspection).

You can by default find this file in %systemdrive%inetpublogsFailedReqLogFilesW3SVC folder.

If you double-click this file, it will open with the provided XSL stylesheet that shows the trace events. In Longhorn Server, this stylesheet has gotten a major overhaul to highlight the important information better – for more information, see this: http://blogs.iis.net/bills/archive/2006/10/19/Making-Failed-Request-Tracing-More-Approachable.aspx . You can download the new stylesheet and use it today for your Vista machine.

The Failed Request Tracing log provides verbose execution information for the request, that can be used in a number of ways to further diagnose more complex problems that may result from the operation of more than one module. For example, if a url rewriter module changes a url in the request, which later leads to the static file handler failing to find the file, the SetUrl event can provide the needed information. The log also provides such key info as the times taken by each module to execute, the outcome of each of the built-in module’s operation (often including the reason why something didn’t work), and any times when a module fails a request by setting an error response status code.

Finally, one of the main strengths of Failed Request Tracing is that you do not have to be the client to receive the error information. As an administrator, you can configure it to monitor for errors and log the forensic trace when they occur, allowing you to just leave the feature on in production. Think of it as request logs on steroids. To learn more about Failed Request Tracing, see http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Diagnostics-in-IIS7/Using-Failed-Request-Tracing/Troubleshooting-Failed-Requests-using-Tracing-in-I .

I will post more specific strategies on how to troubleshoot with Failed Request Tracing logs in a future post. In the meantime, you should now be a lot more prepared to deal with errors when they occur, and resolve them before you type that first forum post. And if you do make a post (which you are welcome to do), you’ll be able to provide us with the key information to help you solve your problem.

Источник

Adblock
detector