Публикация инфраструктуры открытых ключей с помощью ISA Server 2004 (часть 2)

Опубликовано: 11 Апреля, 2023

Это вторая часть статьи, состоящей из трех частей, которая представляет собой пошаговое руководство по созданию инфраструктуры открытых ключей (PKI) и использованию ISA Server 2004 для реализации некоторых часто упускаемых из виду, но важных функций сертификатов. В части 1 была подготовлена подготовительная работа для создания PKI.

Введение

Каждый центр сертификации (CA) имеет свой собственный сертификат для его уникальной идентификации. Инфраструктура открытых ключей, представляющая собой набор из одного или нескольких ЦС, имеет «корневой» ЦС, управляющий всеми остальными. Корневой сервер накладывает эти полномочия на любого «подчиненного», используя свой сертификат для клеймения или подписи сертификата, который должен быть связан с этим подчиненным. Этот клеймо является математической меткой, которая может быть создана только рассматриваемым корнем, и клеймо нельзя подделать, не обнаружив. Корневой ЦС подписывает свой собственный сертификат, потому что ему больше некому это сделать.

Если клиент «доверяет» корневому сертификату, он также доверяет любому сертификату с его подписью. Это также означает, что любой ЦС, сертификат которого подписан этим корнем, также может выдавать доверенные сертификаты: доверие корневого ЦС передается по всей цепочке ЦС.

Корневой ЦС должен подписывать только сертификаты подчиненных ЦС и делегировать роль подписи любых других сертификатов этим подчиненным. Многие не беспокоятся об этой иерархической структуре PKI и позволяют корневому центру сертификации выдавать все сертификаты. Вот пара доводов в пользу того, чтобы этого не делать:

Простота: вам может понадобиться другой выдающий ЦС для другого местоположения или проекта разработки, или, возможно, вы просто испортили свой текущий выдающий ЦС! Вы можете создать еще один корневой ЦС, но это означает, что эти сертификаты корневого ЦС будут доставлены пользователям, а затем удалены, и… ааа, это просто беспорядок! Но всегда найдутся те, кто прекрасно уживется в виртуальной мусорной корзине, полной специализированных корневых ЦС.
Безопасность: оставьте корневой ЦС рядом, и у кого-то может возникнуть соблазн найти способ украсть закрытый ключ этого корневого ЦС. Теперь они могут создавать сертификаты для злонамеренных целей. Если корневой ЦС скомпрометирован, ни одному из ваших сертификатов нельзя доверять. Для некоторых это маловероятный сценарий; другие так не подумают.

В этом руководстве демонстрируется двухуровневая PKI, состоящая из выдающего ЦС и его корневого ЦС.

Создание корневого ЦС

Большим недостатком отдельного корневого ЦС является дополнительное оборудование и лицензирование Windows. Вы можете установить корневой ЦС на существующий работающий сервер, но у вас не будет возможности изолировать, отключить и заблокировать корневой ЦС. Меры экономии могут включать схемы с архивированием или, возможно, технологии виртуальных серверов. Старая лицензия Windows 2000 может оказаться полезной, потому что корневой ЦС Windows 2000 будет работать нормально.

При установке операционной системы для вашего корневого центра сертификации необходимо помнить несколько моментов:

Сервер корневого ЦС не обязательно должен быть членом какого-либо из ваших доменов AD. Если вы собираетесь отключать его на несколько недель, он не должен быть членом домена.
Сервер корневого ЦС вообще не нуждается в сетевом подключении, и те, кто заботится о безопасности, никогда этого не допустят.

Этапы подготовки

Некоторые параметры ЦС невозможно настроить во время обычной установки, и их необходимо указать в текстовом файле с именем «CAPOLICY.INF» в корневой папке системы («C:WINDOWS» для большинства из нас). Используя текстовый редактор по вашему выбору, создайте этот файл со следующим содержимым:

[Версия]
Подпись=”$Windows NT$”
[CRLDistributionPoint]
Пусто = верно

Если вы хотите использовать Windows 2000, вам необходимо установить Service Pack 4, и формат будет другим:

[Версия]
Подпись=”$Windows NT$”
[Certsrv_Server]
RenewalKeyLength=2048
ПродлениеВалидитиПериод=20
RenewalValidityPeriodUnits=Годы
[Доступ к информации о полномочиях]
URL=””
[CRLDistributionPoint]
URL=””

Дополнительные строки связаны с тем, что Windows 2000 не предлагает эти параметры в мастере компонентов Windows. Эти дополнительные строки малоэффективны в Windows 2003, но если вы их включаете, имейте в виду, что записи «RenewalValidityPeriod» и «RenewalValidityPeriodUnits» неверны для Windows 2000!

Установка служб сертификации

С файлом CAPOLICY.INF, созданным в папке C:WINDOWS, откройте мастер компонентов Windows (из «Установка и удаление программ» на панели управления).

фигура 1

Установите флажок «Сертификационные службы». Это предупреждение появляется:

фигура 2

Нажмите «Да», а затем нажмите «Далее».

Изменение имени или членства в домене автономного сервера ЦС

Предупреждение - ложь! Наш корневой сервер ЦС должен быть автономным ЦС без ссылок на Active Directory. На самом деле вы можете сделать резервную копию базы данных ЦС, удалить службы сертификации, переименовать сервер, присоединиться к домену или выйти из него, переустановить службы сертификации, восстановить резервную копию, перенастроить, и все будет работать нормально. Однако это маловероятный маневр, и не пытайтесьЦС предприятия.

Рисунок 3

Мы устанавливаем автономный корневой ЦС, а также устанавливаем флажок «Использовать пользовательские настройки» и нажимаем «Далее». Примечание. «Enterprise CA» не подходит для этого сервера, не относящегося к домену.

Рисунок 4

На этой странице можно оставить значения по умолчанию, но общепринятой практикой является использование большей длины ключа для корневого ЦС, скажем, 4096 бит: Однако имейте в виду, что длина ключа больше 2048 бит по умолчанию означает, что используйте сертификаты из вашей PKI с оборудованием Cisco и, возможно, с некоторыми другими сетевыми устройствами. Нажмите «Далее».

Рисунок 5

На этой странице введите подходящее общее имя. Суффикс отличительного имени вводится со всевозможными кричащими строками в стиле X.500 для предположительного создания уникального отличительного имени или DN (например, «OU=MyBusinessUnit,O=MyOrganisation»). Его важность будет потеряна для большинства из нас, поэтому оставьте это поле пустым, если хотите. Измените срок действия с пяти лет на что-то большее, потому что вы никогда не захотите обновлять полученный сертификат; 20 лет должны сделать свое дело. Нажмите «Далее».

Срок действия корневого ЦС

Существует небольшой риск для безопасности в том, что сертификаты действительны в течение такого длительного периода, хотя взлом 4096-битного закрытого ключа за это время в настоящее время непонятен. Но кто знает, что принесет будущее: если вас преследуют теории заговора и общая крайняя паранойя, что ж, выберите что-то меньшее (хотя вы, вероятно, все равно думаете, что все PKI небезопасны).

Рисунок 6

Ничего из этого менять не нужно; просто нажмите Далее.

Мастер выполнит настройку компонентов и остановится со следующим предупреждением, если вы не установили IIS:

Рисунок 7

Это хорошо; ваш корневой сервер ЦС лучше не подключать к сети, так какой смысл в веб-регистрации! Просто нажмите ОК. Мастер завершит установку и представит диалоговое окно «Завершено»: Нажмите «Готово».

Если вы решите использовать Windows 2000 с пакетом обновления 4 (SP4) в качестве корневого ЦС, действия будут очень похожими, но с меньшим количеством параметров (например, сроком действия). Вы будете полагаться на все эти другие настройки в файле CAPOLICY.INF, чтобы заполнить пробелы.

Настройка служб сертификации

Первый шаг к настройке нашего нового ЦС включает в себя небольшую работу с реестром. По умолчанию автономный ЦС Windows создает сертификаты из запросов, срок действия которых составляет всего один год. Это не всегда приемлемо, когда сертификаты предназначены для подчиненных (выдающих) ЦС. Запустите REGEDIT и перейдите к:

HKLMSYSTEMCurrentControlSetServicesCertSvcConfiguration Имя вашего ЦС

Рисунок 8

Найдите значение REG_DWORD с именем ValidityPeriodUnits и измените его на подходящее значение ( 5 будет разумным). Значение ValidityPeriod по умолчанию — «Годы».

Если вы используете Windows 2003, вы можете не использовать REGEDIT и вместо этого запустить следующие командные строки:

certutil -setreg caValidityPeriodUnits «5»
certutil -setreg caValidityPeriod «Годы»

Срок действия подчиненного ЦС

Не считайте, что этот срок действия установлен постоянно. Вы можете решить создать подчиненный ЦС для конкретного проекта, который будет завершен через три месяца. В таких случаях вы можете временно изменить эти параметры реестра и перезапустить службы сертификации. ЦС никогда не будет выдавать сертификаты, срок действия которых превышает срок действия его собственного сертификата, поэтому это позволяет создавать подчиненные ЦС, специально предназначенные для этой работы.

После этого найдите консоль центра сертификации среди инструментов администрирования.

Рисунок 9

Щелкните правой кнопкой мыши имя центра сертификации на левой панели и выберите «Свойства».

Рисунок 10

Страница «Свойства» открывается на странице «Общие», и здесь вы можете просмотреть сертификат своего ЦС (обратите внимание, что на странице сведений параметр «Точки распространения CRL» отсутствует из-за используемого нами файла CAPOLICY.INF). Наш реальный интерес лежит на странице расширений, так что нажмите на нее.

Ни одна из записей по умолчанию в разделе «Укажите местоположения, из которых пользователи могут получить список отзыва сертификатов» не подходит для нашей цели: этот сервер не является членом домена, поэтому запись LDAP будет содержать неверные данные; сервер находится в автономном режиме, поэтому записи HTTP и FILE не будут указывать ни на что доступное, и все записи используют имя файла, которое слишком сложно для этой цели. Сначала запишите путь в первой записи, затем выделите каждый по очереди, нажмите кнопку «Удалить» и подтвердите удаление.

Теперь нажмите Добавить.

Рисунок 11

Введите локальную точку распространения, где службы сертификации могут сохранить список отзыва сертификатов с соответствующим именем. Вы можете использовать расположение по умолчанию с путем, который вы указали выше, вместе с подходящим именем файла (я использую аббревиатуру имени ЦС и избегаю пробелов). Запись будет иметь аналогичный формат:

C:WINDOWSsystem32CertSrvCertEnrollCompany1RootCA.crl

Нажмите ОК. Вы можете использовать здесь переменные, если хотите, но это приведет к неожиданному поведению. Обратите внимание на примеры HTTP, представленные в разделе « Описание выбранной переменной»: все эти переменные, следующие за «<CaName>», не только не подходят для местоположения HTTP; они также могут помешать отображению местоположения в выданных вами сертификатах!

Рисунок 12

Установите флажок «Опубликовать CRL в этом расположении» и снова нажмите «Добавить ».

Рисунок 13

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

ldap:///CN=<CATruncatedName>,CN=ROOTCA,CN=CDP,CN=Службы открытых ключей,CN=Services,CN=Configuration,DC=company1,DC=local<CDPObjectClass>

Компоненты домена (DC) здесь предназначены для «company1.local»; вы должны ввести значения из своего собственного доменного имени AD. Обратите внимание, что есть три косых черты.

Строго говоря, вы должны использовать переменную «<CATruncatedName>», чтобы вставить «продезинфицированное» имя ЦС. Если вы не использовали большое имя ЦС, это усеченное имя будет таким же, как и полное имя ЦС.

В этом примере явно используется строка «CN=ROOTCA», которая в данном случае является именем сервера. Остерегайтесь использовать здесь 'CN=<ServerShortName>'; это может вызвать путаницу, если вы когда-нибудь опрометчиво последуете моим предыдущим комментариям о переименовании сервера ЦС! Используйте «ROOTCA» или другое имя; это не обязательно должно быть имя сервера для автономного центра сертификации.

Щелкните OK, но не устанавливайте никакие флажки для этой записи. Нажмите Добавить еще раз.

Использование Active Directory для точек распространения CRL

В этой статье мы будем использовать только точку распространения HTTP, которая вполне подходит и имеет смысл, когда сертификаты должны использоваться извне. Так зачем настраивать расположение LDAP? Ваш корневой ЦС не хочет ограничиваться разовой работой; он должен быть в состоянии обслуживать многие, если не все ваши потребности PKI. Возможно, вы решили создать ЦС исключительно для внутреннего использования и хотите использовать AD в качестве точки распространения. Когда эта запись уже есть, вам нужно только установить флажок Включить в расширение CDP выданных сертификатов, перезапустить службу и выдать сертификат ЦС.

Вы можете установить флажок «Включить во все CRL …» и сохранить часть ввода при публикации CRL в AD (мы сделаем это в части 3), но лично я бы избегал наличия какой-либо информации AD в CRL, которая в конечном итоге будет доступна для просмотра на Интернет. Никогда не устанавливайте флажок Публиковать списки отзыва сертификатов в этом расположении на автономном сервере.

Рисунок 14

В поле «Расположение» введите URL-адрес выбранной вами точки распространения HTTP (из части 1) вместе с именем файла, которое вы уже использовали в предыдущей записи. Например:

http://certificates.company1.local/Company1RootCA.crl

Нажмите ОК. Если вы используете более одной точки распространения HTTP, добавьте и их.

Рисунок 15

Установите флажок Включить в расширение CDP выданных сертификатов для записи HTTP.

Если вы решили подключить этот сервер к сети (не рекомендуется), вы можете добавить запись ФАЙЛ, чтобы сохранить часть ручного копирования файлов, которые будут появляться. Это будет подробно описано для подчиненного (выдающего) ЦС в Части 3.

В раскрывающемся списке «Выбрать расширение» выберите «Доступ к авторитетной информации (AIA)».

Рисунок 16

Что касается CDP, удалите записи по умолчанию, но на этот раз нет смысла изменять первую запись ( C:WINDOWS… ), поэтому вы можете сохранить ее. Нажмите «Добавить» и введите запись LDAP, как вы это делали для местоположений CDP, но на этот раз сделайте ее похожей на:

ldap:///CN=<CATruncatedName>,CN=AIA,CN=Службы открытых ключей,CN=Services,CN=Configuration,DC=company1,DC=local<CDPObjectClass>

Используйте свое собственное доменное имя AD для этих битов DC! Нажмите ОК.

Использование Active Directory для доступа к авторитетной информации

Как и в случае с CDP, я включил здесь запись LDAP исключительно для предвидения, и она не будет использоваться для целей этой статьи. Установите флажок Включить в расширение AIA выданных сертификатов и перезапустите службу перед выдачей сертификата ЦС для ЦС, который будет использоваться только в домене AD.

Нажмите «Добавить» еще раз и введите запись HTTP, соответствующую выбранному URL-адресу. В этом примере я использовал:

http://certificates.company1.local/Company1RootCA.crt

Опять же, избегайте этих переменных здесь, иначе вы можете столкнуться с некоторыми неожиданными проблемами.

Рисунок 17

Установите флажок Включить в расширение AIA выданных сертификатов для нашего местоположения HTTP и убедитесь, что все флажки сняты для местоположения LDAP. Теперь нажмите «ОК», а затем нажмите «Да» в ответ на приглашение перезапустить службу.

Обратите внимание на параметр OCSP на этом листе свойств; мы упомянем об этом чуть позже.

Рисунок 18

Теперь щелкните правой кнопкой мыши папку Revoked Certificates и выберите «Свойства».

Рисунок 19

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

Дилемма интервала публикации CRL для автономного корневого ЦС

Прежде чем будет готов новый список отзыва сертификатов, вам придется вручную создать новый список отзыва сертификатов, а затем скопировать его в свои точки распространения (описано ниже). Это надоедливая работа, о которой нельзя забывать, поэтому возникает соблазн установить очень большой интервал публикации. Но если вам затем потребуется отозвать сертификат подчиненного ЦС, скажем, из-за того, что он скомпрометирован (маловероятно, но вы никогда не знаете), вы не можете немедленно применить это, потому что клиенты кэшируют CRL на период их действия. Вы должны достичь приемлемого компромисса при выборе интервала публикации, и это неизбежное ограничение механизма CRL.

Есть лучший способ: «Протокол статуса онлайн-сертификата» (OCSP) — это многообещающий метод, позволяющий избежать проблем с CRL. Существует опция OCSP при настройке AIA ЦС, а «CryptoAPI» на клиентах Windows можно легко расширить для поддержки OCSP. Но найти программное обеспечение «ответчик OCSP» для работы с вашей PKI не так-то просто.

Управление корневым ЦС, сертификатом ЦС и списками отзыва сертификатов

Вернувшись в консоль центра сертификации, снова щелкните правой кнопкой мыши папку Revoked Certificates и на этот раз выберите All Tasks and Publish.

Рисунок 20

Нажмите OK, и новый CRL будет создан в папке по умолчанию C:WINDOWSsystem32CertSrvCertEnroll. Теперь откройте проводник и перейдите в это место.

Рисунок 21

Скопируйте файлы «CRL» и «CRT» на носитель, который можно будет перенести на ваши онлайн-серверы (дискета, флешка или что-то еще). Переименуйте скопированный файл crt в соответствии с настроенным вами расположением HTTP AIA, которое в этом примере будет Company1RootCA.crt. Старый список отзыва сертификатов был создан до перенастройки точек распространения отзыва сертификатов, и его можно безопасно удалить.

Перенесите этот носитель на сервер, где вы создали общую папку ранее в Части 1, и скопируйте файлы CRL и CRT в эту папку. В части 3 мы обсудим, как мы будем публиковать эти файлы в AD.

Распространение корневого сертификата ЦС с помощью групповой политики

Этот шаг гарантирует, что все в вашем домене будут доверять вашему новому корневому ЦС. Этот шаг изменяет объект групповой политики (GPO) политики домена по умолчанию, и Microsoft рекомендует всегда создавать его резервную копию перед такими изменениями.

Войдите на контроллер домена с правами администратора. Среди инструментов администрирования найдите и откройте политику безопасности домена.

В разделе «Параметры безопасности» на левой панели разверните «Политики открытых ключей» и щелкните правой кнопкой мыши «Доверенные корневые центры сертификации». Выберите Импорт из меню. Откроется мастер импорта сертификатов:

Нажмите «Далее» на странице приветствия, а на следующей странице перейдите к общей папке, в которую вы скопировали сертификат корневого центра сертификации. Нажмите «Далее».

Рисунок 22

Щелкните Далее, чтобы перейти на следующую страницу (вы не можете изменить расположение хранилища сертификатов).
Нажмите «Готово» и подтвердите успешный импорт.

Рисунок 23

Если у вас есть несколько доменов, к которым применяется этот сертификат, повторите процесс на контроллерах домена в этих доменах.

Поддержание корневого ЦС

Теперь корневой ЦС готов выдать свой первый сертификат подчиненному ЦС. Между тем, если вы следовали рекомендациям, этот ЦС находится в автономном режиме (не подключен к сети), поэтому вы можете также закрыть его и выключить!

Вам необходимо защитить свой корневой ЦС как для безопасности, так и для того, чтобы не потерять его из-за аппаратного сбоя. Закройте его или храните в защищенной серверной комнате. Прежде чем сделать это, убедитесь, что у вас есть резервная копия по крайней мере базы данных центра сертификации и закрытого ключа (в консоли центра сертификации щелкните правой кнопкой мыши имя центра сертификации и выберите «Все задачи и резервное копирование центра сертификации »). Храните резервные копии так же надежно, как и сам сервер. Делайте резервные копии после выпуска любых новых сертификатов и после публикации нового CRL.

По мере приближения окончания «интервала публикации CRL» вам нужно будет посетить корневой центр сертификации, вручную опубликовать новый CRL, как описано выше, и перенести копию нового файла «crl» в свои точки публикации.

Вывод

Сейчас мы на полпути к созданию PKI для использования с ISA Server в сценарии с выходом в Интернет. Часть 3 посвящена созданию подчиненного ЦС.

Приложение

Ниже приведен список тех переменных, которые используются при создании местоположений. Некоторые из них не подходят, особенно для автономных ЦС, остальные, вероятно, не экономят труд, а некоторые вызовут всевозможные проблемы, если их использовать не в том месте! Я рекомендую не использовать их без крайней необходимости, хотя одна или две все же найдут применение в части 3 этой статьи.

CAName
Название центра сертификации.

CAObjectClass
Идентификатор класса объекта для центра сертификации, используемый при публикации на URL-адресе LDAP.

CATruncatedName
Имя центра сертификации, усеченное до 32 символов с решеткой на конце!

CDPObjectClass
Идентификатор класса объектов для точек распространения CRL, используемый при публикации на URL-адресе LDAP.

Имя Сертификата
Продление продления центра сертификации.

КонфигурацияКонтейнер
Расположение контейнера конфигурации в Active Directory.

CRLNameSuffix
Вставляет суффикс имени в конце имени файла при публикации CRL в файле или URL-адресе.

DeltaCRLAllowed
При публикации разностного CRL CRLNameSuffix заменяется отдельным суффиксом, чтобы отличать разностный CRL.

DNSName сервера
DNS-имя сервера центра сертификации.

Короткое имя сервера
NetBIOS-имя сервера центра сертификации.

Кибер-безопасность