I thought maybe I was imagining this, but I can consistently reproduce it. Problem started with Fiddler Classic, and I then tried Fiddler Everywhere only to see the same behavior:
My dev/debugging environment consists of MS Visual Studio, Postman, and Fiddler running on Windows 10. I always have MS Outlook, MS Teams, and SSMS running as well. I run both Visual Studio, Postman, and Fiddler as Administrator, though I've tried running them in normal mode as part of debugging this problem. It makes no difference.
Any time I start Fiddler, within approximately 15 minutes, Teams is the first app to go down... it suddenly reports "no internet connection" and I can't send or receive messages.
Shortly thereafter, Outlook will start throwing up "invalid security certificate" dialogues. Email send/receive is no longer possible after this point... The Outlook Icon in my taskbar shows a yellow triangle with a black exclamation mark.
Next to go is the ability to make https connections through, for example, Chrome or Edge. I see errors such as the attached.
Has anyone else experienced this behavior? I've tested extensively making sure just the apps I've mentioned earlier were running. I can run for 24, 48, or more hours without the problem occurring. But if I fire up Fiddler (either Classic or Everywhere), 100% of the time, the networking issues occur. Always.
Any thoughts on what might be going on here? My assumption is that Fiddler is trying to be a proxy for everything on my machine, and it just can't do it for <reasons>. If I remember correctly I can manually tell Fiddler NOT to proxy for certain apps, but this seems tedious. I'm especially worried to suddenly see https disabled for Chrome or Edge, as the Visual Studio applications I'm debugging are APIs that use https...
1 Answer, 1 is accepted
Hello Mark,
All Office365 applications, including MS Teams and Outlook, are known to have compatibility issues with system proxies, especially those that dynamically change the operating system proxy settings. That said, the recommended approach is to bypass the Office365 applications so that their traffic does not go through the Fiddler proxy.
Several approaches can be applied to bypass the Fiddler proxy:
1. You can explicitly bypass a set of endpoints used from the Office365 applications (or any other applications) through the Settings > Connections > Bypass FIddler for URLs that start with the.. option. Details on that approach can be found in the linked articles below:
https://docs.telerik.com/fiddler-everywhere/knowledge-base/setup-fiddler-alongside-office365
https://docs.telerik.com/fiddler-everywhere/knowledge-base/how-to-bypass-the-proxy
The bypass option is recommended when Fiddler is used as a system proxy (system capturing mode).
2. You can turn off the system capturing mode and use one of the alternative capturing modes like browser capturing (will capture traffic only from a specific browse instance), terminal capturing mode (captures traffic from dedicated terminal instance), or even Fiddler as an explicit proxy. This will allow your Office365 to use the default upstream without having to use the Fiddler proxy, and at the same time, you will be able to capture traffic from the preferred application through sandboxed proxy settings (without polluting the Live Traffic grid with traffic from multiple different applications).
Learn more about the supported capturing modes in Fiddler Everywhere here...
All of the above said, you should not randomly get the ERR_CERT_AUTHORITY_INVALID message in your browsers after prolonged usage of Fiddler. You can try to entirely reset the Fiddler certificates. If the issue appears with specific pages, try to clear the browser's cache before starting the Fiddler proxy (to ensure that there is no pinned version of the certificate. Additionally, consult your network administrators if there is a specific administrative policy or security tool that might be removing or limiting the Fiddler proxy (or its certificate authorities) in any way.
Regards,
Nick Iliev
Progress Telerik
Rank 1
Thanks for the very detailed response Nick. I think the answer is going to be the bypass option you mentioned for my office applications. This will at least let me stay in touch with my team while I'm debugging using Fiddler. Losing Teams and then Outlook consistently after firing up Fiddler takes me out of the game. So bypass is a good workaround.
Trying to go the other route and "opt in" Fiddler as a proxy would be problematic in our environment as we have a very large number of APIs with distinct URLs & ports, multiplied by all of those APIs running in four or five distinct environments (dev, test, rc, etc.)
I'm still unsure what to do about the web browser problem as https is being completely disabled for Chrome and/or Edge. I did try the remedies you mentioned, such as resetting the certs, clearing cache, etc. No joy :-(
I'll keep plugging away at it. Thanks for the response!
A quick note about the bypass option. I wanted to let you know that you can add endpoints to the bypass list on the fly through the actively captured traffic while using the bypass options in the context menu(an example in the attached screenshot).
Regarding the randomly appearing ERR_CERT_AUTHORITY_INVALID issue - if you are using the system capturing mode, then you can check if the Fiddler CA (certificate authority) is present in the Windows certificate manager (before and after the issue appears). As the issue appears randomly after a prolonged use of Fiddler it sounds like something might be removing the certificate from your cert store.
You can observe that directly in the cert manager or through:
1. Open Google Chrome settings.
2. Go to "Security" to navigate to "Manage Certificates".
3. Confirm that the Fiddler CA is in the "Trusted Authorities" tab.
As a side note, you can still try the independent browser capturing mode if the issue appears while using a browser. This mode is available only in Fiddler Everywhere and explicitly starts separate browser instance that uses the Fiddler proxy and its CA (without modifying the system CA manager)