Немного затянул с публикацией, но лучше поздно чем никогда. В начале рабочей недели появились задержки при подключении по RDP ко всем компьютерам, оно подвисало на несколько секунд в стадии «Securing remote connection...», которая отвечает за установку шифрованного канала для безопасной передачи реквизитов.
Так как для RDS используются сертификаты от внутреннего CA и уже когда-то забыв обновить CRL корневого офлайнового CA решил проверить его здоровье в pkiview.msc.
Оснастка показала, что всё OK, но напротив обоих CA несколько секунд держался статус Verifying, что странно, так как все данные для проверки доступны внутри домена через LDAP и HTTP. Проверка через certutil -verify также подвисала на 10-15 секунд в стадии CERT_CHAIN_POLICY_BASE, причем с любыми сертификатами — не только от внутренних, но и от внешних CA (StartCom, Comodo и т.д.).
Проблема не ушла и после перерегистрации сертификатов с CRL в CDP и AIA. Отчаявшись, захватил сетевой дамп во время выполнения certutil -verify и увидел там следующее:
Трейс до ctldl.windowsupdate.com показал zapret.comcor.ru в пути, а его IP-адрес (CDN Akamai) оказался добавлен 01.08.2016 в реестр блокировки РКН.
Оказывается в Windows 8.1 (и позднее портирован в Vista, 7 и 8) появился механизм динамической загрузки списков доверенных и недоверенных удостоверяющих центров (CTL) на случай появления новых или их компрометации. Когда срок действия подходит к концу, клиент пытается обновить CTL и если это не удаётся, попытка повторяет при каждой установке SSL-соединения.
Посмотреть содержимое и проверить состояние CTL можно командами certutil -f -verifyCTL AuthRoot и certutil -f -verifyCTL Disallowed. Также этими командами можно восстановить содержимое хранилища сертификатов.
Списки загружаются с адреса ctldl.windowsupdate.com, но у провайдера сломалась страница-заглушка и соединения к запрещённым ресурсам блокировались по IP-адресу, что вызывало таймаут в 15 секунд при установке каждого соединения.
Подробное описание нового механизма есть на TechNet, для обходного решения таймаут можно задать через групповые политики в разделе Public Key Policies > Certificate Path Validation Settings > Network Retreival:
Пока гуглил описание механизма наткнулся на блог исследователя, где он описывает алгоритм работы на примере своей утилиты CTLInfo, которая умеет показывать содержимое и срок действия CTL.
TL;DR
При истечении срока действия CTL и недоступности ctldl.windowsupdate.com возможны задержки при установке SSL-соединений, старайтесь этого избегать.
Так как для RDS используются сертификаты от внутреннего CA и уже когда-то забыв обновить CRL корневого офлайнового CA решил проверить его здоровье в pkiview.msc.
Оснастка показала, что всё OK, но напротив обоих CA несколько секунд держался статус Verifying, что странно, так как все данные для проверки доступны внутри домена через LDAP и HTTP. Проверка через certutil -verify также подвисала на 10-15 секунд в стадии CERT_CHAIN_POLICY_BASE, причем с любыми сертификатами — не только от внутренних, но и от внешних CA (StartCom, Comodo и т.д.).
Проблема не ушла и после перерегистрации сертификатов с CRL в CDP и AIA. Отчаявшись, захватил сетевой дамп во время выполнения certutil -verify и увидел там следующее:
Трейс до ctldl.windowsupdate.com показал zapret.comcor.ru в пути, а его IP-адрес (CDN Akamai) оказался добавлен 01.08.2016 в реестр блокировки РКН.
Оказывается в Windows 8.1 (и позднее портирован в Vista, 7 и 8) появился механизм динамической загрузки списков доверенных и недоверенных удостоверяющих центров (CTL) на случай появления новых или их компрометации. Когда срок действия подходит к концу, клиент пытается обновить CTL и если это не удаётся, попытка повторяет при каждой установке SSL-соединения.
Посмотреть содержимое и проверить состояние CTL можно командами certutil -f -verifyCTL AuthRoot и certutil -f -verifyCTL Disallowed. Также этими командами можно восстановить содержимое хранилища сертификатов.
Списки загружаются с адреса ctldl.windowsupdate.com, но у провайдера сломалась страница-заглушка и соединения к запрещённым ресурсам блокировались по IP-адресу, что вызывало таймаут в 15 секунд при установке каждого соединения.
Подробное описание нового механизма есть на TechNet, для обходного решения таймаут можно задать через групповые политики в разделе Public Key Policies > Certificate Path Validation Settings > Network Retreival:
Пока гуглил описание механизма наткнулся на блог исследователя, где он описывает алгоритм работы на примере своей утилиты CTLInfo, которая умеет показывать содержимое и срок действия CTL.
