Big delay when calling SslStream.AuthenticateAsClient
Some time ago I had a customer who was opening a SSL connection on his C# application, and he was calling SslStream.AuthenticateAsClient. His problem was that this call was taking around 15 seconds for each connection he made.
I debugged the issue and saw that the time that SslStream.AuthenticateAsClient was taking went to the process of building the certificate chain of the SSL server certificate with X509Chain.Build. The Build method ended up calling CertGetCertificateChain API, which took all the time. Digging a bit further to understand why CertGetCertificateChain took so long, I saw that we were trying to download the following file from the Internet:
Why were we downloading this file? Well, this will happen by default on Windows when we build the chain of a cert which root CA cert is not installed in the system. This is called the Automatic Root Certificates Update feature, and it is available on Windows XP/Server 2003 and later OS versions, including Windows 7/Server 2008 R2.
Here you can find more info on this feature and why we are using it in this scenario:
Certificate Support and Resulting Internet Communication in Windows 7 and Windows Server 2008 R2
How Update Root Certificates communicates with Internet sites
This subsection focuses on how the Update Root Certificates feature communicates with Internet sites.
If the Update Root Certificates feature has not been turned off through Group Policy, and the application on your server is presented with a certificate issued by a root CA that is not directly trusted, the Update Root Certificates feature communicates across the Internet as follows:
Specific information sent or received: The Update Root Certificates feature sends a request to the Windows Update Web site, asking for the current list of root CAs in the Microsoft Root Certificate Program. If the root CA that is not directly trusted is on the list, Update Root Certificates obtains the certificate for that root CA and places it in the trusted certificate store on the server. No authentication or unique identification of the administrator or user is used in this exchange.
Default setting and ability to disable: Update Root Certificates is turned on by default in Windows 7 and Windows Server 2008 R2. You can turn off this feature by using Group Policy. For more information, see Procedures for viewing or changing Group Policy settings that affect certificates in Windows 7 and Windows Server 2008 R2 later in this section.
Trigger and user notification: Update Root Certificates is triggered when the administrator or user at the computer is presented with a certificate issued by a root CA that is not directly trusted. There is no user notification.
Logging: Events are logged in Event Viewer. To locate the events, click Windows Logs, click Application, and the Source is CAPI2. Events containing information such as the following are logged:
For Event ID 4100:
Description: Successful auto update retrieval of a non-Microsoft root list sequence number from: URL_for_Windows_Update_Web_Site
For Event ID 4101:
Description: Failed auto update retrieval of a non-Microsoft root list sequence number from: URL_for_Windows_Update_Web_Site with error: hexadecimal_error_value
Encryption, privacy, and storage: When requests or certificates are sent to or from Update Root Certificates, no encryption is used. Microsoft does not track access to the list of trusted CAs that it maintains on the Windows Update Web site.
Transmission protocol and port: The transmission protocol is HTTP and the port is 80.
For older versions of the OS:
Certificate Support and Resulting Internet Communication in Windows Vista
Specific information sent or received: The Update Root Certificates feature sends a request to https://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en, asking for the current list of root certification authorities in the Microsoft Root Certificate Program. If the root CA that is not directly trusted is named in the list, Update Root Certificates obtains the certificate for that root CA and places it in the trusted certificate store on the user's computer. No user authentication or unique user identification is used in this exchange.
Certificate Support and the Update Root Certificates Component
Summing up, this behavior is by design. Options we have are:
1) Install the root CA cert locally so we don’t need to go to the Internet for the list of trusted root CA certs.
2) Disable the Automatic Root Certificates Update feature via GPO so we don’t go to the Internet in any case.
I hope this helps.
Alex (Alejandro Campos Magencio)