Microsoft Security Advisory (2641690)

Why was this advisory revised January 19, 2012? 
Microsoft revised this advisory to announce the release of an update for Windows Mobile 6.x, Windows Phone 7, and Windows Phone 7.5 devices. For more information, see Microsoft Knowledge Base Article 2641690.

Why was this advisory revised November 16, 2011? 
Microsoft revised this advisory to announce the rerelease of the KB2641690 update for Windows XP Professional x64 Edition Service Pack 2 and all supported editions of Windows Server 2003. The rereleased update addresses an issue noted by customers using Windows Server Update Services (WSUS), where the applicability for the update was not properly detected.

Customers of Windows XP Professional x64 Edition Service Pack 2 and all supported editions of Windows Server 2003 should apply the rereleased version of the KB2641690 update to be protected against the use of fraudulent certificates as described in this advisory. Customers of Windows XP Service Pack 3 and supported editions of Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 are not affected by this rerelease.

The majority of customers have automatic updating enabled and will not need to take any action because the rereleased KB2641690 update will be downloaded and installed automatically.

What is the scope of the advisory? 
The purpose of this advisory is to notify customers that DigiCert Sdn. Bhd has issued 22 certificates with weak 512 bit keys. These weak keys have allowed some of the certificates to be compromised. Microsoft has revoked the trust of this subordinate CA in an update that moves two intermediate CA certificates to the Microsoft Untrusted Certificate Store.

What caused the issue? 
Microsoft was notified by Entrust, a CA in the Microsoft Root Certificate Program, that one of their subordinate CAs, DigiCert Sdn. Bhd, issued 22 certificates with weak 512 bit keys. Additionally, this subordinate CA has issued certificates without the appropriate usage extensions or revocation information. This is a violation of the Microsoft Root Certificate Program requirements.

There is no indication that any certificates were issued fraudulently. Instead, cryptographically weak keys allowed some of the certificates to be duplicated and used in a fraudulent manner. Entrust and GTE CyberTrust have revoked the intermediate CA certificates issued to DigiCert Sdn. Bhd. Microsoft is providing an update that revokes the trust of these two intermediate certificates to further protect customers.

How might an attacker duplicate a certificate? 
A digital signature can only be created by the person who possesses the certificate’s private key. An attacker can attempt to guess the private key and use mathematical techniques to determine if a guess is correct. The difficulty of successfully guessing the private key is proportional to the number of bits used in the key. Therefore, the larger the key the longer it takes an attacker to guess the private key. Using modern hardware, 512 bit keys can be successfully guessed in a short amount of time.

How might an attacker use fraudulent certificates? 
An attacker could use the 512 bit certificates to spoof content, perform phishing attacks, or perform man-in-the-middle attacks against all Web browser users including users of Internet Explorer.

What is Microsoft doing to help with resolving this issue? 
Although this issue does not result from an issue in any Microsoft product, we have nevertheless released an update that moves two intermediate certificates issued by Entrust and GTE CyberTrust to the Microsoft Untrusted Certificate Store. Microsoft recommends that customers apply the update immediately.

What is a man-in-the-middle attack? 
A man-in-the-middle attack occurs when an attacker reroutes communication between two users through the attacker’s computer without the knowledge of the two communicating users. Each user in the communication unknowingly sends traffic to and receives traffic from the attacker, all the while thinking they are communicating only with the intended user.

What is a certification authority (CA)? 
Certification authorities are the organizations that issue certificates. They establish and verify the authenticity of public keys that belong to people or other certification authorities, and they verify the identity of a person or organization that asks for a certificate.

What is the procedure for revoking a certificate? 
There is a standard procedure that should allow a certificate authority to prevent certificates from being accepted if they are used. Every certificate issuer periodically generates a Certificate Revocation List (CRL), which lists all the certificates that should be considered invalid. Every certificate should provide a piece of data called the CRL Distribution Point (CDP) that indicates the location where the CRL can be obtained.

An alternative way for Web browsers to validate the identity of a digital certificate is by using the Online Certificate Status Protocol (OCSP). OCSP allows interactive validation of a certificate by connecting to an OCSP responder, hosted by the Certificate Authority (CA) which signed the digital certificate. Every certificate should provide a pointer to the OCSP responder location through the Authority Information Access (AIA) extension in the certificate. In addition, OCSP stapling allows the Web server itself to provide an OCSP validation response to the client.

OCSP validation is enabled by default on Internet Explorer 7 and later versions of Internet Explorer on supported editions of Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. On these operating systems, if the OCSP validation check fails, the browser will validate the certificate by contacting the CRL Location.

Some network deployments may prevent online OCSP or CRL updates so Microsoft has released an update for all versions of Microsoft Windows that adds these certificates to the Microsoft Untrusted Certificate Store. Moving these certificates to the Microsoft Untrusted Certificate Store ensures these fraudulent certificates are not trusted in all network deployment scenarios.

For more information on certificate revocation checking, see the TechNet article, Certificate Revocation and Status Checking.

How do I know if I’ve encountered an invalid certificate error? 
When Internet Explorer encounters an invalid certificate, users are presented with a Web page that says, "There is a problem with this website’s security certificate." Users are encouraged to close the Web page and navigate away from the site when this warning message appears.

Users are only presented this message when the certificate is determined to be invalid, for instance when the user has Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) validation enabled. OCSP validation is enabled by default on Internet Explorer 7 and later versions of Internet Explorer on supported editions of Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

After applying the update, how can I verify the certificates in the Microsoft Untrusted Certificates Store? 
For information on how to view certificates, see the MSDN article, How to: View Certificates with the MMC Snap-in.

In the Certificates MMC snap-in, verify that the following certificates have been added to the Untrusted Certificates folder:

For supported releases of Microsoft Windows

The majority of customers have automatic updating enabled and will not need to take any action because the KB2641690 update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

For administrators and enterprise installations, or end users who want to install the KB2641690 update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using the Microsoft Update service. For more information on how to manually apply the update, see Microsoft Knowledge Base Article 2641690.

For Windows Mobile 6.x, Windows Phone 7, and Windows Phone 7.5 devices

For information about the update for Windows Mobile 6.x, Windows Phone 7, and Windows Phone 7.5 devices, see Microsoft Knowledge Base Article 2641690.