Authenticode, HTTPS, and Weak RSA Keys
Over on the Microsoft PKI blog, there’s some important information about upcoming changes for website operators who use HTTPS or deploy Authenticode-signed applications or ActiveX controls.
Weak RSA Keys Blocked
To briefly summarize the PKI team’s post, a security update coming to Windows 2008, Win7, Windows Vista, Windows 2003, and Windows XP in August 2012 will treat as invalid signatures that use RSA keys that are weaker than 1024 bits. That means that a HTTPS site that uses a cert with a weaker signature in its chain, or an ActiveX control signed by such a certificate will be blocked as having an invalid signature.
Within IE, this blockage will be visible via a notice that a executable or ActiveX control "was reported as unsafe”:
WinVerifyTrust will report a signature error for such files, because weak RSA keys do not provide a meaningful degree of protection. Regular readers will recall a similar issue when Windows began rejecting MD2 & MD4 signatures. An exception is made for ActiveX controls or Authenticode signed downloads that have a cryptographically-validated timestamp showing that they were signed prior to Jan 1, 2010.
For HTTPS sites, the blocking experience is different. When navigating to a HTTPS page that relies upon a weak RSA key for security, navigation will be interrupted by the “Problem with security certificate” error page:
In this situation, the “continue to this website” link will be non-functional; you cannot use the browser UI to override this blockage.
Update: This user-experience was improved in IE10.
Prior to IE10, you can distinguish the source of this error from other HTTPS errors by the lack of a specific “error text” message appearing at the normal location; e.g. in the HTTPS Subject CN Mismatch error, you see the following explanatory text:
Faster Certificate Revocation
The PKI team also announced a new improvement for helping address certificate revocation latency, which you can read about here. The highlight is that the new feature provides dynamic updates for revocation information so that Windows clients can be updated with untrusted certificates at most within a day of the information being published (no user interaction required); this updated information helps serve as a backstop for Windows’ existing certificate revocation checking support.