Иногда при публикации нового 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

Уже прошёл почти год моего опыта использования AppLocker'а в домашних, тестовых и производстенных условиях и я хотел бы поделиться своими впечатлениями об этом со стороны перспективы использования этой технологии. К сожалению (а может и к счастью?) эту технологию постиг эпик фейл. И это даже при весьма удачной технической реализацией, которая более удобная в управлении, чем SRP и более надёжная. Хотя и с известными багами.

Microsoft создала потребительскую технологию, актуальную для всех секторов рынка, но давать её решила только VIP'ам, а остальным только пускать слюнки. Я говорю о том, что AppLocker доступен только в редакциях Ultimate и Enterprise десктопной Windows 7. Этим самым из целевой аудитории отваливается домашний сектор. В реальной жизни кроме пиратов мало кто приобретает компьютер с Windows 7 Ultimate. Чаще это ноутбуки с редакциями Home Basic/Premium, то же касается и обычных десктопов. Так же отваливается как минимум весь сектор Small Business и Medium тоже. SMB и средний бизнес тоже не будет приобретать Windows 7 Enterprise, а скорее будет покупать Professional, поскольку у Enterprise против Professional реальных преимуществ для этих секторов почти нет. А SMB — это основной рынок любой страны и по большому счёту он делает погоду на рынке. Да и крупные компании тоже особо тратиться на Enterprise не будут (хотя, Software Assurance им покрывает эти расходы). Иными словами, целевая аудитория этой технологии — средний (в меньшей степени) и крупный бизнес. Это маркетоЕдная составляющая проблемы.

Другая проблема кроется в технической составляющей. При всех достоинствах, AppLocker имеет определённые недостатки, которые заключаются в ограниченном применении правил издателей (подробнее см.тут: Встречаем – AppLocker!). Уж очень неоднозначно описываются правила издателей (а кто-нибудь пробовал строгие правила издатедей? Нет, а попробуйте и узнаете что это такое :-)), из-за чего они могут обхватывать нежелательные сертификаты доверенного поставщика. И с этим бороться сложно. Хотя, кому как. Из-за этого более целесообразным является использование правила хеша, что в свою очередь доставляет головняка при обновлении исполняемых файлов, для которых создано правило хеша. Их каждый раз придётся пересчитывать и обновлять сами правила. Это не смертельно, но уже не так весело, как в вайтпеперах и уютненьких бложеках MVP-маркетоидов.

Но наиболее глобальная проблема даже не в недостатках правил издателей или бага в правилах пути. Наиболее глобальная проблема кроется в интеграции AppLocker'а в существующую среду и крупный бизнес здесь страдает от этого сильнее, чем смалл бизнес. Это связано с тем, что в крупном бизнесе практически никогда не бывает сетей с установленной единственной версией ОС. Там обязательно присустствует парк ОС из разных поколений (начиная от Windows 2000/XP до Windows 7). AppLocker покрывает только малую часть из всего парка (только Windows 7 Enterprise). Для остальных приходится же использовать что-то другое. Обычно это Software Restriction Policies. И администраторам придётся создавать 2 набора политик: отдельно SRP для XP/Vista и отдельно AppLocker для Windows 7. То же самое относится и к редактированию политик. Если обновился какой-то файл, придётся обновлять политику SRP и AppLocker соответственно. Администраторам будет проще поддерживать одну политику, вместо двух. Плюс, правила сертификатов в SRP могут вносить негативный эффект в правила AppLocker'а. Хоть и заявляется, что если AppLocker включен, SRP будет игнорироваться системой, но запреты по правилам сертификатам будут перекрывать соответствующие разрешения в AppLocker'е. Это вызовет в свою очередь проблему планирования правил, чтобы грамотно создать правило в SRP и AppLocker'е и чтобы не наткнуться на подводный камень.

Вывод: так какое же место в этой жизни уготовано для AppLocker? Я считаю, что это только терминальные сервера или фермы терминальных серверов, где AppLocker показывает явное преимущество. А так же тот небольшой кусочек домашнего сектора, где возможно использование AppLocker'а. В остальных случаях практического использования, AppLocker является нецелесообразным и неэффективным. Возможно в следующем поколении Windows (или через поколение) что-то изменится, но сейчас дела обстоят примерно таким образом.

Но учитывая, что процент использования SRP по отношению к общему количеству инсталляций Windows XP/Vista/7/Server 2003/Server 2008/Server2008 R2 (видали, какой список ОС поддерживает SRP? :-)) очень ничтожный, то процент использования AppLocker'а — вообще круглый ноль и можно сказать, что МС просто выкинул деньги на ветер, вложив их в разработку AppLocker'а.