Last year’s high-profile attacks (apparently by state-level adversaries) on several commercial CAs made our industry painfully aware that certificate revocation checking, as currently implemented, is ineffective. We should expect further attacks and we need to raise our game to defend against them. According to PKI theory, revoking a mis-issued certificate should be enough to protect users, but in reality this isn’t currently the case. Most browsers “soft-fail” online CRL/OCSP checks, which means that an attacker can thoroughly defeat the protocols.
As you might expect, Comodo have been advocating that the browsers should begin to “hard-fail” revocation checks ASAP! But the browsers continue to resist such suggestions. They argue that online revocation checks can be slow and they fail too often, due to a varieties of reasons, not all of which are within the control of the CAs.
Rather disturbingly, Google have just gone one step further in the wrong direction (in our opinion): They have just announced their intention to make Chrome stop performing online revocation checks altogether. They want to replace realtime online checks with a proprietary mechanism that uses Chrome’s automatic update system to push partial lists of revoked certificates to each Chrome user. This would mean that 100% of Chrome users will have no protection against a (probably vast) number of revoked certificates!
We remain unconvinced that online checks are, or necessarily need to be, as bad as the browsers frequently claim. In our opinion, what we need now are cold, hard statistics that reveal just how slow online checks are and just how often they fail.
Enter CertSentry. 
We have grand plans for CertSentry (much more than tackling the problems with traditional revocation checking), but the main function of version 1 will be to gather extensive statistics on the health of the current revocation checking infrastructure. We are confident that these statistics will prove invaluable to our efforts to “fix” revocation checking!
Our plan is to roll out CertSentry first to all Dragon users and then to all CIS users. But right now, we need your help to beta-test it by installing Dragon Beta version 17.2.0.
Once installed, CertSentry is invoked whenever you run any application that uses the standard Microsoft CryptoAPI functions to perform revocation checks. Such applications include Dragon, Chrome (for now, at least!), Internet Explorer, Outlook, etc.
This CertSentry beta also has experimental support (disabled by default…for now) for “hard-failing” online revocation checks. If you would like to switch this feature on, simply add one of the following values to your Windows registry: (This needs to be a REG_DWORD)
To enable “hard-fail” only for certificates issued by Comodo’s CA system:
HKEY_LOCAL_MACHINE/SOFTWARE/COMODO/CertSentry/COMODOFailureMode (value “2”)
To enable “hard-fail” for all certificates from all CAs:
HKEY_LOCAL_MACHINE/SOFTWARE/COMODO/CertSentry/DefaultFailureMode (value “2”)
Feedback greatly desired. We believe the code is stable, but please let us know of any repeatable host application crashes that don’t occur with CertSentry not installed. Also, if you try out “hard-fail”, let us know how you fare.