На днях столкнулся с весьма интересным случаем:
На сервере Hyper-V работает виртуалка с ролью Enterprise CA и тут понадобилось перезагрузить физический хост. Всё прошло нормально, но утром посыпались жалобы, что люди не могут с токенами войти в систему и пользователи, подключающиеся к терминальному серверу по протоколу RDP-TLS получали одну и ту же ошибку: A revocation check could not be performed for the certificate. Начав расследование инцидента выяснилось, что CA по каким-то причинам отказался публиковать CRL'ы. Причём в эвентлоге ничего подозрительного обнаружено не было. Посмотрев последний CRL обнаружил, что время в Next Publish совпало с тем временем, когда хост Hyper-V ребутился (это было видно по эвентлогу загрузки системы). Как известно, по умолчанию Hyper-V при выключении сохраняет состояние виртуальных машин (как бы отправляет их в режим "sleep") и при включении обратно, восстанавливает их из этого режима. Вобщем, у CA был забит триггер обновления CRL'ов на определённое время и виртуалка его проспала. После этого CA даже не делал попыток переопубликовать CRL в течении 8 (или около того) часов, пока я их вручуню не опубликовал. 2-часовой overlap по очевидным причинам не спас ситуацию. Как выяснилось, CA не будет обновлять такие CRL'ы пока:
Пораскинув мозгами я проверил ещё один момент — работу Key Archival, т.к. сертификат CA Exchange обновляется по такому же приципу. Т.е. если физический хост временно недоступен (выключен, перезагружается, ковыряется в носу) и в этот период истекает сертификат CA Exchange, то после возвращения виртуалки из сна этот сертификат не обновляется и архивирование ключей перестаёт работать. Может, я один такой счастилвчик, кто нарвался на такую несложную, но противную проблему, но факт остаётся фактом. И здесь, CA не будет предпринимать попыток обновить CA Exchange пока:
Чтобы предотвратить подобное в дальнейшем, я выбрал следующий воркэраунд для Hyper-V:
Как видно из описания, вместе с выключением физического сервера, виртуальные машины с Enterprise CA будут выключаться тоже и включаться после включения физического сервера, что предотвратит состояния сна для Enterprise CA и подобная ситуация больше не должна проявляться.
Вадим, это не воркэраунд! Это "так должно быть"! Ни в коем случа нельзя критические сервисы отправлять в спячку!
Ну там время спячки буквально несколько минут и во время, когда пользователей в сети нет. Вот и не обращал на это внимание.
Comments: