A small number of HTTPS client applications support a feature known as “Certificate Pinning” whereby the client application is hardcoded to accept only one specific certificate. Even if the connection uses a certificate that chains to a root that is otherwise fully-trusted by the operating system, such applications will refuse to accept an unexpected certificate.
To date, some Twitter and Dropbox apps include this feature, and Windows 8 Metro apps may opt-in to requiring specific certificates rather than relying upon the system’s Trusted Root store. Firefox’s automatic browser update feature will silently fail when Fiddler is decrypting its traffic. The Microsoft Security toolkit named EMET can enable pinning in any application for certain “high-value” sites (including Windows Live). The Chrome browser supports pinning, but it exempts locally-trusted roots like Fiddler’s.
When a Certificate-Pinned application performs a HTTPS handshake through a CONNECT tunnel to Fiddler, it will examine the response’s certificate and refuse to send any further requests when it discovers the Fiddler-generated certificate.
Unfortunately, there is no general-purpose workaround to resolve this; the best you can do is to exempt that application’s traffic from decryption using the HTTPS tab or by setting the x-no-decrypt Session flag on the CONNECT tunnel. The flag will prevent Fiddler from decrypting the traffic in the tunnel and it will flow through Fiddler uninterrupted.
In some cases, you can jailbreak the device (Android or iOS) and remove the certificate pinning checks.
In the unlikely event that you have the server's actual private keys, you can simply have Fiddler use the "real" server certificate and its private keys.
CertMaker.StoreCert("www.yourhostname.com", "C:\\whatever\yourhostname.pfx", "yourpfxpassword");
After you make this call, the Certificate Maker will cache this single certificate and use it for any connections for www.yourhostname.com.