Cannot intercept HTTPS connections

[Markus Halm]

Hi there,

I've been trying to get the HTTPS interception working but with no luck so far.

What's not working?

Everytime I go to a SSL-secured website, I get no connection established within IE and in the Logs I can read this:

12:09:07:1394 !SecureClientPipeDirect failed: Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt on pipe to (CN=www.dropbox.com, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com)

(Which translates: "The credentials supplied to the package were not recognize on pipe to ...")

What have I tried so far?

From what I could find on the interwebs about this very problem, I already did a few steps that helped others to circumvent this problem:

• Download CertMaker plugin
• Installed and trusted Fiddler's root CA, of course
  
• Set fiddler.certmaker.bc.debug = True
  
• Set fiddler.certmaker.bc.keyprovidertype = 24
• Set fiddler.certmaker.root.extraparams = -sy 24 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider"
  (Though I think, this param isn't used by the CertMaker plugin)

Unfortunately this didn't lead to the solution desired.

What's in the logs?

<---snip--->

12:09:07:0300 Fiddler.BCCertMaker> Asked to MakeNewCert(www.dropbox.com) from thread 18...
12:09:07:0456 Proceeding to generate (www.dropbox.com) on thread 18.
12:09:07:0612 Fiddler.BCCertMaker> CreatingCert for: www.dropbox.com
12:09:07:0612 Fiddler.BCCertMaker> PrivateKey Generation took: 0ms.
12:09:07:0769 Fiddler.BCCertMaker> EECert Generation took: 8ms in total.
12:09:07:0925 Fiddler.BCCertMaker> Converting BCKey to DotNetKey using CSP Provider type: 24
12:09:07:1237 ContainerInfo for www.dropbox.com's Certificate's PrivateKey
    KCName:FiddlerBCKey
    Exportable:True
    IsMachine:False
    Protected:False
    Removable:False
    Provider:Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype) (24)
    UniqueName:6126ce6d65fe3c035ce2d7d51f5a45f2_fc2c3110-a2bd-413f-acf4-c84f3643232f
    RandomlyGenerated:False
 
12:09:07:1237 Fiddler.BCCertMaker> BC-to-.NET Conversion took: 81ms.
12:09:07:1237 Fiddler.BCCertMaker> Caching EECert for www.dropbox.com
12:09:07:1237 /Signaling [www.dropbox.com] is ready, created by thread 18.
12:09:07:1394 !SecureClientPipeDirect failed: Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt on pipe to (CN=www.dropbox.com, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com)
12:09:07:4050 !SecureClientPipeDirect failed: Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt on pipe to (CN=www.dropbox.com, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com)
12:09:07:6706 !SecureClientPipeDirect failed: Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt on pipe to (CN=www.dropbox.com, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com)

<---snap--->

System specs:

• Windows XP SP3
• Fiddler v4.4.5.9
• Running ELEVATED
• Gateway: Auto-Config, configscript pointing to our company's pac-file
• IE 8.0.6001.18702
  

Do you have any ideas what else I could try to make it work? Or is there any further information I may provide?

Regards, Markus

[EricLaw]

Hi, Markus-- Thanks for sharing your debug information!

You're correct that the extraparams value isn't used by CertMaker, only by the built-in provider.

Windows XP requires that keyprovidertype is 1. Is there some reason you set this to 24?

Removing the preference will tell the plugin to use the default. If you issue the QuickExec command prefs remove fiddler.certmaker.bc.keyprovidertype and then "Remove Interception Certificates" (Tools > Fiddler Options > HTTPS) and then restart and re-enable HTTPS decryption, does the same problem arise?

If so...

Do you see the problem if you DON'T run elevated?

Do you have the same problem if you're not using the CertMaker plugin and are using only the built-in provider?

To confirm, you're seeing this on sites other than dropbox and you're using IE, right? (I ask because the DropBox client uses "Certificate Pinning" and blocks even trusted root certificates if they don't match the client's "pinned" certificate).

[Markus Halm]

Hi Eric,

thanks for your quick reply.

First things first: indeed, I'm only using IE and am trying other sites as well (e.g. gmx.net). Actually Dropbox isn't my desired target rather it's some internal application of ours. I was just testing it out with different sites to check wether it's working with them – which ... it isn't. ;)

The reason for using keyprovidertype = 1 is, that on our company's computers there's this Entrust Security Provider stuff installed. And from what I've read in this thread setting the provider to 24 manually has fixed it for conrad. That has been the reasoning behind my settings.

So now going through your "todo"-list.

1. Unsetting the keyprovidertype setting led to no success: Logs using CertMaker and KeyProvider 1
2. Using built-in key provider: Logs using built-in provider and -sy 24
   (Note, that I only have removed the "-sp ..."-part as it was causing troubles and judging from MS' documentation of MakeCert it shouldn't be required.)
   
3. As before, but with fiddler.certmaker.root.extraparams removed: Logs using built-in provider
   
   
4. And now all again, this time NOT elevated ... Each try (Built-In, Built-In & kp=24, MakeCert, MakeCert & kp=24) gave me the same results as before.

Is there any other thing I could try? Or possibly some more debugging stuff that can be found anywhere to get further insight into why it's not working as expected?

I'm very thankful for you looking at my problem. Very much appreciated! :)

[EricLaw]

Thanks for sharing these logs. Entrust definitely seems like a factor here: my notes suggest that XP only works with KeyProviderType=1, but since Entrust is taking that type over, you end up with the problem where the certificate's private key is inaccessible.

Unfortunately, without Entrust, I can't try debugging this myself. :-(

Maybe try prefs set fiddler.certmaker.bc.useMachineKeyStore True and then run Elevated?

Maybe try using KeyProviderType 12 and see whether that has an impact?

[Markus Halm]

Thank you so much!! It finally works!

Though, I'm not sure the useMachineKeyStore-Setting did work. When removing the certificate again, it says:

08:44:16:0103 Fiddler.BCCertMaker> FindCertsByIssuer found 1 certificates in CurrentUser.Root matching 'CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com'.
08:44:16:0572 Fiddler.BCCertMaker> FindCertsByIssuer found 0 certificates in LocalMachine.Root matching 'CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com'.

But anyway: using KeyProviderType 12, it now DOES work like charm. You're the very best!

Thank you, again, for your great support and the time you took investigating this issue. :)

Regards, Markus

[EricLaw]

Cool, thanks for letting me know about the KeyProviderType tweak; this may help future users of Entrust products.

The UseMachineKeyStore setting controls where the private key is stored; it doesn't actually control where the certificate referencing that key is stored.