The improperly issued certificate could be used to spoof content, launch phishing attacks, or perform man-in-the-middle HTTPS interception against the live.fi and www.live.fi Web properties, Microsoft said in a security advisory Monday.
The company updated the Certificate Trust List (CTL) included in Windows in order to blacklist the fraudulent certificate. Systems running Windows 8, Windows 8.1, Windows RT, Windows RT 8.1, Windows Server 2012 and Windows Server 2012 R2 will receive the update automatically and transparently.
Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 systems will also be updated automatically, but only if they previously installed the KB2677070 or KB2813430 updates which added an automatic updater for revoked certificates.
Users of systems that don't have this updater installed, or customers running Windows Server 2003, should install the newly released KB2917500 update to revoke the rogue live.fi certificate.
The certificate was issued by Comodo after an unauthorized party was able to register an email account on the live.fi domain using a "privileged username" and then used the email account to request the certificate, according to Microsoft.
A Comodo support article notes that before a certificate is issued for a particular domain name, the person requesting the certificate must prove ownership or control of that domain. The "domain control validation" can be done in several ways, one of which is through an email sent to one of several generic admin type email addresses: admin@, administrator@, postmaster@, hostmaster@ or webmaster@.
It's not clear which of those usernames the unauthorized party managed to register on the live.fi domain. However, the incident should serve as a warning to all domain owners that such admin-type addresses should be strictly controlled.
Even if users apply the Microsoft update, it won't completely mitigate the risk associated with this certificate. That's because not all applications use the Windows Certificate Trust List to validate website certificates.
Browsers like Internet Explorer and Google Chrome do, but Mozilla Firefox for example has its own certificate root store and blacklist, which Mozilla updates independently.
The incident highlights yet again that once a SSL certificate is issued erroneously or fraudulently, the action cannot easily be undone. While the issuing certificate authority (CA) can flag the certificate as revoked, the process of checking for such revocations is broken for the most part.
There are two main ways to check if a certificate has been revoked: by checking certificate revocation lists (CRLs) published periodically by certificate authorities or by using the Online Certificate Status Protocol (OCSP), which allows checking a certificate's revocation status in real time by querying OCSP servers operated by CAs. There are problems with both approaches.
Browsers allow SSL connections to continue if CRL or OCSP checks fail with a network error because such checks can fail for a variety of reasons -- for example the CA servers are down or there's network congestion en route to them. This is known as a soft fail approach.
The problem is that man-in-the-middle attackers can also block CRL and OCSP checks, rendering the mechanism useless. Because of this, browser vendors have to manually blacklist known rogue certificates and then push the blacklist updates to the browsers.