WCF call working when Fiddler On, else gives 400 Bad Request while debugging

Question

Not Solved - still looking for a solution.

I am making a WCF call passing in a SAML Token:

Using SAML token with Web Service (wsdl)

private static string serviceEndpoint = "https service endpoint";
    public static void CallProviderService(SecurityToken token)
    {
        var binding = new WS2007FederationHttpBinding(WSFederationHttpSecurityMode.TransportWithMessageCredential);
        binding.Security.Message.EstablishSecurityContext = false;
        binding.Security.Message.IssuedKeyType = SecurityKeyType.BearerKey;

        var channelFactory = new ChannelFactory<ISomeProviderService>(binding, new EndpointAddress(new Uri(serviceEndpoint)));
        string thumb = "mycertthumbprint";
        channelFactory.Credentials.ClientCertificate.SetCertificate(StoreLocation.CurrentUser, StoreName.My, X509FindType.FindByThumbprint, thumb);
        channelFactory.Credentials.ServiceCertificate.Authentication.CertificateValidationMode = System.ServiceModel.Security.X509CertificateValidationMode.PeerOrChainTrust;
        channelFactory.ConfigureChannelFactory();
        channelFactory.Credentials.SupportInteractive = false;

var elements = service.Endpoint.Binding.CreateBindingElements();
elements.Find<SecurityBindingElement>().EnableUnsecuredResponse = true;
service.Endpoint.Binding = new CustomBinding(elements);

        var channel = channelFactory.CreateChannelWithIssuedToken<ISomeProviderService>(token);

        try
        {
            var response = channel.MyServiceMethod(somedataobject);
        }

        catch (Exception ex)
        {
           //log message
        }
    }

When I had fiddler running the call worked find and returned me data.

With fiddler off, I get 400 Bad Request error in my catch block.

My doubt is the certificate isn't being passed when Fiddler is off.

Any idea?

Note: I have a .wsdl which I used to create proxy classes using Visual Studio ->Add Service Reference.

Question: How can I check if my installed certificate is used while making this https service call?

Updated: Here are the Req/Response from Fiddler:

Tunnel Request:

Tunnel Response:

Protocol Exception details:

From Client after Server Certificate Request:

Update 12/8/2014: I think I have got one time success using the binding in this link: WCF custom binding that will support HTTPS, a signed certificate and a signed username token

I will update more as I don't know what that is doing much.

Answer 1

Due to very abundance of scenarios (and questions) like these, Eric Lawrence has written a blog post - Help! Running Fiddler Fixes My App???, just for this.

Following section from the post, seems relevant to your problem -

---

HTTPS Issues

Some users find that HTTPS traffic only works when Fiddler is running and decrypting secure traffic.

Certificate Errors

By default, Fiddler warns you about invalid certificates when connecting to HTTPS sites:

See image in original post

If you elect to ignore this warning, Fiddler will effectively “hide” the certificate error from the client application, such that it only sees the certificate Fiddler generated for HTTPS interception.

Most browsers show a meaningful error message if they encounter an invalid certificate:

See image in original post

…but many applications will fail silently or with a confusing error message. Even within the browser, sometimes no error message is shown (e.g. when using XmlHttpRequest).

The fix here is simple: Correct or replace the server’s certificate.

Answer 2

Checking the cert.

There are potentially two client certificates. The one used on the TLS session and the one used in the SAML Token/SOAP message. Typically they are the same cert. But added by different parts of the code.

Fiddler only knows about the TLS cert. If you had to add the TLS client cert to fiddler, then it could be this indeed. Test is simple, remove it from the Fiddler directory. If it stops working......

If you want to see the TLS client cert then you could make a trace with your favorite Network trace tool (NetMon, MessageAnalyser, WireShark, whatever). Put it on the outgoing network adapter and take a look at the difference in the TLS messages. You probably have to give the private key to the trace tool. Because the client certificate is exchanged when it is already encrypted.....

Another option is to use the Schannel built in trace, but I haven't had time to figure out how that one works, because the network trace was always possible in my test environments.

Answer 3

Can you switch certificate validation mode from below options and try -

1. ChainTrust
2. None
3. PeerOrChainTrust
4. PeerTrust