Tip #810: Using Fiddler with Xrm Tooling

Sometimes it’s very useful to see what requests are flying forth and back between your code and Dynamics 365. The tool of trade is, of course, Fiddler. Fiddler allows https traffic analysis by using man-in-the-middle interception using self-signed certificates.

If you are using Xrm Tooling and, specifically, CrmServiceClient then you quickly find that the following code:

var s = 
 @"Url=https://a.crm.dynamics.com;AuthType=Office365;
   UserName=foo@a.onmicrosoft.com;Password=strongone";

using (var crmSvc = new CrmServiceClient(s))
{
   Console.WriteLine($"{crmSvc.IsReady}");
   if(crmSvc.IsReady) 
   {
      Console.WriteLine(
      $"{crmSvc.ConnectedOrgFriendlyName}");
   }
   else 
   {
      Console.WriteLine("Doh!");
   }
}

generates a friendly “Doh!” instead of a friendly organization name.
The logs will show the following error: The remote certificate is invalid according to the validation procedure, and it’s fair enough as Fiddler certificates are self-signed.

If you do want that trace, there is a silver bullet and a brilliantly concise gun to fire it. Just add the following code before creating CrmServiceClient:

ServicePointManager
   .ServerCertificateValidationCallback +=
   (sender, cert, chain, sslPolicyErrors) => true;

Happy debugging!

Tweet about this on TwitterShare on Facebook4Share on Google+2

One thought on “Tip #810: Using Fiddler with Xrm Tooling

  1. Chris Groh says:

    This should include a VERY strong disclaimer as it trusts any certificate. I’ve seen this code accidentally get into production before. This allows anyone to do a MITM attack to pull both your CRM credentials and any other data that uses ServicePointManager to connect within the same .net application. Even in dev it can be dangerous since dev environments often contain sensitive information or use the same credentials as production. (A more out-of-the way attack would be the attacker using dev admin credentials to put evil code into a web resource or plugin and hope that you deploy it to production.)

    Fiddler does add an extra layer of certificate validation checks while it is enabled where it will prompt you about invalid certificates but running that code when fiddler is off or running the code then turning off Fiddler is extremely dangerous.

    The better way to do this is to add the fiddler certificate to the Trusted Root Certificate Authority for the account running the process. You could also manually verify that the hash matches the fiddler certificate using something like this: http://stackoverflow.com/a/526803/7223314

Leave a Reply

Your email address will not be published. Required fields are marked *