By default, Fiddler intercepts insecure traffic (HTTP) but it can be configured to decrypt secure (HTTPS) traffic. In order to do so, the proxy executes a man-in-the-middle attack against the secure traffic; to achieve that, Fiddler must generate a root certificate and use that root certificate to generate multiple end-entity certificates, one for each HTTPS site which is being intercepted.
Extensibility Fiddler uses a pluggable architecture for certificate generation. Developers provide their own certificate-related logic by implementing the ICertificateProvider3 interface on an assembly specified by the fiddler.certmaker.assembly preference, which defaults to "certmaker.dll".
On Windows, Fiddler defaults to using Microsoft’s makecert.exe command line utility to generate the root and end-entity certificates. All generated certificates are stored in the Fiddler-running user’s Windows certificate storage area. (Certificates can be seen by launching the CertMgr.msc utility).
There are three downsides to the makecert.exe tool:
Issue #1 is that, because Fiddler generates one certificate for each HTTPS site you visit, your Windows Certificate store can be “polluted” with dozens or hundreds of Fiddler-generated end-entity certificates. This is generally harmless, but can cause performance problems if you’re using Cisco VPN Software or Roaming User Profiles in Windows. That’s because these features attempt to copy all of the Certificates in your Windows Certificate store on logon/logoff, and if you have tons of Fiddler-generated certificates, this can be a problem. One workaround for this problem is to set the fiddler.CertMaker.CleanupServerCertsOnExit preference, which cleans up all end-entity certificates each time Fiddler exits.
Issue #2 is that the certificates generated by makecert.exe lack important fields (specifically, the Authority KeyID field) that are required by iOS-based clients (as well as some Android clients). As a consequence, with the default certificate maker, iOS applications will always complain about invalid certificates if you use Fiddler to decrypt their traffic, even if you try to trust the Fiddler root certificate on the iOS device.
Lastly, issue #3 is that makecert.exe only runs on Windows, and thus is not available for Mac/Linux. Fiddler can run on those platforms via Mono and thus requires a different approach to certificate generation.
To address each of these shortcomings, the CertMaker add-on replaces the default certificate generator with a C#-implementation based on the BouncyCastle C# library. Certificates generated by this add-on are not stored inside the Windows certificate store and include the fields required for compatibility with iOS and Android. Additionally, the add-on works properly on the Mono Framework, and thus it is the default Certificate Generator for Fiddler on Mono.
You can determine which certificate generator is in use by looking at the Tools > Fiddler Options > HTTPS tab:
There are no real downsides to using the CertMaker add-on in lieu of the default makecert-based generator, aside from the add-on’s 210kb download size.
Fiddler’s HTTPS interception capabilities (rightly) raise eyebrows among security-conscious users.
Trusting the Root
By default, Fiddler does not reconfigure your system to trust the Fiddler root certificate, but it does provide the option to do so. Several prompts are shown when you first tick the Decrypt HTTPS traffic checkbox.
First, Fiddler itself asks whether you’d like to trust the root certificate it generates:
If you select No (the default) then nothing else happens, and your browsers and other software will typically complain about invalid certificates when interacting with HTTPS sites that Fiddler has intercepted. (If your software doesn’t complain about an invalid certificate, it has a security bug!)
If you select Yes, then Fiddler will instruct Windows to import the generated root certificate into the current user’s Trusted Root Certification Authorities store. The following prompt is then shown:
If you select Yes, then software running in the current user account should trust certificates generated by Fiddler. However, there are some exceptions to this: for instance, Windows 8 “Metro”/“AppStore” applications ignore the current user’s Trusted store but generally do respect certificates in the machine Trusted store. When running on Windows 8+ (or if the fiddler.CertMaker.OfferMachineTrust preference is set to True), Fiddler will next prompt you to trust the certificate on a machine-wide basis.
This operation requires Administrative permissions, so first you’ll see a prompt for elevation to Admin:
…and then the TrustCert.exe tool will prompt you to confirm the operation:
At the end of this flurry of prompts, virtually all applications on your PC will trust Fiddler-generated certificates. The two exceptions are AppStore/Metro applications which have a fixed certificate list (“pinning”) and Firefox. Firefox can be easily reconfigured to trust Fiddler’s root by following these steps.
What’s the Risk?
Many security folks are worried that, if a user configures Windows to trust Fiddler’s root certificate, that user could have their traffic intercepted and decrypted by any other Fiddler user. They assume that Fiddler is sharing the same root certificate across all installations.
Fear not! Every Fiddler root certificate is uniquely generated, per user, per machine. No two Fiddler installations have the same root certificate. The only way for a Fiddler user to be “spoofed” by a bad guy is if that bad guy already is running code inside the user’s account (which means you’d already be pwned anyway).
The fact that every Fiddler root certificate is unique can actually be problematic, if you’ve configured one machine (Machine A) to send traffic to a different machine (Machine B) which is decrypting traffic. If you’d ever configured Machine A to trust the Root Certificate generated by Fiddler on Machine A, when it encounters a Fiddler-generated certificate chaining to the root generated by Machine B, IE will show a “Page cannot be displayed” error rather than the normal “untrusted certificate” message. When Windows sees that Machine B’s certificate chains to a root certificate of the same name, but a different private key, than the locally-trusted root, it panics and kills the connection. (This scenario was sufficiently obscure that the IE team never built a specific error page for it).
Can I See the Keys?
In some cases, you might be interested in getting the private keys used by Fiddler’s certificates (say, because you’d like to provide the private key to Wireshark).
Grabbing the private key is not (easily) possible when using the default certificate generator, but it’s easy to do with the CertMaker plugin. Simply type about:config in Fiddler’s QuickExec box and filter the preference list to those preferences that contain the word certmaker:
The preference fiddler.certmaker.bc.cert caches the base64-encoded root certificate, while fiddler.certmaker.bc.key contains the associated private key. The fiddler.certmaker.bc.debug preference controls whether debug information is spewed to the Log tab when certificates are generated. The fiddler.certmaker.bc.logprivatekeys preference controls whether private keys are logged on the Log tab as they are generated. The fiddler.certmaker.bc.reuseprivatekeys preference controls whether the CertMaker plugin reuses a single private key for all end-entity certificates generated within a single Fiddler session.
Please let me know if you have any other questions about certificates in Fiddler!
Eric Lawrence (@ericlaw) has built websites and web client software since the mid-1990s. After over a decade of working on the web for Microsoft, Eric joined Telerik in October 2012 to enhance the Fiddler Web Debugger on a full-time basis. With his recent move to Austin, Texas, Eric has now lived in the American South, North, West, and East.