With all of the activity over the past year as a result of the Flame malware fiasco, it seems a great time to take a step back and review the issues, considerations, and responses appropriate to the Windows Server Update Services (WSUS) environment as a result of these certificate-related changes.

 

During the 2nd and 3rd quarters of 2012, a number of changes were made in the certificate infrastructure of Windows Update, which also impacted the operation of WSUS environments. All of these changes culminated in the release of KB2661254 which has as its sole purpose to quarantine (read: disable) any certificates present on a system that were built with key-lengths less than 1024-bits.

 

For WSUS Administrators, there are three possible ways in which this may have an impact.

 

WSUS SSL Certificates

For WSUS Administrators who have implemented Secure Sockets Layer (SSL) connections for their WSUS servers, the age and provenance of the SSL certificates in use may be a concern. Be sure that your SSL certificates have at least 1024-bit keys.

 

On Windows Server 2008 and newer (IIS7), to check your SSL certificate, navigate to the IIS console in Server Manager, select the root node of the IIS console, and double-click the “Server Certificates” icon. Double-click on the certificate to open the Certificate dialog.

WSUS SSL Cert on IIS7.png

On Windows Server 2003 (IIS6), open the IIS Admin Console, select the WSUS website, open the Properties dialog, select the “Directory Security” tab, and click on the “View Certificate…” button to open the Certificate dialog.

WSUS SSL Cert on IIS6.png

Once the Certificate dialog is open, select the Details tab, and view the value in the “Public key” field to identify the key-length.

Certificate Key Length verification.png

Local Publishing Certificates

More commonly (than SSL, believe it or not), many WSUS Administrators may have local publishing certificates in use. All local publishing certificates created prior to April, 2012, will have been created with 512-bit keys. Additionally, any certificates created after April, 2012, but prior to the installation of KB2720211 (April 2012) or KB2734608 (August 2012) to the WSUS server, will also be 512-bits. Certificates created after the installation of one of those updates will be 2048-bit certificates.

 

To check your Local Publishing Certificate, on the WSUS server launch the Certificate Management console with CertMgr.msc. Navigate to the “Trusted Publishers” certificate store, and double-click on the WSUS Publishers Self-signed certificate. As with the SSL certificate above, on the Details tab, scroll down the attribute list and find the “Public key” attribute. It should show “RSA (2048 Bits)”.

Other Certificate-based Applications

In addition to the two instances directly affecting WSUS, there may also be other applications that are dependent upon certificates for their operation. SolarWinds Patch Manager is one such application. It uses certificates to authenticate and encrypt console-to-server and inter-role communications. It was updated in July, 2012, with the release of v1.73. However, there may be other applications in the environment that have not been updated. It’s important to know which applications you have that are certificate-based and what type of certificates are in use.

 

Beware KB2661254

KB2661254, if installed, will BREAK all three of the above scenarios by quarantining the certificates.

 

If the SSL certificate is less than 1024 bits, the Windows Update Agent will record HTTP 403 errors, most likely an HTTP 403.4 (SSL required). In the WindowsUpdate.log these will appear as error codes 0x80190193 or
0x80244018.

 

If the Publishing certificate is less than 1024 bits, the publishing software will encounter errors publishing new packages, and the Windows Update Agent will record an 0x800B0109 error.

 

Other applications affected may behave in various different ways, for example in the case of SolarWinds Patch Manager, the consoles will be unable to connect to the application servers, and if you have more than one Patch Manager server deployed in a distributed infrastructure, the servers will be unable to communicate with one another. Any attempt to register a new server will also fail.

 

Be sure to patch the WSUS server, update the SSL or Publishing certificates, redistribute the certificates, and re-publish any locally-published updates prior to installing KB2661254. For more information, please read the complete Microsoft KB2661254 article, which also includes guidance on how to override the impact of this update if you have already installed it and cannot resolve key-length issues with existing certificates.

 

Why Is This Still an Issue?

Inasmuch as the update has been available for nine months, you might think this is merely historical pedanticism at this point.

 

Sadly, though, every day I encounter environments that have not patched the WSUS server (KB2720211) nor deployed KB2661254. This article is for those who have not yet done so, in the hopes that they will be able to
avoid the trials and tribulations experienced by those who inspired this article to be written.