Недавно в интернете читал интересное обсуждение, в котором утверждалось, что самоподписанные сертификаты подвержены атаке Man-in-The-Middle (MiTM). Давайте разберёмся, что это такое. Есть 2 узла (А и Б). Узел А инициирует соединение с узлом Б отправляя запрос для предъявления сертификата (SSL). Узел Б посылает свой сертификат узлу А. И тут между узлами А и Б появляется узел В (злоумышленник), который перехватывает сертификат и вместо него отправляет свой поддельный сертификат. Узел А думает, что это сертификат узла Б и начинает шифровать этим сертификатом данные, передавая узлу Б. Но на самом деле узел А шифрует данные поддельным сертификатом узла В и злоумышленник читает все шифрованные (а это могут быть и конфиденциальные данные) данные.

Я не берусь судить, откуда растут ноги у этого мифа, но он достаточно устойчив. Давайте посмотрим существующие алгоритмы шифрования:

• Симметричное шифрование

Самый простой, но и небезопасный метод:

1. John Smith хочет безопасно отправить конфиденциальные данные Mary Jane.
2. John генерирует симметричный ключ и шифрует им документ. Документ теперь зашифрован и может быть передан через интернет.
3. Mary Jane получает зашифрованный документ.
4. Mary Jane применяет *тот же самый* симметричный ключ и получает текст в незашифрованной форме.

Минус такого сценария заключается в том, что используется один и тот же ключ как для шифрования и дешифрования. Следовательно, чтобы Mary Jane смогла расшифровать данные ей нужно иметь тот же самый ключ. Этот ключ не должен передаваться вместе с документом, а какими-нибудь другими методами (например, по телефону). Чем больше получателей этого документа, тем выше вероятность, что ключ станет известен ещё кому-то и не существует механизмов, которые бы позволяли определять статус ключа (скомпрометирован или нет). Плюс такого сценария — высокая скорость. Симметричное шифрование выполняется достаточно быстро и не потребляет большого количества процессорных ресурсов. Идеально подходит для шифрования больших объёмов данных.

• Асимметричное шифрование

Метод более сложный, но и более безопасный:

1. John Smith хочет отправить конфиденциальные данные Mary Jane.
2. John использует открытую часть сертификата (с открытым ключом) Mary Jane и этим открытым ключом шифрует данные.
3. Mary Jane получает зашифрованный документ.
4. Mary Jane применяет *закрытый ключ* от своего сертификата и расшифровывает данные.

В нашем сценарии Mary Jane — это веб-сервер, которому нужно передать конфиденциальные данные. А John Smith — клиент, который хочет эти данные передать на сервер. Чисто технически злоумышленник может перехватить открытую часть сертификата Mary Jane и вместо него подложить свой поддельный сертификат с таким же именем. Без дополнительных мер безопасности, John не смог бы отличить настоящий сертификат от поддельного. И здесь появляется важный момент. Перед шифрованием данных John Smith должен проверить этот сертификат на доверие и отзыв. Сертификаты содержат различные средства определения статуса закрытого ключа через списки отзыва. Если сертификат помещён в список отзыва, ему доверять нельзя и использовать его крайне опасно. В случае с самоподписанными сертификатами определить отзыв не представляется возможным. Но можно (как минимум) убедиться, что сертификат выпущен доверенным лицом (или центром сертификации). Для этого John Smith пропускает сертификат через Certificate Chaining Engine (CCE). Если издатель сертификата (или сам сертификат) хранится у John'а в Trusted Root CAs, можно с уверенностью сказать, что сертификат не был подделан злоумышленником и выдан доверенным лицом. Если же сертификата там нет, невозможно убедиться, что это действительно сертификат самой Mary Jane. В таком случае приложение выдаёт ошибку или предупреждение, что не удалось проверить сертификат. Когда пользователь получил такое предупреждение, он должен незамедлительно отменить операцию шифрования (если это ещё не сделало само приложение).

Поскольку закрытый ключ от сертификата хранится только у Mary Jane и он никогда не раскрывается никому, злоумышленнику бесполезно использовать перехваченные пакеты, поскольку закрытый ключ (который нужен для расшифровки данных) никогда не покидает Mary Jane. Хотя тут есть 2 момента. Поскольку самоподписанные сертификаты не имеют централизованного издателя, при большом количестве таких сертификатов появляется вопрос доверия к таким сертификатам:

1. Самое простое — игнорировать ворненги ошибок сертификатов. В таком случае можно надурить отправителя и подсунуть поддельный и недоверенный сертификат. Если вы игнорируете ворненги — вы ССЗБ. Против этого метода защиты не существует.
2. Чуть сложнее — все сертификаты участников обмена шифрованными данными устанавливать в Trusted Root CAs. Тогда ворненгов и не будет. Но при большом количестве таких сертификатов можно ошибочно установить поддельный сертификат к себе в хранилище. И тогда вы будете доверять сертификату злоумышленника.

Следовательно, чисто технически очень сложно организовать атаку MiTM даже с самоподписанными сертификатами. Единственное на что можно рассчитывать — на человеческий фактор. А против человеческого фактора защиты нет никакой. Разве что его можно попытаться снизить за счёт использования централизованного доверенного издателя (центр сертификации). В таком случае придётся установить только один корневой сертификат в Trusted Root CAs. И если сертификат у какого-то участника обмена ВНЕЗАПНО стал недоверенным, можно с определённой уверенностью сказать, что это поддельный сертификат. Но, как я уже отмечал, оба вышеупомянутых пункта относятся как к самоподписанным сертификатам, так и к сертификатам выпущенных централизованным издателем.

Примечание: данный пост содержит сведения об изменении настроек Active Directory и Certification Authority и автор ещё раз обращает ваше внимание на дисклаймер данного блога.

---

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

• параллельно устанавливают ещё один CA и удаляют старый. При этом сертификаты предыдущего CA не поддерживаются и просто выводятся из обращения (как правило с ними ничего не происходит, а только перестают работать, поскольку CA больше не публикует CRL'ы и проверки таких сертификатов проваливаются). Такой метод применяют, когда количество сертификатов выданных прежним CA невелико и им можно пренебречь и переиздать сертификаты.
• параллельно устанавливается ещё один CA, делают кросс-сертификацию старого CA и удаляют его. При этом сертификаты предыдущего CA поддерживаются и используются в работе. В виду отсутствия предыдущего CA, необходимо дополнительно обеспечить успешную валидацию всех ранее выданных сертификатов.

Если первый метод достаточно прост и тривиален, второй уже требует дополнительных действий со стороны администратора. Это публикация CRL при фактическом отсутствии упразднённого CA и поддержание CRT файлов для построения цепочек сертификатов. И в данном случае старая PKI будет частью новой PKI за счёт кросс-сертификации. Для начала нужно рассмотреть что такое кросс-сертификация. Кросс-сертификация — процесс заверения одной иерархией PKI другой иерархии PKI. При этом заверенная PKI будет являться частью завереямой PKI. Рассмотрим простой пример:

Имеется иерархия CA из корневого Contoso-CA1 и подчинённого Contoso-CA2. Вы создаёте новую иерархию, состоящую из Adatum-CA1 и Adatum-CA2. При этом вы можете сделать кросс-сертификацию между Adatum-CA2 и Contoso-CA1 или Contoso-CA2:

В первом случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
        Adatum-CA2
                Contoso-CA1
                        Contoso-CA2
                                EndCert

Как видите, клиент не должен явно доверять Contoso-CA1, а только Adatum-CA1. За счёт кросс-сертификации цепочка будет начинаться в иерархии Contoso и заканчиваться в иерархии Adatum.

Во втором случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
        Adatum-CA2
                Contoso-CA2
                        EndCert

В принципе, можно сделать ещё и вот так:

В первом случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
        Contoso-CA1
                Contoso-CA2
                        EndCert

Во втором случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
       Contoso-CA2
               EndCert

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

В нашем случае мы создаём новую иерархию Adatum и постепенно избавляемся от Contoso. Важно учитывать, что демонтаж старых центров сертификации можно проводить только после полной настройки новой иерархии PKI.

Подготовка шаблонов сертификатов

1. Войдите в систему с правами Enterprise Admins.
2. Нажмите Start, Run… и введите 'MMC'. Если появится диалоговое окно UAC, подтвердите запуск консоли.
3. В меню File нажмите Add/Remove Snap-ins.
4. В списке выберите Certificate Templates, нажмите Add и нажмите Ok для завершения операции.
5. В открывшейся оснастке найдите стандартный шаблон User. Нажмите правой кнопкой на нём и выберите Duplicate Template. Если появится запрос о выборе версии шаблона укажите Windows Server 2003 Enterprise и нажмите Ok.
6. Во вкладке Properties of New Tamplate укажите новое название шаблона. Например, Cross-signing.
7. Снимите галочку с Publish certificate in Active Directory.
8. Во вкладке Request Handling можете указать другой CSP, если, например, хотите хранить сертификат на смарт-карте (рекомендуется).
9. В Issuance Requirements можете указать требование явного одобрения запроса со стороны администратора CA.
10. Во вкладке Extensions выделите Application Policies и нажмите Edit.
11. Удалите всё из списка, после чего нажмите Add и выберите Qualified Subordination. Нажмите Ok.
12. Во вкладке Security удалите всех из разрешений, кроме глобальной или универсальной группы, которой будет разрешено энролить сертификаты для подписи запросов кросс-сертификации.
13. Нажмите Ok для сохранения изменений и записи шаблона в Active Directory.

Теперь нужно добавить нужные шаблоны в выдачу на CA. Для этого:

1. Войдите на сервер CA с именем Adatum-CA2 с правами Enterprise Admins.
2. Нажмите Start, Administrative Tools и нажмите Certification Authority.
3. Выделите секцию Certificate Templates и в контекстном меню выберите New –> Certificate Template to issue.
4. В списке выделите только что созданный Cross-signing и Cross Certification Authority и нажмите Add.

Теперь запросите сертификат на основе шаблона Cross-signing. Этот сертификат вам потребуется для подписывания запросов сертификатов на основе шаблона Cross Certification Authority.

Создание кросс-сертификата

Кросс-сертификация — это весьма обширная тема. Для нашего сценария нет необходимости рассматривать подробности т.н. qualified subordination, поэтому ограничимся самым простым вариантов без дополнительных ограничений. Для этого создайте текстовый файл с именем Policy.inf и следующим содержанием:

[Version]
Signature = $WindowsNT$

[RequestAttributes]
CertificateTemplate = CrossCA

далее скопируйте сертификат CA Contoso-CA2 на локальный диск. Запустите командную строку и выполните следующую команду:

certreq –policy

В открывшемся диалоговом окне укажите файл сертификата Contoso-CA2 и нажмите Open. Во втором диалоговом окне укажите созданный файл policy.inf и нажмите Open. После чего появится окно выбора сертификата подписи. После указания сертификата подписи нажмите Ok и укажите путь размещения и имя запроса сертификата. После чего выполните следующую команду:

certreq –submit path\cross.req

где path\cross.req — путь размещения и имя файла запроса для кросс-сертификата. Если появилось диалоговое окно выбора сервера CA, выберите тот, в выдаче которого находится шаблон Cross Certification Authority и нажмите Ok.

1. Войдите на сервер CA с именем Adatum-CA2 с правами Enterprise Admins и администратора CA.
2. Нажмите Start, Administrative Tools и нажмите Certification Authority.
3. Выделите секцию Pending Requests, найдите в списке самый последний запрос и в контекстном меню выберите Issue. Предварительно вы можете убедиться, что запрос получился корректный и все данные в нём правильные.
4. Перейдите в секцию Issued Certificates, найдите самый последний сертификат (должен быть наш кросс-сертификат) и экспортируйте его в CER файл.

если открыть сертификат и посмотреть вкладку Certification path, можно увидеть, что цепочка этого сертификата заканчивается не на Contoso-CA1, а на Adatum-CA1. Следовательно, для данного сертификата доверие, да и наличие самого Contoso-CA1 уже не обязательно.

На данном этапе остался последний шаг — публикация кросс-сертификата в Active Directory. Для этого запустите командную строку с повышенными привилегиями (выбрав Run as administrator в контекстном меню значка Command Prompt) и выполните в ней следующую команду:

certutil –dspublish –f path\cross.cer

где path\cross.cer — путь размещения и имя файла кросс-сертификата.

Подготовка к демонтажу старых центров сертификации

Прежде чем демонтировать ненужные центры сертификации, необходимо переподписать все их CRL и поместить их в точки публикации CDP, например, LDAP и/или веб-сервер. Для этого вы должны зайти на каждый демонтируемый сервер CA и выполнить следующую команду:

cd c:\windows\system32\certsrv\certenroll\
certutil –sign .crl 1.crl now+1825:00
certutil –sign +.crl 1+.crl now+1825:00

Certutil –sign переподпишет старые CRL'ы с новым более долгим сроком, в нашем случае — на 5 лет. Т.е. эти CRL'ы будут действительны последующие 5 лет. Далее, вы должны скопировать эти CRL'ы в точки публикации. При этом следует удалить единички (которые были добавлены только для создания нового файла) из имён файлов, чтобы они совпадали с именами файлов в расширениях сертификатов.

Демонтаж старых центров сертификации

Демонтаж старых центров сертификации следует проводить в соответствии с этим руководством: How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000

Примечание: удалять следует только объекты относящиеся демонтируемым центрам сертификации. В противном случае вы можете удалить и объекты новых действующих CA.

Листая тематические форумы, рефералов бложика и переписку в почте, уже набралось немного вопросов, на которые нет смысла делать отдельный пост, но есть смысл вынести в очередной FAQ.

 

 

Q: Как узнать тип установленного на сервере Certification Authority?

A: тип Certification Authority можно узнать несколькими методами, которые обычно основываются на реестре:

HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CA Sanitized Name>

и запись типа REG_DWORD — CAType. И вот что означает каждое значение:

0 — Enterprise Root CA
1 — Enterprise Subordinate CA
3 — Standalone Root CA
4 — Standalone Subordinate CA
5 — Unknown

По большому счёту, если вы задаёте этот вопрос, значит, для вас этот тип — Unknown (5) :-)

Q: Может ли в домене/лесу Active Directory существовать 2 и более иерархий PKI с разными корневыми центрами сертификации?

A: да, вы можете в существующем домене/лесу развернуть несколько независимых иерархий PKI. Сервер CA не использует домен для захвата власти, а только лишь для обеспечения удобства распространения и выдачи сертификатов конечным потребителям.

Q: Можно ли мигрировать сервер CA с платформы x86 на x64? Судя по этой статье: http://support.microsoft.com/kb/298138, это невозможно. Как быть?

A: Сведения представленные в указанной статье не совсем достоверны. Технически бэкап БД выполненный на платформе x86 может быть успешно восстановлен на платформе x64 и каких-то проблем с этим возникнуть не должно. Поэтому вы можете смело планировать миграцию ваших серверов CA с x86 на x64, особенно если существующий CA работает на системе под управлением Windows 2000. В качестве руководства по миграции вы можете руководствоваться следующим вайтпепером: http://technet.microsoft.com/en-us/library/ee126170(WS.10).aspx

Q: Я зашифровал папку с файлами при помощи EFS, но пользователи всё равно могут просматривать содержимое папки? Что это, баг или данные просто не шифруются?

A: Это не баг, а нормальное поведение системы (при условии, что другие пользователи имеют права на просмотр содержимого каталога). Если посмотреть на файловую сисему изнутри, становится понятно, что папка — всего лишь логический контейнер и он хранится в MFT. Папка сама по себе не содержит в себе данных и не имеет размера. А сами данные, которые нужно шифровать находятся в другой части файловой системы. Поэтому если вы зашифровали папку средствами EFS, шифруются сами данные, но обзор списка файлов в шифрованной папке по прежнему разрешён.

Q: мне нужно издать сертификат с некоторыми данными в расширении Subject Alternative Name (SAN). Я создаю запрос с этим расширением, но CA игнорирует это расширение. Как быть?

A: по умолчанию Windows CA игнорирует это расширение в целях безопасности. Для включения этого расширения воспользуйтесь сведениями из этой статьи: http://support.microsoft.com/kb/931351

Q: для чего служат различные контейнеры в AD внутри контейнера Public Key Services?

A: эти контейнеры служат для обеспечения автоматизации работы центра сертификации, подачи запросов и проверки сертификатов.

• NTAuthCertificates — служит для хранения сертификатов центров сертификации, которым разрешено издавать логонные сертификаты (для смарт-карт, для аутентификации по сертификатам в VPN или IIS) для текущего леса. Например, вы используете сторонний центр сертификации, выдающий сертификаты для смарт-карт. Для того, чтобы контроллеры домена распознавали и доверяли этим сертификатам, сертификат стороннего CA должен быть добавлен в NTAuthCertificates. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Intermediate CAs.
• AIA — служит для хранения сертификатов центров сертификации. Сертификаты из этого контейнера используются для ускорения построения цепочек сертификатов при проверке. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Intermediate CAs.
• CDP — служит для хранения списков отзыва (Certificate Revocation List или CRL). Списки отзыва используются для определения статуса конкретного сертификата (отозван или не отозван). CRL'ы из этого контейнера не копируются клиентами. Поэтому CRL опубликованный в данном контейнере может быть использован только если расширение CDP какого-то сертификата явно ссылается на него.
• Certifiation Authorities — служит для хранения собственных или сторонних доверенных корневых центров сертификации. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Trusted Root CAs.
• KRA — служит для хранения выпущенных сертификатов агентов восстановления. Каждый выпущенный сертификат агент восстановления публикуется в этот контейнер в запись соответствующего CA. Важно понимать, что при назначении нового агента восстановления на сервере CA, содержимое данного контейнера не изменяется.
• Enrollment Services — служит для хранения записей и сертификатов всех Enterprise CA в текущем лесу. Клиенты используют этот контейнер для обнаружения Enterprise CA.
• OID — содержит все OID'ы зарегистрированные в вашей компании. В том числе  Issuance, Application Policies, Certificate Templates OID's.
• Certificate Templates — служит для хранения сведений о всех шаблонах сертификатов текущего леса.

Q: я создал шаблон версии 3 (Windows Server 2008 Enterprise Edition) для смарт-карт, но при энроллменте я получаю ошибку. В чём дело?

A: исторически CSP (Cryptography Service Provider) смарт-карт не поддерживают алгоритмы CNG (Cryptography New Generation), которые реализованы в шаблонах версии 3. Следовательно, вы не можете использовать шаблоны версии 3 для смарт-карт. Вместо этого вы должны использовать шаблоны версии 2 (Windows Server 2003 Enterprise Edition).

Q: я установил MS OCSP Responder, но папка веб-приложения пуста. Что должно быть в папке OCSP?

A: Имплементация OCSP в Windows основывается на ISAPI фиьтрах, реализованных в библиотеке ocspisapi.dll. Поэтому при создании веб-приложения OCSP путь к нему указывается как %systemroot%\SystemData\ocsp. В этой папке есть только папка aspnet_client, но файлов никаких нет. Их быть и не должно.

Короткая заметка.

Не всем нравится, когда CA в сертификаты пихает немного лишнюю и ненужную информацию. Особенно это касается сертификатов, используемых снаружи сети. Самое популярное «ненужное» расширение — Certificate Template Name и Template. Наружным пользователям (пользователи из интернета) знать названия и OID'ы ваших шаблонов совсем необязательно. Вот как можно отключить любое расширение:

certutil -setreg policy\DisableExtensionList +<Extension OID>

и включить обратно:

certutil -setreg policy\DisableExtensionList –<Extension OID>

и примеры:

certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.20.2
certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.21.7

Для включения расширения заменить плюсик на минусик, соответственно. OID'ы расширений можно найти здесь: http://msdn.microsoft.com/en-us/library/aa379367(VS.85).aspx

Примечание: после внесения изменений нужно перезапустить службу certsvc.

Однако, следует учитывать, что отключать расширения надо очень осторожно. Например, если ваш CA издаёт сертификаты через автоэнроллмент, нельзя отключать расширения Certificate Template Name и Template, поскольку эти расширения используются автоэнроллментом для обновления существующих сертификатов. Поэтому я придерживаюсь правила, по которому следует (по возможности) поднимать как минимум 2 сервера CA — для внутреннего и для внешнего использования. К сожалению это далеко не всегда возможно и чаще ограничиваются только одним сервером CA на все случаи жизни. Но если кто-то делает по бест-практисам, этот совет может очень даже пригодиться.

В этом посте я кратко изложу ссылки на посты, связанные с данным материалом.

• Устанавливаем Certification Authority (часть 1) — Введение

В первой части рассматриваются общие вопросы, связанные с необходимостью внедрения PKI и технические вопросы планирования. В частности обсуждаются схемы иерархий серверов CA, выбор типа CA для каждого уровня и прочие ключевые вопросы, необходимые для успешного внедрения PKI.

• Устанавливаем Certification Authority (часть 2) — Установка Offline Root CA

В данном посте содержатся технические характеристики, которым будет соответствовать корневой центр сертификации (Root Certification Authority) и пошаговый процесс установки и последующего конфигурирования роли AD CS (Active Directory Certificate Services). Также детально разбираются вопросы, которые могут возникнуть при установке роли AD CS.

• Устанавливаем Certification Authority (часть 3) — Установка Subordinate Issuing CA

Здась рассматриваются ключевые моменты, присущие центрам сертификации несущих роль Policy и Issuing CA. А так же подробное пошаговое руководство по установке подчинённого центра сертификации (Subordinate Certification Authority).

• Устанавливаем Certification Authority (часть 4) — Конфигурирование Subordinate Issuing CA

Заключительная часть цикла рассказывает об особенностях конфигурирования издающего центра сертификации в доменной среде. Так же здесь вы найдёте дополнительную информацию по увязке Online Certificate Status Protocol (OCSP) с нормально выключенным (Offline) центром сертификации.

HTH