На днях столкнулся с весьма интересным случаем:

На сервере 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'ы пока:

• кто-то опубликует их вручную;
• кто-то перезапустит службу certsvc.

Пораскинув мозгами я проверил ещё один момент — работу Key Archival, т.к. сертификат CA Exchange обновляется по такому же приципу. Т.е. если физический хост временно недоступен (выключен, перезагружается, ковыряется в носу) и в этот период истекает сертификат CA Exchange, то после возвращения виртуалки из сна этот сертификат не обновляется и архивирование ключей перестаёт работать. Может, я один такой счастилвчик, кто нарвался на такую несложную, но противную проблему, но факт остаётся фактом. И здесь, CA не будет предпринимать попыток обновить CA Exchange пока:

• кто-то запустит оснастку PKIView.msc (да-да, PKIView.msc может запустить триггер обновления CA Exchange);
• кто-то запустит команду: certutul –cainfo xchg;
• кто-то перезапустит службу certsvc.

Чтобы предотвратить подобное в дальнейшем, я выбрал следующий воркэраунд для Hyper-V:

1. Запустите оснастку Hyper-V Management;
2. Выберите виртуалку, на которой работает Enterprise CA и нажмите Settings;
3. Проскрольте список вниз до секции Management и разверните её;
4. В Automatic start action выберите Always start;
5. В Automatic stop action выберите Shutdown.
6. Повторите эти шаги для всех виртуальных машин, на которых работает Enterprise CA.

Как видно из описания, вместе с выключением физического сервера, виртуальные машины с Enterprise CA будут выключаться тоже и включаться после включения физического сервера, что предотвратит состояния сна для Enterprise CA и подобная ситуация больше не должна проявляться.

Иногда при публикации нового CRL вы получаете вот такую интересную ошибку: The directory name is invalid. 0x8007010b (WIN32/HTTP:267):

Откуда и почему она взялась — никто не знает, т.к. «я ничего не делал, оно само сломалось!». Иногда это оказывается правдой, но чаще — нет, администратор что-то сделал и всё поломал. Эта ошибка означает только одно: CA не смог поместить файлы либо в локальную папку, сетевую папку или опубликовать в LDAP. Не существует универсального способа определить причину ошибки, но есть универсальная методология поиска проблемы. Во-первых нужно залогониться на сервер CA и выполнить там следующую команду:

certutil –getreg CA\CRLPublicationURLs

и выбирайте все пути, под которыми есть хоть один из указанных флагов:

• CSURL_SERVERPUBLISH – 1
• CSURL_SERVERPUBLISHDELTA -- 40 (64)

по этим путям сервер CA публикует физические файлы. Если это локальный путь, убедитесь, что он существует и учётная запись System имеет право записи в неё. Если это сетевая папка, убедитесь, что:

• Сервер CA способен разрешить сетевое имя в IP адрес;
• Сервер CA способен получить доступ к сетевому ресурсу по SMB;
• Учётная запись компьютера CA (это выглядит как имя со знаком доллара вконце) имеет право Change или FullControl в сетевых разрешениях папки (не путать с правами NTFS!);
• Учётная запись компьютера CA имеет право записи в разрешениях NTFS.

Если любое из этих условий не выполняется — вы получите ошибку.

Если это путь LDAP, убедитесь в следующем:

• Учётная запись компьютера CA является членом группы Cert Publishers;
• Группа Cert Publishers имеет право FullControl на каждый вложенный контейнер по следующему LDAP пути (но не на сам контейнер CDP, а только вложенные):
  CN=CDP, CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain}.
• Внутри контейнера CDP (по пути указанному в предыдущем пункте) есть вложенный контейнер с именем равным NetBIOS имени компьютера CA. Если нет, то нужно создать вручную и назначить группе Cert Publishers право FullControl.

Если это путь LDAP, убедитесь в следующем. Когда всё исправлено, можно пробовать повторно публиковать CRL'ы:

certutil –CRL

Примечание: иногда бывает просто опечатка при конфигурировании пути в оснастке CA или названии целевой папки. Поэтому обращайте внимание на правильность указанных путей.

Вот и всё. Надеюсь такая нехитрая методичка поможет вам бороться с такой назойливой ошибкой.

Некоторое время я описал баг в AppLocker'е, который заключается в некорректной обработке правил пути, если путь содержит неанглийские буквы (подробнее см. Очередной баг в AppLocker). Как я уже говорил, я открыл кейс в саппорте и обещал отписаться, если будут какие-то новости. И я выполняю своё обещание публикацией официального ответа Microsoft:

We've investigated the issue and it appears to be a problem in the implementation of case-insensitive path comparison for characters outside the ASCII range. Fortunately it seems there is a workaround for the time being. If, in Local Security Policy, one specifies paths in all-uppercase characters, including uppercasing any non-ASCII characters as appropriate, then the rule will match properly. Concretely, for your example 'Mapīte', putting that string with lowercase ī in a rule's path in Local Security Policy will not work; however putting the string 'MAPĪTE' with uppercase Ī does seem to work.

Т.е. если путь содержит буквы верхней таблицы ASCII (символы 128 и выше), путь следует прописывать заглавными буквами. Я уже собрался наваять костыль на пошике, который будет делать это за меня (за счёт использования метода String.ToUpper()), но очень быстро обломался, поскольку консоль пошика не способна отображать диактрические знаки и скопировать правильный путь из консоли не удастся и всю работу по озаглавливанию букв придётся делать вручную.

Достаточно часто администраторы занимаются выпуском сертификатов с использованием нескольких имён. Например, когда нужно привязать один сертификат к нескольким именам: mail.company.com и owa.compny.com. Однако поле Subject может содержать только одно имя. Для разрешения этой проблемы используется расширение Subject Alternative Name (SAN). В этом расширении вы можете использовать сколько угодно дополнительных имён для сертификата.

Но как правильно же оформить несколько имён в сертификате на примере mail.company.com и owa.company.com? Здесь варианта всего 2:

• Использовать поле Subject и расширение SAN

Данный способ используется чаще для внешних сертификатов. Поле Subject заполняется следующим образом (красным выделены обязательные компоненты):

CN = mail.company.com
OU = <название подразделения>
OU = <ещё какое-то название подразделения>
O = <название организации>
L = <местоположение компании>
C = <код страны, где расположена компания>

Т.е. включается основное имя сертификата (по правде говоря, при использовании SAN, понятие основного имени отсутствует, т.к. все имена считаются равноценными. Здесь следует указывать имя, которое будет использоваться чаще всего приложениями, неподдерживающими расширение SAN) и опционально можно задать дополнительные DN суффиксы, отражающие принадлежность сертификата. И расширение SAN заполняется следующим образом:

DNS Name=mail.company.com
DNS Name=owa.company.com

Как видите, имя из Subject продублировано в SAN. Дело в том, что если в сертификате есть расширение SAN и приложение умеет его обрабатывать, приложение как правило настраивается только на проверку расширения SAN и в Subject они не заглядывают. Но это не всегда так. Иногда приложение смотрит и в Subject и в SAN. В таком случае имена дублировать не обязательно. Но в целях обеспечения совместимости следует ВСЕГДА дублировать имя из Subject в расширении SAN.

• Использовать только расширение SAN

Этот способ редко применяется во внешних сертификатах, а только внутренних. В этом случае поле Subject не заполняется совсем и оставляется пустым. А расширение SAN будет включать все необходимые имена:

DNS Name=mail.company.com
DNS Name=owa.company.com

Такая форма заполнения поддерживается в Internet PKI и описана в RFC 5280. Согласно этому RFC, если поле Subject не определено (пусто), имя для сертификата выбирается из расширения SAN, а само расширение помечается как критичное (см. RFC 5280 §4.2.1.6). Вот примерные пруфпики, как это выглядит в жизни:

на вкладке General имя формируется либо из первого имени в расширении SAN или из имени используемого конкретным приложением (например, при просмотре из браузера) и котрое перечислено в расширении SAN.

Здесь продемонстрировано пустое поле Subject.

И перечисление необходимых имён в расширении SAN. Критичность расширения определяется по наличию жёлтого треугольничка и восклицательного знака.

На заметку: что такое критичное расширение (critical extension)? Это просто расширение, которое приложение должно проверить в обязательном порядке. Если приложение видит такое расширение, приложение должно уметь его обработать и понять значение в этом расширении. Если приложение не знает, что делать с этим расширением или приложение не может разобрать значение этого расширения, приложение обязано отклонить данный сертификат. Более подробно о порядке поведения приложения.

Примечание: хоть и заявляется, что приложение должно отклонить сертификат, если значение расширения непонятно, это не в полной мере относится к расширению SAN. Приложение не обязано поддерживать все формы SAN, а может поддерживать только некоторые формы, например, только DNS Name. Но если поддерживаемая форма не может быть распознана, сертификат должен быть отклонён.

Поскольку расширение SAN является единственным средством идентификации имени сертификата, вполне логично ожидать, что это расширение будет помечено как критичное и обязательное для обработки приложением.

Какой способ из двух выбрать? А какой считаете более приемлемым. Если это сертификат внешнего веб-сервера, целесообразно использовать первый вариант, поскольку при помощи DN суффиксов можно конкретизировать принадлежность сертификата к вашей компании. А так же если предполагается доступ из приложений неподдерживающих расширение SAN. Это не обязательно компьютерные приложения, это могут быть приложения мобильных устройств. В целях избежания чрезмерного пиара VeriSign'a в моём бложике, представляю образцово-показательный сертификат выполненный первым способом на сайте Thawte: https://www.thawte.com/

Для использования внутри организации можно использовать и второй вариант, с пустым Subject. Например, для логонных сертификатов смарт-карт. Контроллеры домена вообще не смотрят на Subject логонного сертификата, а смотрят только в SAN на предмет наличия UPN в расширении.

Что бы почитать?

• RFC 5280
• Web server certificate enrollment with SAN extension

В различных интернетах всё ещё задают (и не мало) вопросы про проблемы подключения через remote desktop к серверу терминалов защищённому SSL сертификатом. При подключении пользователи видят вот такое:

И сообщение: A revocation check could not be performed for the certificate. Или в русском варианте — не удалось проверить не был ли отозван этот сертификат. А если нажать на View certificate… выясняется, что всё в порядке, сертификат доверен и цепочка построена правильно. Что это такое и как с этим жить?

Причины здесь может быть 2:

• Корневой сертификат цепочки сертификатов не установлен в Trusted Root CAs в *компьютерном* хранилище сертификатов;

Эта проблема встречается примерно в 60-70% случаев появления этой ошибки. Многие привыкли устанавливать корневые сертификаты по двойному клику в пользовательское хранилище. Но, новый mstsc.exe проверяет цепочку сертификатов так, чтобы она заканчивалась на доверенном корневом сертификате установленном в компьютерном хранилище. Поскольку сертификат недоверенный, certificate chaining engine даже и не пытается проверить что-то на отзыв. Как установить сертификат туда:

1. Войдите в систему с правами локального администратора.
2. На рабочем столе нажмите Start и Run… (в случае с Windows Vista/7 можете выделить поле Search programs and files) и в окне наберите MMC. Если появится окно UAC, подтвердите выполнение операции или введите пароль администратора.
3. В открывшейся консоли нажмите File и Add/Remove Snap-in.
4. В списке выделите Certificates и нажмите Add. В появившемся диалоговом окне переставьте переключатель в Computer account и нажмите Next.
5. В следующем окне нажмите Finish.
6. В расскрывшейся оснастке Certificates выделите папку Trusted Root CAs, нажмите правой кнопкой и выберите All Tasks –> Import. Следуйте инструкциям мастера для добавления корневого сертификата в компьютерное хранилище.

• Какие-то CRL'ы в цепочке недоступны.

Когда сертификат выдаётся внутренним CA, но пользователи подключаются к серверу через интернет (например из дома подключаются к RemoteApp по https), очень часто файлы сертификатов и CRL'ы издающего CA недоступны из интернета. В данном случае необходимо связаться с системным администратором, чтобы он переконфигурировал расширения CDP так, чтобы CRL'ы были доступны и из интернета.

Что бы почитать?

• Certificate Chaining Engine — как это работает
• Certificate chaining engine в PowerShell (часть 2)
• CRL Distribution Points и Authority Information Access
• Планирование расширений CDP и AIA