We have a ColdFusion 11 website, requiring client certificates, running on a publicly accessible Windows Server 2012R2 running IIS 8.5. There is a URL rewrite rule in place to remove the value set in the response header for Server. This rule is effective when a valid client certificate is presented, but if the client computer has no client cert or if the prompt for the client cert is canceled then the rewrite rule is ignored or bypassed, and the response header reports the IIS version. The IIS logs indicate that the appropriate 403.7 response is being returned. Configuring the rewrite rule at the level of either the server or the site results in the exact same behavior.

We have a similar server running a .NET application which processes the rewrite rule regardless of the action taken with respect to the client cert prompt. (There is yet another server with a .NET application which fails like the ColdFusion site.) Comparing web.configs, IIS site settings, and even applicationHost.config, has yielded no distinctions that have been able to account for this difference in behavior. (This is not to say that the answer is not there, just that I haven’t identified it as such.)

For example, using browser dev tools on a computer with no client certs, all attempts to these sites result in a 403 response. In the Response Header details, IE, Edge, and Firefox display the IIS version for the ‘bad’ servers, but the rewrite rule value for the ‘good’ servers. Chrome reports ‘Failed to load response data’ for all servers.

Given that the bad behavior is exhibited on both .NET and ColdFusion sites, I suspect that the issue is in the Windows / IIS system and is happening before ColdFusion is in the picture, but I can’t find enough information online to focus my investigation further. What I have read indicates that since the response isn’t Microsoft-HTTPAPI/2.0, the request is getting past http.sys. This, and the fact that the response code is 403.7 (Forbidden: Client Certificate Required) suggests that it is in fact getting to IIS, but why isn’t the rewrite rule being respected?

Can anyone point me to the configuration setting(s) that could be responsible for the difference in behavior between these servers, or to a resource that could help me understand the relationship between IIS and http.sys which may be affecting the issue? I found a post on Server Fault a week or so ago that seemed to have a glimmer of a hope, but after shutting down for the night have not been able to reproduce the search to get back to it; grrrr. Thanks in advance.

  • Sounds like a bug of IIS. Your only feasible option is to set up a reverse proxy in front (like nginx) and remove such headers from the responses.
    – Lex Li
    Commented May 14, 2020 at 4:20
  • Have you tried using Failed Request Tracing on both types of servers and compared the output there? Commented May 14, 2020 at 5:02
  • @PeterHahndorf: I have not tried Failed Request Tracing; that is unfamiliar ground for me. I will investigate and report my results. Thank you for the suggestion. Commented May 18, 2020 at 18:33


You must log in to answer this question.