Login to start a new topic

Enabling fiddler breaks IIS with Kernel-mode authentication

 I am trying to troubleshoot a problem with a third party web app, and the vendor refuses to investigate without Fiddler logs from a workstation.


The app is hosted locally on IIS in our network, and is using HTTPS issued by our domain CA. We are using NTLM and Negotiate authentication with kernel-mode auth enabled.


If I enable Fiddler decryption, external HTTPS sites work and decrypt without issue, but this site (and another internal IIS site with a similar configuration) prompt endlessly for credentials and/or return 401 unauthorized. I have searched and searched but can't find anything explaining how to solve this problem. The application pool is running under a domain service account per the vendor's setup directions.


I do see the NTLM and Negotiate headers in the request but something is clearly not right.


I am a sysadmin but I am not very experienced with IIS or web development so it may be something very obvious that I'm missing. Any help would be appreciated.


Hey Astadnick,


I assume that you are running a NET application with IIS under localhost. If that assumption is correct, you would probably need to configure the NET application via the web.config file (see this article) and/or try the listed localhost solutions. 

Not quite, this is a production internal server, access is from remote workstations over HTTPS signed by our domain CA.

The site is bound to the hostname in the SAN field of the cert (https://app.corp.mycompany.com). My normal account does not have login rights to the server locally so I can't easily test localhost either way.

Hey Astadnick,



Check the if Ignore server certificate errors (unsafe) option is enabled (from Settings > HTTPS).

I have tried this both ways with no change in behavior. I still get a continuous stream of 401 prompts every time I load the page if Fiddler is running.

OK, I am not sure what might be causing the 401 issues you are dealing with, but perhaps you could try an alternative solution to provide logs for further investigation. The team recently published Fiddler Jam, which can capture logs directly from within a Chromium browser. Perhaps you could try to generate a JAM log and send it to the vendor to investigate it using the Fiddler Jam dashboard (there is a free trial for the dashboard usage, and the extension is entirely free).


As for the 401 issue, could you check if the solution mentioned in this KB article is applicable for your case?

Login to start a new topic