Freigeben über

Troubleshooting Internet Explorer and the CRL mystery

  • Artikel

This was an interesting case, and didn't see much on this when I searched around the public internet, so want to leave a little something in case it helped someone else.

The Problem Statement

  • Users on Windows 7 and Internet Explorer 11 or Microsoft Edge on Windows 10 were experiencing no issues going to a public http site (example being https://www.wsj.com or https://www.msn.com).
  • Users on Windows 10 and Internet Explorer 11 were experiencing issues on these same sites. A message popped up “Revocation Information for the security certificate for the site is not available” when viewing ads on the page

This was the error that was being presented to the user:

So, some notes from the troubleshooting:

  • I made an assumption that maybe there were some code differences between Internet Explorer 11 for Windows 7 and Internet Explorer 11 for Windows 10, and that was incorrect. All the CRL checking process is doing in Internet Explorer is calling to the operating system and waiting for a "pass/fail" response.
  • There was a "Man in the Middle" device known as an A10, which was passing certificates properly.
  • Inspecting the certificate chain, the chain was valid, and the same chain was being passed in Windows 7 Internet Explorer and Windows 10 Internet Explorer and Microsoft Edge.
  • Microsoft Edge has a very different model, being a Universal Windows Platform (UWP) app. This app is containerized, and doesn't use the same plug in model that Internet Explorer does.
  • A network trace revealed the following:
    • When Windows 7 (Internet Explorer 11) and Microsoft Edge were passing traffic, they were passing requests in TLS 1.2. Further investigation revealed that TLS 1.0, 1.1, and 1.2 are allowed by policy on both Win7 and Win10 via Group Policy (GPO).
    • When Windows 10 Internet Explorer 11 was passing traffic, TLS 1.0 was being negotiated (exposed by network trace), which led me to think there was a plug-in for Internet Explorer involved. After disabling all plug-ins for IE, the problem persisted, leading me to think a piece of installed software was interfacing with or filtering Internet Explorer traffic. When monitoring the same process, I noticed a lot of activity revolving around FireEye and Entrust (both security software products) around the Internet Explorer process.
  • The next step was to disable all plug-ins. This did not succeed.
  • At this point, it was easier to rebuild a new image, but leave off any additional software, just load Windows 10 and Group Policy (we can always drop Group Policy later)
    • Note that this test passed, so it led credibility to a piece of installed software being the culprit.
    • Upon further investigation, it was determined that Entrust for Windows 10 was causing issues with the process and without this software, the errors do not persist.

So, the root cause: Updating the Entrust software fixed the issue.

To recap the "How to Troubleshoot Internet Explorer" piece...

  • Load Internet Explorer in "Safe Mode" (iexplore.exe -extoff)
  • If this doesn't solve it, attempt to remove GPOs by putting it in a "Safe OU". This isn't guaranteed to remove everything, but is better than flattening the system.
  • Speaking of flattening the system, instead of removing software one by one, which you can do (death by 1,000 cuts style), cut to the chase and rebuild a system from your image with no additional software installed but the operating system, drivers, and Microsoft patches.
    • But wait, we bake all of our software into the image. Sorry about that, but build an image without all the extra software, or use the Windows media standalone to build your test. Then, reapply your apps slowly and keep retesting.
  • If the system is broken after applying your image of Windows (your issue can be there), try a clean Windows media build.
  • If after all that still doesn't solve the problem, you may have to look external to the system. It could be a network device, security appliance, or even just bad scripting on the remote site (although you shouldn't trust any external website to do any local scripting on your systems).

I hope you found this blog useful to help troubleshoot Internet Explorer crashes as well as the CRL mystery itself.

— Easy link to my blog: https://aka.ms/leesteve —
If you like my blogs, please share it on social media and/or leave a comment.

Comments

  • Anonymous
    September 08, 2017
    Interesting. Thanks.