Case 1 involves TLS + client certificate authentication with both client and server using secp384 based EC certificates. In this case, when monitoring traffic via fiddler, the tunneling/handshaking as well as encrypted traffic is completely missing from fiddler (as if nothing is happening). We know there is real traffic by monitoring both client and server individually.

Case 2 involves the same client process, same server process, same server certificate but client certificate authentication is disabled. In this case all the traffic as well as the initial handshake is captured within Fiddler.

Is this a known limitation of Fiddler? If yes, how else can I capture the TLS handshake that happens in Case 1? If not, am I missing a setting inside Fiddler? I have aC:\Users\<username>\My Documents\Fiddler2\ClientCertificate.cer setup too ...

1 Answer 1


Fiddler captures HTTPS traffic by generating on-the-fly a fake certificate for the intended server, thereby running a complete Man-in-the-Middle attack. This requires that the client is configured to accept the Fiddler-controlled CA as a trusted CA, as described in the documentation.

This kind of interception breaks client certificates. When there is a client certificate in SSL/TLS, the client technically signs (during the handshake) what amounts to a hash of all received and sent handshake messages so far; the signature computed by the client will then cover (among other things) the server's certificate as seen from the client, i.e. the fake one generated by Fiddler, not the genuine server's certificate. Therefore, the client signature will not match the handshake messages that the server saw.

If the documentation is to be believed, then Fiddler can fix that, but this requires Fiddler to recompute the client signature. This works only if Fiddler has access to the client's private key. The ".cer" file is not sufficient; the private key is needed. The documentation is a bit unclear; my guess is that Fiddler uses the ".cer" file to know what client certificate to use, then will look for that certificate and private key within the local user's certificate store (which would be why Fiddler's documentation says that you should first import the certificate "as a .pfx file", i.e. with its corresponding private key, and then just export the ".cer" file). In any case, without access to the client private key, Fiddler will not be able to masquerade as the true client when talking to the server.

Now Fiddler could also have a limitation with regards to EC certificates; that I don't know. From what I explain above, Fiddler must run as a TLS client when talking to the genuine server, so if there is a client EC certificate, then Fiddler's code must support it, meaning that Fiddler must be able to generate an ECDSA signature.

From the documentation we see that the private key remains within the entrails of the client machine (a Windows system). Thus, any signature generation will need to go through the cryptographic API offered by Windows. Windows has two completely distinct API: CryptoAPI and CNG. CryptoAPI is the old one; CNG was introduced with Windows Vista and 2008. From the point of view of an application (e.g. Fiddler), a private key stored and managed with CNG can be used only with specific function calls; an application that knows only CryptoAPI cannot use a CNG-stored private key.

Unfortunately, CryptoAPI has no support for elliptic curve. An EC-based key can be used only through CNG. Moreover, Fiddler is said to be written in .NET, and .NET's cryptographic API relies on CryptoAPI only (you can use CNG but you have to do it with explicit invocations of the native DLL ncrypt.dll and bcrypt.dll). Therefore, I find it quite plausible that Fiddler uses only CryptoAPI and, thus, may support only RSA and DSA keys for client certificates, not EC keys.

  • In the scenario described, the user SHOULD still be seeing (at a minimum) a CONNECT tunnel through Fiddler; the fact that it's not shown suggests a configuration error. You are correct to note that Fiddler uses the CER file to select the certificate from the Windows Personal Certificate store, and requires that the Windows Personal Certificate store have the private key. You are further correct that Fiddler is performing a HTTPS handshake with the server itself using the .NET Framework's APIs (SChannel).
    – EricLaw
    Commented Nov 17, 2014 at 21:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .