Unexpected certificate validation feature in Windows
Slightly delayed 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 the secure transmission of details.
Since RDS uses certificates from the internal CA and having once forgotten to update the CRL of the root offline CA decided to check its health in pkiview.msc .
The snap-in showed that everything is OK, but opposite both CAs, the Verifying status was held for a few seconds, which is strange, since all verification data is available within the domain via LDAP and HTTP. Check 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 CA (StartCom, Comodo, etc.).
The problem did not go away even after re-registering certificates from CRL to CDP and AIA . Desperate, I captured a network dump during certutil -verify and saw the following:
')
Trace to ctldl.windowsupdate.com showed zapret.comcor.ru on the way, and its IP address (CDN Akamai) was added on August 1, 2016 to the RKN lock 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 new ones appeared or they were compromised. When it expires, the client tries to update the CTL and if that fails, the attempt repeats each time an SSL connection is established.
You can view the contents and check the status of the CTL with the certutil -f -verifyCTL AuthRoot and certutil -f -verifyCTL Disallowed commands . Also, these commands can restore the contents of the certificate store.
The lists are downloaded from ctldl.windowsupdate.com, but the provider broke the stub page and the connections to the forbidden resources were blocked by the IP address, which caused a timeout of 15 seconds when each connection was established.
A detailed description of the new mechanism is available on TechNet ; for a workaround, the timeout can be set via group policies in the Public Key Policies> Certificate Path Validation Settings> Network Retreival section:
While Google was describing the mechanism, I came across a researcher's blog , where he describes an algorithm for working with the example of his utility CTLInfo , which is able to display the contents and the validity period of the CTL.
TL; DR
If the CTL expires and ctldl.windowsupdate.com becomes unavailable, there may be delays when establishing SSL connections, try to avoid it.
Since RDS uses certificates from the internal CA and having once forgotten to update the CRL of the root offline CA decided to check its health in pkiview.msc .
The snap-in showed that everything is OK, but opposite both CAs, the Verifying status was held for a few seconds, which is strange, since all verification data is available within the domain via LDAP and HTTP. Check 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 CA (StartCom, Comodo, etc.).
The problem did not go away even after re-registering certificates from CRL to CDP and AIA . Desperate, I captured a network dump during certutil -verify and saw the following:
')
Trace to ctldl.windowsupdate.com showed zapret.comcor.ru on the way, and its IP address (CDN Akamai) was added on August 1, 2016 to the RKN lock 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 new ones appeared or they were compromised. When it expires, the client tries to update the CTL and if that fails, the attempt repeats each time an SSL connection is established.
You can view the contents and check the status of the CTL with the certutil -f -verifyCTL AuthRoot and certutil -f -verifyCTL Disallowed commands . Also, these commands can restore the contents of the certificate store.
The lists are downloaded from ctldl.windowsupdate.com, but the provider broke the stub page and the connections to the forbidden resources were blocked by the IP address, which caused a timeout of 15 seconds when each connection was established.
A detailed description of the new mechanism is available on TechNet ; for a workaround, the timeout can be set via group policies in the Public Key Policies> Certificate Path Validation Settings> Network Retreival section:
While Google was describing the mechanism, I came across a researcher's blog , where he describes an algorithm for working with the example of his utility CTLInfo , which is able to display the contents and the validity period of the CTL.
Source: https://habr.com/ru/post/306974/
All Articles