August 16, 2016 at 23:30An unexpected feature of certificate verification in Windows
Delayed a little with the publication, but better late than never. At the beginning of the working week there were delays when connecting via RDP to all computers, it hung for a few seconds in the “Securing remote connection ...” stage, which is responsible for setting up an encrypted channel for secure transfer of details.
Since certificates from the internal CA are used for RDS, and already once having forgotten to update the CRL of the root offline CA, I decided to check its health in pkiview.msc .
The snap-in showed that everything is OK, but opposite to both CAs, the Verifying status was held for several seconds, which is strange, since all data for verification is available inside the domain via LDAP and HTTP. Verification through certutil -verify also hung for 10-15 seconds in the CERT_CHAIN_POLICY_BASE stage, and with any certificates - not only from internal, but also from external CAs (StartCom, Comodo, etc.).
The problem still persists after re-registering certificates from CRL to CDP and AIA . Desperate, captured a network dump at runtime certutil -verifyand saw the following there:
Trace to ctldl.windowsupdate.com showed zapret.comcor.ru on the way, and its IP address (CDN Akamai) was added on 01.08.2016 to the ILV blocking registry .
It turns out that in Windows 8.1 (and later ported to Vista, 7 and 8), a mechanism for dynamically loading lists of trusted and untrusted Certification Authorities ( CTLs ) appeared in case of new or compromised ones. When the expiration is about to expire, the client tries to update the CTL, and if this fails, the attempt retries the SSL connection each time it is established.
You can view the contents and check CTL status with the commands certutil -f -verifyCTL AuthRoot and certutil -f -verifyCTL Disallowed. You can also restore the contents of the certificate store with these commands.
Lists are downloaded from ctldl.windowsupdate.com, but the provider has a stub page and connections to restricted resources were blocked by IP address, which caused a timeout of 15 seconds when each connection was established.
There is a detailed description of the new mechanism on TechNet , for a workaround, the timeout can be set through group policies in the section Public Key Policies> Certificate Path Validation Settings> Network Retreival:
While I googled the description of the mechanism, I came across a researcher’s blog where he describes the algorithm for working with the example of his CTLInfo utility , which can show the contents and expiration of CTL.
TL; DR
If CTL expires and ctldl.windowsupdate.com is unavailable, delays in establishing SSL connections may occur, try to avoid this.
Since certificates from the internal CA are used for RDS, and already once having forgotten to update the CRL of the root offline CA, I decided to check its health in pkiview.msc .
The snap-in showed that everything is OK, but opposite to both CAs, the Verifying status was held for several seconds, which is strange, since all data for verification is available inside the domain via LDAP and HTTP. Verification through certutil -verify also hung for 10-15 seconds in the CERT_CHAIN_POLICY_BASE stage, and with any certificates - not only from internal, but also from external CAs (StartCom, Comodo, etc.).
The problem still persists after re-registering certificates from CRL to CDP and AIA . Desperate, captured a network dump at runtime certutil -verifyand saw the following there:
Trace to ctldl.windowsupdate.com showed zapret.comcor.ru on the way, and its IP address (CDN Akamai) was added on 01.08.2016 to the ILV blocking registry .
It turns out that in Windows 8.1 (and later ported to Vista, 7 and 8), a mechanism for dynamically loading lists of trusted and untrusted Certification Authorities ( CTLs ) appeared in case of new or compromised ones. When the expiration is about to expire, the client tries to update the CTL, and if this fails, the attempt retries the SSL connection each time it is established.
You can view the contents and check CTL status with the commands certutil -f -verifyCTL AuthRoot and certutil -f -verifyCTL Disallowed. You can also restore the contents of the certificate store with these commands.
Lists are downloaded from ctldl.windowsupdate.com, but the provider has a stub page and connections to restricted resources were blocked by IP address, which caused a timeout of 15 seconds when each connection was established.
There is a detailed description of the new mechanism on TechNet , for a workaround, the timeout can be set through group policies in the section Public Key Policies> Certificate Path Validation Settings> Network Retreival:
While I googled the description of the mechanism, I came across a researcher’s blog where he describes the algorithm for working with the example of his CTLInfo utility , which can show the contents and expiration of CTL.