Так как для 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) на случай появления новых или их компрометации. Обновление происходит при первой установке 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.
Комментарии (12)
vavy25020
17.08.2016 10:53+1Проверка CRL на свежесть — это не проклятие, это нормально. А вот когда одни бесконтрольно портят связность в интернете, а другие это бесконечно долго терпят — вот это действительно проклятие.
citius
17.08.2016 11:39+1Дык тут не CRL, а CTL насколько я понял. Certificate trust list, т.е. список доверенных корневых.
CRL у каждого PKI свой.vavy25020
17.08.2016 12:09CTL мочь обновлять тоже логично и нормально.
Я понимаю, что методы его обновления могут быть разными, включая установку обновлений windows. Тоже с akamai айпишников, кстати.
Но в любом случае, если завязываешься на мировую систему сертификатов, имей доступ к миру.
А если у тебя в стране чебурашканетизация — то сам себе виноват, что у тебя в стране такая жизнь. :-(citius
17.08.2016 12:11Да я собсно не оправдываю, долбоебизм это совершенный.
Когда Самый Главный Рубильник в руках у обезьян, можно ожидать чего угодно.
DM-Demius
17.08.2016 10:54+2Э нет, это дебилизм системы запретов, которое кое кто ввёл у нас в стране и не знание работы ИТ систем этими «Умными».
orcy
17.08.2016 15:04Да, но в тоже время проверять на сервере каждый раз по сети при установки соединения тоже решение не очень. Роскомнадзор это только одна из возможных проблем
navion
17.08.2016 15:18Насколько я понимаю, список кэшируется на срок действия (либо до перезагрузки), но пока он не загружаен — API пытается это сделать при каждом соединении и возникает задержка.
Revertis
17.08.2016 11:10+2Получается, что Роскомнадзор запретил валидацию сертификатов в Windows у всех россиян?
navion
17.08.2016 14:15+1Им не впервой, пора добавить проверку реестра блокировки в алгоритм траблшутинга сети.
ls1
Это вообще проклятие современных сетей — зависимость одного сервиса от сетевой доступности совсем другого, постоянно приходится под капот со сниффером лезть.
HappyGroundhog
Самое интересное управлять и обновлять софт в сети, физически отключенной от Интернета. Там такие занятные косяки иногда вылезают. Про софт, основанный на Ruby можно вообще отдельный трактат написать. Автору отдельное спасибо за ссылку на политику.