Rank 1
Iron
Hi,
I have been using HTTPS decryption in Windows Fiddler for years, to inspect the traffic to and from my app.
And it has been working perfectly on both my Samsung phone with Android 12 and my iPhone 6 Plus with iOS 12.5.5.
Recently I got an iPhone 11 with iOS 15.1, and find myself completely unable to get it to work 😢
Because I know, that requirements for certificates have been strengthened in recent versions of iOS, I have now ended up "resetting" the certificate in Fiddler and creating a new root certificate. I have successfully removed the old certificates and installed the new Fiddler certificate on both the Samsung and the iPhone 6 Plus, following the Capture Traffic from iOS Device guide, and everything works like a charm.
On the iPhone 11, I have also installed the certificate:
And I have enabled full trust for it:
And yet, if I try to visit e.g. https://google.com/ in Safari, I get an error message telling me that "This Connection Is Not Private":
And if I click "view the certificate", it shows that the google.com certificate, issued under the Fiddler root, is "Not Trusted" - with no indication as to why???
3 Answers, 1 is accepted
Hello Nicholas,
The error message indicates that the certificate is not trusted. One possibility is that you have multiple Fiddler certificates with the same name - that can easily happen when you download and install the Fiddler certificate from different Fiddler versions. The best approach would be to go into the iOS settings (Settings > General > Profiles) and explicitly delete all profiles named DO_NOT_TRUST_FiddlerRoot. Then download (Safari > http://ipv4.fiddler:8888), install, and enable full trust for the Fiddler certificate (Settings > General > About > Certificate Trust Settings) anew. Finally, make sure to restart the mobile Safari (close the app entirely and make sure it is not minimized).
The above steps can be found in the linked documentation article below. Note that the article is written for the new Fiddler Everywhere but the concept is pretty much the same - the only crucial difference is that Fiddler Classic uses port 8888, and Fiddler Everywhere uses port 8866.
https://docs.telerik.com/fiddler-everywhere/traffic/configure-ios#configure-the-ios-device
Regards,
Nick Iliev
Progress Telerik
Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.
Rank 1
Iron
Hi Nick,
Thanks for getting back.
Yes, the error message does indicate that the certificate is not trusted. But it just doesn't seem to make any sense. As you can see in the screenshots in my original post, the certificate is both installed ("Verified ✓") and has full trust enabled - and as you can see in this next screenshot, I had already deleted any old Fiddler certificates, so that this is the only Fiddler certificate installed:
And yes, I have also killed Safari completely before trying again - even rebooted the phone a couple of times for good measure...
Strangely, for some sites Safari instead gives this warning, stating that the connection is not trusted because the website is using deprecated TLS 1.0 or TLS 1.1. I have never before experienced this type of error in connection with Fiddler's HTTPS decryption, so I don't know if it could give you any new clues as to what might be going wrong?
Just to triple-check I again deleted the one & only FiddlerRoot certificate/profile from the Settings, re-downloaded it from http://ipv4.fiddler:8888/, installed it, and enabled Full Trust - and it still doesn't work. Basically same as before, although strangely https://www.google.com/ now also gives the "insecure connection due to TLS 1.0 or TLS 1.1" error as shown above - but I'm not sure there is any deeper meaning to this 🙂
I'm really at my wits end, and wondering if there could be some problem with the FiddlerRoot certificate generated by Fiddler, which would make a stricter iOS 15.1 not trust it...? If that was a general problem though, I guess a lot more people would run into it - and I don't see how it could lead to the strange "TLS 1.0 or TLS 1.1" error that Safari now shows for most sites...
It seems Apple has added more and more requirements, re. what is required for a certificate to be considered "secure".
E.g. https://support.apple.com/en-us/HT211025 also adds a requirement that new certificates must not have a validity period greater than 398 days - but this is not supposed to affect "certificates issued from user-added or administrator-added Root CAs", like FiddlerRoot.
Likewise https://support.apple.com/en-us/HT210176, and likely others, seem to add a slew of other requirements...
Other people seem to run into similar problems: https://developer.apple.com/forums/thread/655074?answerId=667415022#667415022. But without iOS helping by telling why it considers a particular certificate invalid, it all seems like a big guessing game for people (like me) trying to figure out why their certificates are considered invalid/insecure...
When Safari was complaining about the certificate being invalid, I clicked "view the certificate" and captured the below screenshot of Safari's view of the certificate - I dont know if that could give any clues as to why Safari might think that it is invalid (because Safari sure doesn't tell what it thinks is wrong with it...):
Rank 1
im having the exact same issue. ios 15.1.1
installed root certificate and enabled it in trust settings...and i cannot capture any traffic. all says connection not private.
I've tested the whole scenario with a freshly updated iPhone to the latest 15.2 and I was able to successfully capture HTTPS traffic. During my test, I've noticed the same error in Safari ("... insecure connection due to TLS 1.0 or TLS 1.1" ) was present if the certificate was not fully trusted. Note that you are receiving a different error ("... insecure connection due to TLS 1.0 or TLS 1.1" ) compared to the initial report (...safari warns you when a website has a certificate that is not valid) which indicates a different issue.
Can you double-check the full trust in Settings > General > About > Certificate Trust Settings?
Another thing that strikes me as different is that my version of Trust Asset Version (again in Certificate Trust Settings) was version 15 while on your screenshot it is shown as 14. Perhaps you could check if there are available updates for your OS?
Rank 1
Rank 1
Rank 1
Iron
Hmm, it looks like some users of Charles proxy might be experiencing a similar issue:
https://stackoverflow.com/questions/69906780/charles-proxy-network-trace-on-ios-15-1-device-iphone
FYI. I have now also created a thread in Apple's Developer Forum, in the help that they might be able to spot why the leaf certificate generated by Fiddler is considered invalid: https://developer.apple.com/forums/thread/696721
Hey Nicholas,
Indeed, I can confirm that the issue is in the certificate generated by Fiddler Classic. By default, this certificate is generated from a tool called CertEnroll (more about certificate generation here: https://www.telerik.com/blogs/understanding-fiddler-certificate-generators ). However, this tool is not generating a valid certificate for the latest iOS versions. As per the documented instructions, you need to use the Bouncy Castle certificate generator which will produce valid certificates that are compatible with iOS.
You can resolve the issue by manually installing the Bouncy Castle extension and generating a new root certificate. Follow these steps to apply the solution:
- Close Fiddler Classic.
- Go to https://www.telerik.com/fiddler/add-ons and download the CertMaker for iOS and Android extension (this is the Bouncy Castle generator).
- Install the downloaded executable.
- Start Fiddler Classic and go to Tools > Options > HTTPS and verify that the Certificates generated by is now showing BCCertMaker
- In Tools > Options > HTTPS use the Actions drow-down and execute Reset All Certificates action.
- Once the new certificate is generated and installed, go to your iPhone and connect to the Fiddler Echo service ( HTTP://ipv4.fiddler:8888 ).
- Download, install and enable full trust for the newly generated certificate in the iOS settings.
- Restart your Safari browser (and in some rare cases, restart the Fiddler Classic process) and you should be able to capture HTTPS traffic from the iOS device.
Regards,
Nick Iliev
Progress Telerik
Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.
Rank 1
ok i have done this and we are definitely getting somewhere.
Websites are loading but taking AGES. a simple google.com is barley loading and 2 min in the loading bar has only halfway loaded but i can see the google search bar and image.
This is definitely better then what was happening before but still its not useable in this slow stage.
Any idea what might be wrong?
Thanks
Glad to hear that you are able to capture HTTPS traffic once again!
The issue with the slowly loading pages doesn't sound related to the certificate issue. Can you try the solution suggested in this forum thread (turning on/off IPv6 option in Tools > General and restarting Fiddler)?
Rank 1
Iron
Hi Nick,
Sorry for taking so long to get back...
I had not noticed that you, in the beginning of 2021, changed the instructions for iOS to specify that you now have to use Bouncy Castle certificate generator instead of the default one.
I followed the (new) instructions, downloaded & installed the Bouncy Castle extension, reset the certificates in Fiddler, deleted the old Fiddler root certificate on the device(s) and installed the newly generated Fiddler root certificate on the device(s) - and everything now works as a charm on all three of my test devices 🥳
It sounds like a good idea to release a new version of Fiddler Classic with a default certificate generator which produces valid certificates that are actually compatible with iOS - but I can see that you removed that line from you your original answer...?
The team is currently planning on releasing a new version of Fiddler Classic, where the default generator will be changed to Bouncy Castle.
Anyway, thanks for your help, at least it now works for me 😀
We are glad you were able to have the capturing fully working.
Regarding the Bouncy Castle as default generator - this is something we are considering and evaluating, so thank you for your input on the topic.
Happy debuging!