Can't use Fiddler root CA after updating FF to v41
After I updated Firefox to version 41.0.2 on Windows 7, I can no longer use Fiddler4 to decrypt HTTPS traffic because the root certificate exported from Fiddler is no longer being recognized by Firefox. Firefox appears to be rejecting the "wildcard" domain name used in the certificates generated by Fiddler. It always gives the error "ssl_error_bad_cert_domain".
For example, going to https://login.comcast.com with Fiddler turned on:
login.comcast.com uses an invalid security certificate. The certificate is only valid for *.comcast.com (Error code: ssl_error_bad_cert_domain)
It is especially a problem for sites using HSTS (HTTP Strict Transport Security) such as google.com, because an exception cannot be added for these sites and it requires the root CA to be recognized.
www.google.com uses an invalid security certificate. The certificate is only valid for *.google.com (Error code: ssl_error_bad_cert_domain)
I have tried clearing all history and website permissions, deleting the cert8.db file, disabling/re-enabling the HTTPS decryption and regenerating the certificate in Fiddler, removing the Fiddler-generated root certificate from the certificate authorities list in Firefox and re-adding it, all to no avail. I could not find any documentation online for this issue, as the Telerik website indicates that adding the certificate to the root CAs in Firefox options should be enough.
What has changed in Firefox, and why would the browser fail to recognize these root certificates? Is there some new further security tightening that's been introduced?
Is anyone else able to update Firefox and use the normal method of adding the Fiddler root CA? Do you run into the same problem or does it work for you?
a012 tarafından tarihinde düzenlendi
Tüm Yanıtlar (9)
If you can't inspect the certificate via "I Understand the Risks" then try this:
Open the "Add Security Exception" window by pasting this chrome URL in the Firefox location/address bar and check the certificate:
- chrome://pippki/content/exceptionDialog.xul
In the location field of this window type or paste the URL of the website.
- retrieve the certificate via the "Get certificate" button
- click the "View..." button to inspect the certificate in the Certificate Viewer
You can inspect details like the issuer and the certificate chain in the Details tab of the Certificate Viewer. Check who is the issuer of the certificate. If necessary then you can attach a screenshot that shows the certificate viewer.
If you have reset Firefox and have created a new profile then try to recover the cert8.db file from the "Old Firefox Data" folder on the desktop.
Otherwise you would have to export the certificate in another browser that works and import the certificate in the Firefox Certificate Manager.
- Tools > Options > Advanced > Certificates: View Certificates
You need to set trust bit(s) when prompted to make this certificate work as a trusted root certificate.
Please see the four screenshots I attached with attempting to connect to https://www.google.com with Fiddler running. See how it says the certificate is only for *.google.com and it thinks it's for a different site?
I also tried to compare what happens when I remove the Fiddler root certificate from the CAs in Firefox options. When I do this, it's a completely different error: sec_error_unknown_issuer ("The certificate is not trusted because the issuer certificate is unknown.") So when I have the root certificate, Firefox is definitely recognizing it but saying that it's for a different site.
Was a bug introduced into Firefox that fails to pattern-match the website domain name using the wildcard (*) that the certificate provides when it should be doing so? Past versions never had this issue. I'm surprised that no one else reports this usage of Fiddler breaking with the Firefox update, so I'm not sure if there's a bug that's only affecting my browser somehow.
On a different system I had Firefox version 35.0.1 installed and the Fiddler4 HTTPS decryption was working fine with the root cert installed. I attempted an update to 41.0.2, and began having the exact same problem. I kept trying some previous versions, and found that apparently version 36.0 (the one right after 35.0.1) is the one that broke this functionality. If I downgrade back to version 35.0.1, everything works fine again.
It looks like version 36.0 was published in February 2015, so again I'm surprised that I'm not finding other reports of this issue happening since then.
You can try to rename (or delete) the permissions.sqlite file in the Firefox profile folder to remove stores 'sts' permissions.
You can use this button to go to the current Firefox profile folder:
- Help > Troubleshooting Information > Profile Directory: Show Folder (Linux: Open Directory; Mac: Show in Finder)
- http://kb.mozillazine.org/Profile_folder_-_Firefox
Tried deleting the permissions.sqlite file but unfortunately this doesn't solve the issue.
Also, I posted a question on the Telerik forum as well: http://www.telerik.com/forums/firefox-36-0-breaks-fiddler-https-decryption
a012 tarafından tarihinde düzenlendi
The problem here is that Firefox 36+ apparently dropped support for wildcards (*.example.com) in the SubjectCN parameter, requiring that wildcards only appear in the SubjectAltNames field of the certificate.
The default Fiddler Certificate Provider (makecert) cannot generate certificates with SubjectAltNames, leading to this problem (which isn't present in IE or Chrome, as they do not impose this restriction on certificates).
There are two simple workarounds for this; pick one:
Best Choice: Click Tools > Fiddler Options > HTTPS. Click "Certificates Generated By: Fiddler.DefaultCertificateProvider." In the box that appears, change the dropdown to "CertEnroll." CertEnroll generates more "modern" certificates containing SubjectAltNames and other features that improve performance. After you save this change, you will probably need to untick the "Decrypt HTTPS traffic" checkbox, click "Remove Interception Certificates" (accepting all prompts), then restart Fiddler and recheck the "Decrypt HTTPS traffic" checkbox (accepting all prompts). This will ensure you end up using the new certificate generator and none of the old cached certificates are used.
Ok Choice: Click Tools > Fiddler Options > HTTPS. Click "Certificates Generated By: Fiddler.DefaultCertificateProvider." In the box that appears, untick the Use Wildcards box. This will disable MakeCert's use of wildcards in certificates.
Thanks!! A couple of questions:
1) Should this be considered a Firefox bug? Firefox is changed to do something different than the other major browsers do. Do the standards have anything to say about this? Should wildcards be allowed in the SubjectCN parameter?
2) When choosing CertEnroll to make the certificate instead of makecert, and leaving the wildcard option on, it still seems to generate a wildcard domain (e.g. *.mozilla.org) in the Subject parameter, yet Firefox is accepting the certificate. Maybe I'm still missing what the difference is. Why is it being accepted from one certificate generator (CertEnroll) and not the other (makecert) when both of them use the wildcard domain in the main subject field?
I'm at least glad this was easy to work around, but still the Firefox implementation should be addressed if it was changed not to do the right thing.
1. It is arguably a bug in Firefox, but I spoke with a developer in this space and he indicated that they have no plans to fix it. In fairness, Chrome plans to start ignoring the SubjectCN entirely soon, and Firefox may follow suit.
2. The reason this works with CertEnroll is that CertEnroll (unlike makecert) adds a SubjectAltName containing the wildcard, and it also uses utf8string encoding rather than bmpstring for the SubjectCN. Firefox no longer handles wildcards in bmpstring-encoded fields.