This is blatantly ridiculous. Had severe issues with intermittent non functioning https (started with https://www.google.com searches) in Chrome and in IE11, came and went, tore my hair out for weeks until I found this article from Jonas Lieb:
Excerpts: “The symptoms where a little bit unclear: When I would start the browser, I was able to reach secure sites (with the https:// prefix, port 443) for about 30 seconds. Afterwards, it would always get stuck in the “Establishing secure connection” stage for new connections, until ERR_CONNECTION_TIMED_OUT. The connections that were established in these first moments seemed to work for the rest of the session and usual http traffic (TCP port 80) was not affected”
From Dragon documentation: (CertSentry, SSL Certificates, Internet Security | Web Browser)
“Once installed, CertSentry will become the default SSL certificate revocation provider for Windows. The host application loads censentry.dll into its process space whenever the host application requests a certificate revocation check. Host applications include browsers such as Dragon, Chrome and Internet Explorer and mail applications such as Microsoft Outlook.
CertSentry will re-enable Online Certificate Status Protocol (OCSP) checking within Google’s Chrome browser. OCSP checking was recently disabled by Google.”
Who does Comodo think they are, taking over the SSL revocation operations for the Windows OS for everything else outside of Dragon without even so much as giving a warning in the documentation? What and who gives them this authority? They should just stick to protecting Dragon.
Even worse, uninstalling Dragon per Programs and Features in Windows (mine was Win 7 64 bit) doesn’t even remove this “TAKE OVER” of windows SSL security.
CertSentry.dll is wrapped in some servicehost and other processes, and lord knows if they remain running after I managed to delete certsentry.dll and issuers.sst and subjects.sst.
Furthermore, from Jonas’ article: “When Google Chrome is started, the user can immediately start browsing while the certificate stores are loaded. This leads to a race condition. Once all files have finished loading, new SSL connections also fail after completing the handshake. There are a couple things that Chrome and COMODO could learn from these situations: First of all, the asynchronous loading of security files could also be very dangerous since the user does not seem to be protected by the COMODO mechanism in the first seconds. Secondly, there should be a reasonable error message informing the user of SSL errors instead of a time out exception.”
This is just so outrageous, and I am angry to the nth degree after trying to find the cause of this issue for weeks and spending untold hours on it.