В разных интернетах разные пользователи доставляют разные заблуждения на тему PKI. Это вполне нормальное поведение для тех, кто не является специалистом в этой области. Но ненормальное для пользователей претендующих на это звание. Сегодня на повестке дня 3 вопроса:

• Standalone CA и шаблоны сертификатов;
• тайна самоподписанных сертификатов EFS;
• сертификаты на кластере NLB.

Standalone CA и шаблоны сертификатов

Вчера в одном блоге вычитал утверждение, что Standalone CA может использовать шаблоны сертификатов. На самом деле это не так. Standalone CA выгодно отличается от Enterprise, что ему не нужны шаблоны. Совсем. Он собирает сертификат из той информации, которая хранится в запросе сертификата. Если в оснастке certsrv.msc у Enterprise CA есть секция Certificate Templates, то у Standalone CA её нет:

вот, есть Revoked, Issued certificates, Pending, Failed Requests, но никакого Certificate Templates, так что использовать их в такой ситуации нельзя.

Тайна самоподписанных сертификатов EFS

Я думаю, что многие шифровали файлы в системе простым, автоматически сгенерированным системой сертификатом. Находится он в оснастке certmgr.msc, контейнере Personal и выглядит примерно так:

Как мы видим, это самоподписанный сертификат, у которого Issuer и Subject одинаковые и соответствуют имени текущего пользователя. Срок действия — 100 лет. Всем известно, чтобы сертификат был доверенный, корневой сертификат из его цепочки (или он сам, если это самоподписанный сертификат) должен находиться в контейнере Trusted Root CA. Но в случае с этим сертификатом EFS такое не наблюдается. И вчера в том же самом блоге узнал, что этот самоподписанный сертификат какой-то волшебный и на него не распространяются правила доверия.

Но на самом деле всё гораздо интересней. PKI — технология очень железная с не менее железной логикой и всё в ней подчиняется простым принципам. Это делает PKI весьма надёжной и непробиваемой. Но давайте вернёмся к нашим баранамсампоподписанным сертификатам EFS. На самом деле его копия тоже установлена в контейнере, который делает сертификаты доверенными. И имя ему Trusted People:

Если удалить ваш сертификат из контейнера Trusted People, он станет недоверенным и мы будем горько плакать по этому поводу. Вот что говорят об этом технеты:

Trusted People (TrustedPeople) — This container keeps certificates issued to people or end entities that are explicitly trusted. Most often, these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook. To share an EFS–encrypted file with other parties, you must have their certificate in this store.

Иными словами, контейнер Trusted People своего рода аналог контейнера Trusted Root CAs, но только для пользовательских сертификатов.

Сертификаты на кластере NLB

Предположим, у вас кластер NLB, который несёт роль веб-сервера. Зачастую там будет какой-нибудь HTTPS, которому нужны сертификаты. Бытует весьма устойчивое мнение, будто бы сертификат SSL должен быть одинаковый на всех узлах кластера, иначе что-то не будет работать при отказе какого-то узла. В действительности это тоже весьма далеко от истины. Дело в том, что сессионные ключи не реплицируются между узлами кластера и каждый узел поддерживает свою сессию SSL c клиентом (это реально, когда клиент одновременно подключен к нескольким узлам кластера). И переключение с одного узла на второй (если один отказал) вызывает инициирование новой сессии SSL. Т.е. снова запрос сертификата сервера, проверка на доверие и отзыв, генерация сессии, сессионных ключей и всё остальное.

Следовательно, каждый узел кластера может поддерживать свой собственный сертификат SSL. И это, между прочим, является бест практисом (возможно проплаченный верисайном с тафтом). Бест практис в данном случае заключается в том, что каждый узел кластера запрашивает для себя свой сертификат и нет необходимости экспортировать ключи в PFX. Потому что когда люди копируют ключи в PFX защищая его простеньким паролем. Или сложным, но записывая пароль на бумажке, которая попадает нежелательному пользователю, ну а остальное вы знаете

На сегодня это всё.

Update 20.03.2011: исправлен синтаксис для INF

В различных интернетах ходит достаточно много слухов о правильности использования флага EDITF_ATTRIBUTESUBJECTALTNAME2. В общем смысле, администраторы включают этот флаг для выпуска сертификатов с расширением Subject Alternative Name без разбора и ссылаются на этот документ: http://support.microsoft.com/kb/931351. Но, как оказывается, мало кто осилил документ полностью.

Как видно из названия (ATTRIBUTE), этот флаг разрешает сабмитить запрос сертификата с атрибутом, содержащим расширение SAN. Этот атрибут можно добавить следующими способами:

• при использовании Web Enrollment Pages (Windows 2000 и Windows Server 2003) вы можете указать дополнительный атрибут с использованием примерно такого формата: san:dns=dns.name[&dns=dns.name];
• при использовании certreq и INF файла, который содержит строку следующего формата: san:dns=dns.name[&dns=dns.name] (такой же, как и в Web Enrollment Pages);
• при использовании certreq и сабмита уже готового файла запроса: certreq –submit –attrib:"san:dns=dns.name[&dns=dns.name]"

С одной стороны, вроде, и удобно, но это сильно небезопасно. Дело в том, что если флаг EDITF_ATTRIBUTESUBJECTALTNAME2 включен, любой пользователь можешь добавить атрибут SAN к своему запросу и получить нужный сертификат, даже если шаблон не разрешает использовать расширение SAN. Данный флаг можно включать только если CA сконфгирурирован на ручное одобрение каждого запроса администратором CA, который будет следить, чтобы ни один пользователь не подсунул «левый» SAN. Но в условиях энтерпрайза это малореально. Следовательно вы НЕ ДОЛЖНЫ включать этот флаг на Enterprise CA, если он настроен на автоматическую выдачу сертификатов без премодерации!

Но мы ведь хотим SAN, но не хотим включать этот флаг. Как тогда быть? Для этого мы (и вы тоже) должны использовать один из следующих методов:

• Сжечь Web Enrollment Pages и научиться пользоваться оснасткой Certificates (в Windows Vista и выше) для получения сертификата: Web server certificate enrollment with SAN extension (ха-ха, у меня там раньше тоже была сноска на включение этого флага, потому что сам заблуждался).
• Использовать новые возможности INF файла. Начиная с Windows Vista вы можете в INF файле указать расширение SAN в Base64 кодировке с использованием примерно следующего формата:
  [Extensions] 
  2.5.29.17 = "{text}"
  _continue_ = "dns=www01.fabrikam.com&"
• настроить шаблон на премодерацию и использовать вот такой скриптик для добавления расширения SAN в запрос: How to add FQDN to HP iLO request

HTH

Disclaimer: автор блога не несёт ответственности за содержание опубликованных внешних ссылок и гарантирует, что они были рабочие только на момент публикации статьи. Со временем они могут перестать работать по независящим от автора блога причинам. Прошу учитывать это.

Решил я тут провести небольшое исследование на предмет работы интернет-браузеров с цифровыми сертификатами — как серверными, так и клиентскими и ещё по мелочам. Откровенно говоря, домашним пользователям подобные вещи не нужны совершенно, а вот корпоративному пользователю они могут потребоваться. Результаты исследования стали для меня небольшой неожиданностью. Но будем двигаться попорядку. Для начала список испытуемых (наиболее актуальные версии на момент постинга):

1. Microsoft Internet Explorer 8;
2. Mozilla Firefox 3.6.12;
3. Opera 10.63;
4. Google Chrome 7.0.517.44;
5. Apple Safari 5.33.19.4.

Все браузеры проверялись на Windows 7 Enterprise x64. Что проверялось? А проверялось следующее:

• Legacy cryptography support

Под этим пунктом я понимаю просто поддержку SSL 3.0 и стандартных SSL сертификатов. Ничего специфичного. Вобщем-то это стандарт де-факто и все браузеры с этим пунктом полностью солидарны

• CNG Support

С выходом Windows Vista, Microsoft представил свою реализацию ассиметричных алгоритмов шифрования и генерации ключей под названием CNG (Cryptography Next Generation), в том числе с поддержкой ECC (Elliptic Curve Cryptography) и прочих стандартов. С момента выхода Windows Vista уже прошло ровно 3 года (конец 2007 года) и уже вышла следующая версия настольных Windows — Windows 7. Эти 2 системы всё шире и шире заполняют места в корпоративных сетях. Уже никого не удивишь сетью с системами под управлением только Windows Vista и выше. А, следовательно, уже приобретают актуальность SSL сертификаты с поддержкой CNG. Но все ли браузеры поддерживают их? Это тоже можно назвать баяном, но один браузер этот пункт провалил. Для меня было неожиданностью, что Opera ни в какую не хочет подключаться к сайтам с такими сертификатами.

• OCSP Support

Тоже стандарт де-факто 1999 года (RFC 2560). Ну за 11 лет браузеры как-то осилили 23-страничный RFC . Всё-таки, лучше потратить 2кб на запрос-ответ (а напомню, запрос весит примерно 70-100 байт, а ответ порядка 1,5кб), чем тратить мегабайты трафика (особенно на нешустрых мобильных каналах) на скачиваение CRL'ов. Вот один из таких пруфов:

• Offline revocation detection

Довольно важный момент, который многие пытаются игнорировать. Потому что это не всем по зубам настроить правильно и практической пользы от этого они (они — кто не смог настроить доступность проверки отзыва) не видят. А это очень неправильно, ведь может быть так, что сертификат давно отозван (например, украли ключи от сертификата), а мы об этом ничего не знаем, т.к. списки отзыва недоступны. Как правило браузеры игнорируют эту ошибку, когда CRL'ы и OCSP недоступны, но опционально можно включить предупреждение, что сервер отзыва недоступен. В IE это сделано очень готично — выводит жёлтую полоску в адрес-баре: IE7 & SSL. Про другие браузеры не знаю, но похожих опций в настройках не нашёл.

• Native Windows/Integrated Authentication

Весьма актуальный пункт для корпоративного сектора. Поскольку внутренние порталы (особенно на SharePoint) используют учётные записи Active Directory для разграничения прав доступа на элементы и страницы корпоративного веб-сайта с использованием Windows (или Integrated) Authentication. Без него пользователю пришлось бы каждый раз вводить свои логин и пароль для входа на сайт, что весьма уныло и очень раздражает. А если есть вот такая сквозная аутентификация, система сама пересылает учётные данные (как правило, билет кербероса, а не логин и пароль в чистом виде, как некоторые могли бы подумать) на сервер. Безусловно, раздавать свои учётные данные (хоть и шифрованные) всем подряд — не самая лучшая затея в этой жизни. Поэтому существует некоторый дополнительный механизм, который определяет, кому можно их пересылать или нет. IE использует зоны интернета для разделения сайтов. По умолчанию Internet Explorer'у разрешено пересылать учётные данные только тем сайтам, которые находятся в зоне Local Intranet. Как правило корпоративные порталы добавляются в эту зону администраторами через GPO. На одиночных станциях это настраивается в апплете Internet Options панели управления.

Бытует мнение, что только IE может использовать сквозную аутентификацию на вебе. Но это всё неправда, потому что Google Chrome тоже использует зоны интернета для определения, кому можно пересылать учётные данные.

• Custom Windows/Integrated Authentication implementation

Далеко не обязательно (хотя и рекомендуется) использовать стандартное (можно даже сказать системное) разделение сайтов по зонам для определения разрешения на пересылку учётных данных для аутентификации и браузеры могут использовать свою реализацию сквозной аутентификации на вебе. И Mozilla FireFox в данном случае является примером такой реализации. Вот ссылка на настройку Windows Authentication в FireFox: Firefox and Integrated Windows Authentication. Opera и Safari никаким образом не поддерживают сквозную аутентификацию и не имеют собственных реализаций.

• Client Certificate Authentication

Бывают в этой жизни такие ситуации, когда использование логина и пароля для доступа к веб-сайту очень небезопасно (особенно если на сайте хранится очень конфиденциальная информация). Для усиления аутентификации можно использовать пользовательские сертификаты. Пользователь просто предъявляет его и тем самым аутентифицируется на веб-сервере. Опять же, по умолчанию для поиска пользовательских сертификатов используется системное пользовательское хранилище сертификатов (certmgr.msc). Но это тоже не обязательно (хотя и рекомендуется) и можно сделать свою реализацию.

В принципе, эту функцию поддерживают (тем или иным образом) все браузеры. Однако, в Opera она не работает. Никак. Кнопки нужные есть, но они выдают ошибки и всё. Поэтому для Opera здесь ставим красный крестик.

• Windows Certificate Store support

Большинство приложений, использующих сертификаты, используют встроенное в Windows хранилище сертификатов для определения доверия и использования пользовательских сертификатов. Но в интернет-браузерах это не строгое условие, хотя очень полезное, т.к. ничего дополнительно настраивать не надо.

Internet Explorer (удивительно, да?), Google Chrome и Apple Safai используют стандартное хранилище сертификатов. Mozilla FireFox и Opera не поддерживают его никоим образом.

Примечание: однако, это вовсе не значит, что Chrome и Safari будут показывать зелёные полоски на вашем Extended Validation SSL сертификате. Т.е. если система доверяет вашему корневому сертификату (он установлен в контейнере Trusted Root CAs), Chrome и Safari будут ему доверять тоже. Но зелёнку (если она настроена для Internet Explorer) показывать не будут.

• Custom Certificate Store support

Т.к. использование стандартного хранилища сертификатов не обязательно для браузеров, Mozilla FireFox и Opera используют свои собственные хранилища для проверки доверия SSL сертификатам, а так же и для использования клиентских сертификатов для аутентификации на вебе. Поэтому если у вас используются внутренние сертификаты (выданые вашим собственным CA), скорее всего они не будут работать в этих браузерах и вам придётся их отдельно настраивать, чтобы эти браузеры доверяли вашим сертификатам. Что касается пользовательских сертификатов, то здесь придётся экспортировать сертификат из хранилища в PFX и импортировать в браузер. Это неудобно и вообще плохо.

Что касается Opera, этот браузер вообще как-то по-своему относится к сертификатам. Например, даже не показывает зелёнки (Extended Validation SSL) на тех сайтах, где остальные браузеры её показывают. Например, Opera до сих пор не показывает зелёнку на https://startssl.org.

• Native smart card support

Бывают в этой жизни и более тяжёлые случаи, когда пользователи не имеют логина и пароля для входа в систему и вообще для аутентификации в Active Directory. У них есть сертификат, но он не просто лежит в хранилище, а находится на защищённом криптоустройстве, называемом смарт-картой. Это уже из разряда многофакторной аутентификации, о которой я здесь рассказывать не буду, но этот вид аутентификации значительно надёжней комбинации логина и пароля, т.к. тут нужно знать не только PIN код от смарт-карты (а его можно и узнать при большом желании), но и иметь при себе саму смарт-карту. Для работы со смарт-картой в систему устанавливается её драйвер и криптопровайдер (Cryptographic Service Provider, CSP). Этот CSP так же встраивает себя в LSA (Local Security Authority), что позволяет приложениям легко обнаруживать смарт-карты для аутентификации, даже если приложение не обучено специально работать со смарт-картами. Для этого, разумеется, необходимо использовать системные API.

Вот эти самые системные API используют следующие браузеры: Internet Explorer (ну куда же без него ), Chrome и Safari. Как только вы установили драйвер для смарт-карты, эти браузеры уже готовы с ней работать. Просто, удобно и со вкусом.

• Custom smart card support

Mozilla FireFox и Opera не используют системные API для получения сведений о смарт-картах и в этих браузерах эту поддержку нужно включать вручную. Вот пример, как это делается в Mozilla FireFox на примере Aladdin eToken: eToken Settings for Mozilla-Firefox 3.5 (по ссылке документ PDF). Opera, к сожалению, смарт-карты не поддерживает ни в каком виде.

А теперь соберём это всё в аккуратненькую табличку:

	Internet Explorer	Mozilla FireFox	Opera	Google Chrome	Apple Safari
Legacy cryptography support
CNG Support
OCSP Support
Offline revocation detection
Native Windows/Integrated Authentication
Custom Windows/Integrated Authentication implementation	Not required			Not required
Client Certificate Authentication
Windows Certificate Store support
Custom Certificate Store support	Not required			Not required	Not required
Native smart card support
Custom smart card support	Not required			Not required	Not required

Какие выводы следуют из этого?

• Internet Explorer показал вполне очевидные результаты по обсуждаемым моментам.
• Mozilla FireFox показал себя жутким независимым индивидуалистом. Абсолютно все указанные функции реализованы внутри браузера, иногда даже в виде костылей. С одной стороны это делает его платформонезависимым, но с другой стороны значительно усложняет администрирование, поскольку придётся настраивать систему и отдельно браузер. Вобщем, вариант не очень подходящий.
• Opera — достаточно популярный браузер среди домашних пользователей, но совершенно не пригоден как корпоративный браузер. Вобщем, в recycle bin.
• Google Chrome. Что удивильно (всё же, приятно), что Google Chrome показал точно такие же результаты, как и Internet Explorer. А это значит, что в Google хорошо подготовились к возможному внедрению своего детища в корпоративный сектор. Этот браузер предельно максимально использует системные возможности Windows, чтобы не доставлять дополнительного головняка администраторам, которым, возможно, придётся его настраивать. Правда, это делает браузер платформозависимым, но это в данном случае соверешенно некритично. Вобщем годная альтернативна для замена IE (в разрезе обсуждаемых моментов).
• Apple Safari, вроде, всё выглядит очень прилично, но отсутствие какой-либо реализации Windows Authentication, портит всё впечатление. А ведь сквозная аутентификация — немаловажная фича для корпоративного браузера. Вобщем, можно оставить на перспективу после Chrome.

Вот, собственно говоря, и всё

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

На сервере 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 или названии целевой папки. Поэтому обращайте внимание на правильность указанных путей.

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