Fix SSL/TLS Issues After Installing KB 931125 on Windows Server

Table of Contents

This article addresses and provides solutions for Secure Sockets Layer (SSL) and Transport Layer Security (TLS) communication problems encountered following the installation of Knowledge Base article KB 931125 on Windows Server systems. These issues can manifest unexpectedly after the update, disrupting critical services and applications that rely on secure communication protocols. Understanding the symptoms, causes, and resolutions is crucial for maintaining system stability and security.

Identifying Symptoms of SSL/TLS Communication Failures¶

Post-installation of KB 931125, several applications and operations dependent on TLS-based authentication may experience sudden failures. These failures often occur without any apparent configuration changes, making initial diagnosis challenging. Recognizing the symptoms is the first step towards effective troubleshooting. The impacts can range from disrupted network access to failures in critical server applications.

Here are common symptoms that indicate potential SSL/TLS communication problems after applying the update:

• Wireless and Wired Network Access Issues: Users may experience failures in accessing both wireless and wired networks that utilize certificate-based authentication. This can lead to a complete loss of network connectivity for affected devices.
• Lync and Office Communications Server Connectivity Problems: Client applications attempting to connect to Lync or Office Communications Server might fail to establish secure connections. This impacts real-time communication and collaboration capabilities.
• Exchange Server Unified Messaging Voice Mail Failures: Voice mail systems integrated with Exchange Server and Unified Messaging may cease to function correctly. This can disrupt voice communication services and message delivery.
• Inaccessible SSL-Enabled Websites: Users may be unable to access websites that rely on SSL or TLS for secure connections. This results in website unavailability and potential business disruption if critical web services are affected.
• Outlook Logon Failures: Microsoft Outlook clients might fail to log in or connect to Exchange servers. This disrupts email communication and calendaring functions for users.
• Operating System and User Logon Delays: The boot process of the operating system and user logon procedures can become significantly slower. This can lead to decreased productivity due to extended wait times.

To further pinpoint the issue, examine system and application-specific event logs for entries that correlate with these symptoms. Specific event IDs and sources can provide valuable clues. The following table details some key events that may be logged in Windows event logs when SSL/TLS communication problems arise due to this issue.

Relevant Event Logs for SSL/TLS Issues¶

| Event Log | Event Source | Event ID | Event Text ================

Event ID 36885 - Schannel¶

Event Text: “When asking for client authentication, this server sends a list of trusted certificate authorities to the client. The client uses this list to choose a client certificate that is trusted by the server. Currently, this server trusts so many certificate authorities that the list has grown too long. This list has thus been truncated. The administrator of this machine should review the certificate authorities trusted for client authentication and remove those that do not really need to be trusted.”

This warning event indicates that the server’s list of trusted certificate authorities has exceeded the maximum supported size (16KB). As a result, the list is truncated before being sent to clients during the SSL/TLS handshake. This truncation can lead to authentication failures because clients may not find their trusted root certificate authority in the shortened list.

Event ID 36887 - Schannel¶

Event Text: “The following fatal alert was received: 47”

This error event with fatal alert code 47 signifies a no_certificate alert during the SSL/TLS handshake. This often occurs when the server requests a client certificate for authentication, but the client either does not have a suitable certificate or the certificate is not trusted by the server due to the truncated trusted CA list.

Event ID 39 - NapAgent¶

Event Text: “The Network Access Protection Agent was unable to determine which HRAs to request a health certificate from. A network change or if GP is configured, a configuration change will prompt further attempts to acquire a health certificate. Otherwise no further attempts will be made. Contact the HRA administrator for more information.”

This event from the Network Access Protection (NAP) Agent indicates issues with obtaining health certificates, which can be related to underlying SSL/TLS communication failures. NAP relies on secure communication for health certificate acquisition and validation.

Event IDs 20225 & 20271 - RemoteAccess¶

Event Text (20225): “The following error occurred in the Point to Point Protocol module on port:
VPN2-509, UserName: <username>. The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.”

Event Text (20271): “The user <username> connected from <IP address> but failed an authentication attempt due to the following reason:
The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.”

These RemoteAccess events indicate authentication failures for VPN connections. While the error messages suggest policy mismatches, the underlying cause can be SSL/TLS issues preventing proper certificate validation during VPN authentication.

Understanding the Root Cause: Excessive Trusted Root Certificates¶

The problems described above are often triggered by updating Third-party Root Certification Authorities using the December 2012 KB 931125 update package. Critically, this update package was initially intended only for client versions of Windows operating systems. However, it was mistakenly offered to server operating systems for a brief period through Windows Update and Windows Server Update Services (WSUS).

The KB 931125 package inadvertently installed over 330 additional Third-party Root Certification Authorities on servers. This massive influx of root certificates caused the list of trusted certificate authorities to exceed the size limit supported by the Schannel security package.

The Schannel security package, responsible for handling SSL/TLS in Windows, has a maximum limit of 16 kilobytes (KB) for the trusted certificate authorities list. When the number of Third-party Root Certification Authorities becomes excessively large, as with the erroneous application of KB 931125, the 16KB limit is surpassed. This limitation leads directly to the TLS/SSL communication problems and symptoms outlined earlier.

Step-by-Step Resolution: Removing Excess Root Certificates¶

To resolve these SSL/TLS communication issues, the key is to remove the excessive Third-party Root Certification Authorities installed by the incorrect KB 931125 update. The resolution process differs slightly depending on whether you use WSUS to manage updates or if the update was directly installed.

Resolution for WSUS Users¶

If you utilize Windows Server Update Services (WSUS) and have not yet installed the December 2012 KB 931125 update, it is crucial to prevent its installation. Follow these steps:

1. Synchronize WSUS Servers: Initiate a synchronization of your WSUS servers to ensure they have the latest update information from Microsoft.
2. Approve Expirations: Within your WSUS management console, approve the expiration of the KB 931125 update. This action will prevent your WSUS servers from deploying this problematic update to client or server machines.

By taking these steps, you proactively avoid the SSL/TLS communication issues caused by KB 931125 in your WSUS-managed environment.

Resolution for Systems with KB 931125 Installed¶

If the December 2012 KB 931125 update package has already been installed on your Windows Servers, you need to remove the additional Third-party Root Certification Authorities. This involves deleting a specific registry key that stores these certificates.

Caution: Modifying the Windows Registry can have significant impacts on system stability if not done correctly. It is strongly recommended to back up your registry before proceeding with these steps. Incorrect registry modifications can lead to system malfunctions requiring operating system reinstallation.

Follow these steps carefully to remove the excess root certificates:

1. Open Registry Editor: Press the Windows Key + R to open the Run dialog. Type regedit and press Enter. Click Yes if prompted by User Account Control.

   

2. Locate the Target Registry Subkey: In the Registry Editor, navigate to the following registry path using the left-hand pane:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot

   You can expand the folders by clicking the arrow next to each folder name.

3. Delete the “Certificates” Key: Once you have navigated to the AuthRoot key, locate the subkey named Certificates. Right-click on the Certificates key.

   

4. Confirm Deletion: Select Delete from the context menu. A confirmation dialog will appear asking “Are you sure you want to permanently delete this key and all of its subkeys?”. Click Yes to confirm the deletion.

5. Restart the Server: After deleting the registry key, restart your Windows Server. This will ensure that the changes are applied and the system rebuilds the trusted root certificate list without the excessive entries.

After restarting, the SSL/TLS communication problems caused by the oversized trusted root certificate list should be resolved. Monitor your systems and applications to confirm that the symptoms have disappeared and that services are functioning correctly.

Further Insights: Trusted Root Certification List and Schannel¶

To understand why this resolution works, it’s important to delve deeper into how Windows handles trusted root certificates and how Schannel utilizes them for secure communication.

When a server uses TLS/SSL to encrypt network traffic and requires client certificates for authentication, it sends a list of trusted certificate authorities to the client during the authentication handshake process. This list informs the client about the certificate authorities whose certificates the server will accept.

For successful authentication, the client must possess a certificate that chains up to a root certificate present in the server’s trusted certificate authority list. The client certificate is always the end-entity certificate in the chain, not part of the chain itself.

Schannel, the security package in Windows responsible for SSL/TLS, constructs this trusted certificate authority list by examining the “Trusted Root Certification Authorities” store on the local computer. Every certificate designated as trusted for client authentication purposes is added to this list.

However, as mentioned previously, Schannel has a size limitation of 16 KB for this trusted certificate authority list in Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012. If the aggregated size of certificates in the Trusted Root Certification Authorities store exceeds this 16 KB limit, Schannel takes the following actions:

1. Logs Warning Event ID 36855: Schannel records a warning event indicating that the trusted certificate authority list is too long and will be truncated.
2. Truncates the List: Schannel shortens the list of trusted root certificates to fit within the 16 KB limit before sending it to the client computer.

When a client receives this truncated list, it may not find its trusted root certificate authority within the list. Even if the client possesses a valid certificate, if its corresponding root certificate was truncated by Schannel, the server will be unable to authenticate the client. This results in the SSL/TLS communication failures and authentication issues described in this article.

By deleting the Certificates registry key, you effectively force Windows to rebuild the Trusted Root Certification Authorities store, ideally removing the excessive certificates introduced by the erroneous KB 931125 update and bringing the list size back within the 16KB limit.

If you found this article helpful or have further questions regarding SSL/TLS certificate issues after installing Windows updates, please leave a comment below! Your experiences and questions can help others facing similar challenges.