Fiddler certificate with extendedkeyusage

[Chris]

hi

It seems that Fiddler generates on-the-fly certificates (when intercepting HTTPS traffic) but only sets the 'serverAuth' value for the ExtendedKeyUse attribute.

I am having some troubles getting the cert to be accepted by a Java App that is connecting to a backend system and I am using Fiddler to debug the HTPPS traffic.  My java app complains :

2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###http-bio-8083-exec-5, handling exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: Extended key usage does not permit use for TLS client authentication |

If I look at SSL debug generated in my app I see this:

2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###*** Certificate chain |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###chain [0] = [ |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###[ |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  Version: V3 |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  Subject: CN=<target server>, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11 |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  Key:  Sun RSA public key, 1024 bits |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  modulus: ...
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  public exponent: 65537 |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  Validity: [From: Wed Feb 26 00:00:00 UTC 2014, |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###               To: Tue Feb 25 23:59:59 UTC 2025] |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  Issuer: CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  SerialNumber: [   -6c9fcd89 21ec5b61 b6673282 907882a4] |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###Certificate Extensions: 3 |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###[1]: ObjectId: 2.5.29.1 Criticality=false |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###Extension unknown: DER encoded OCTET string = |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###0000: 04 81 B8 30 81 B5 80 10   39 6D 9F 06 75 DA BB F7  ...0....9m..u... |
...
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5### |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###[2]: ObjectId: 2.5.29.19 Criticality=true |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###BasicConstraints:[ |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  CA:false |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  PathLen: undefined |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###] |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###[3]: ObjectId: 2.5.29.37 Criticality=false |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###ExtendedKeyUsages [ |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  serverAuth |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###] |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###] |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  Algorithm: [SHA256withRSA] |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###  Signature: |
...
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5### |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###] |
2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###*** |

Then the app complains:

2015 03 03 11:50:07#+00#INFO#System.out##anonymous#http-bio-8083-exec-5###http-bio-8083-exec-5, handling exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: Extended key usage does not permit use for TLS client authentication |


Is it possible to get the ClientAuth extended use attribute set also?

-chris

[Eric Lawrence]

Hello, Chris--

While it would be easy* to change Fiddler such that its generated Server certificates include the ClientAuthentication EKU, it doesn't really make much sense to do so. A client which expects the SERVER to have the ClientAuthentication EKU set in the certificate is supplies is buggy.

Having said that, I want to make sure that you're not mistakenly trying to use one of the Fiddler-generated certificates as a client certificate (e.g. by exporting it to ClientCertificate.cer)?

Eric Lawrence
Telerik

(*) In the upcoming v1.4.9.7+ versions of the Fiddler CertMaker add-on, you can set the fiddler.certmaker.bc.AddClientAuthEKU preference to true to add this EKU.

 

[Chris]

hi

Thanks for the response.  Looks like my problem was that the Java app I was running needed the actual on-the-fly generated cert in its JKS keystone to set up the HTTPs channel to Fiddler properly.  I assumed I could just import the Fiddler root cert - but I needed to take the cert Fiddler generated for the backend and insert that as well (or instead of) the root cert from Fiddler.  The error I saw (about the extended key usage) seemed to have been a red herring and was not the real reason for the underlying problem.  So I went into the windows cert store on the machine running Fiddler, found the cert that Fiddler created for the backend, exported it and imported it into the JKS used by my app and hey presto! I no longer had problems with setting up the HTTPs channel.  I was surprised I needed to do this, as I assumed the on-the-fly created cert for the backend was signed in such a way that importing the fiddler root cert would have given my app a full certificate chain to validate the cert with, but it seems not.  Is that expected?  It's not what I understood from the Fiddler docs, but I could have misunderstood.

- chris 

[Eric Lawrence]

Hi, Chris--

Importing the Fiddler root certificate into the Java Keystore should have been sufficient for Java to trust the end-entity certificates that were signed by that root.

It's possible that some parts of Java have a limitation whereby it cannot find the chain to the root without additional information (e.g. a AKID) in the end-entity certificate. Fiddler's Certificate Maker add-on  (https://fiddler2.com/r/?fiddlercertmaker) includes an AKID when generating server certs but the default certificate generator does not (because makecert.exe does not offer that feature).

Regards,
Eric Lawrence
Telerik

 

 

[Chris]

hi

I tried this and unfortunately for me it still didn't work.  I can see in the debug output of my app that the AKID field is now set in the generated certificate, and it specifies a key identifier that matches exactly the root fiddler certificate I installed in the JKS (I had to reinstall fiddler's root cert after changing fiddler's certificate generator).  So I can't work out why it doesn't work.  There must be something wrong with the way the java app validates the cert chain in my case, but I am not sure what that problem is.  I am not sure I have much time to investigate this further, so for now the previous workaround (installing the cert generated by fiddler for the backend I was connecting to) works for me - it's a bit clunky, but I can use fiddler for what I need like this.  If I get some time over the next week I will debug the PKIX logic that the java app is using to validate the cert chain, and see if there is something wrong there.

Thanks for your very fast responses - it's great to get help like this so fast.  If you have any other suggestions, please let me know

- chris