Contents of this directory is archived and no longer updated.

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

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

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

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

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

HTH


Share this article:

Comments:

Альберт

Вопрос по выбору типа издающего CA. Нами разработано и запускается в опытную эксплуатацию web-приложение, предназначенное не для публичного доступа, а только для наших клиентов. Web-сервер с этим приложением расположен у нас. Планируется настроить этот сервер только на https и для доступа к нему вручную выдавать клиентам сертификаты на срок, определенный договором с ними. В настоящее время у нас нет домена. Все компьютеры, в т. ч. сервера, работают в рабочей группе. Можно ли для стоящей задачи развернуть PKI без создания домена в нашей организации, установив только Offline Standalone Root CA и Standalone Policy/Issuing CA?

Vadims Podāns

Нет, не получится без Active Directory, поскольку аутентификация смарт-картами — не самостоятельное решение, а надстройка над Kerberos. Поскольку Kerberos возможен только в доменной сети, вам будет нужен домен.

Альберт

Нет, Kerberos поверх HTTP не планируется. Планируется сертификатная аутентификация на нашем сайте. В настройках web-сервера IIS будут исключены все способы аутентификации, кроме SSL. Для сайта на этом сервере, на котором работает наше web-приложение, планируется создать и установить в него сертификат. А для доступа к этому сайту для каждого пользователя (нашего клиента) будем создавать персональные сертификаты пользователей, которые они должны будут установить в свой браузер, либо в eToken.

Альберт

Когда я говорил, что web-сервер с нашим web-приложением расположен у нас, имел в виду что он территориально находится в нашем офисе. Но при этом он выставлен в интернет. А клиенты наши территориально могут находиться где угодно, и будут пользоваться нашим web-приложением входя на наш сайт так же через интернет.

Vadims Podāns

> Для сайта на этом сервере, на котором работает наше web-приложение, планируется создать и установить в него сертификат. А для доступа к этому сайту для каждого пользователя (нашего клиента) будем создавать персональные сертификаты пользователей, которые они должны будут установить в свой браузер, либо в eToken. ок, пусть так, вы установите SSL сертификат на сервер для аутентификации сервера и выдадите пользователям клиентские сертификаты для аутентификации пользователей. но вы должны будете ответить на вопрос: как и с чем сервер будет сверять сертификаты пользователей? Вы не можете приаттачить пользовательские сертификаты в свойства локальных учётных записей. Можно только в свойства доменных учётных записей. Т.е. в рабочей группы отсутствует какой-либо механизм проверки пользовательских сертификатов. Следовательно, вам либо нужен домен, либо писать своё приложение, которое будет эмулировать функции контроллера домена на вашем веб-сервере (что представляется маловероятным).

Альберт

Сертификаты пользователей обязательно должны быть присоединены к учетным записям? Нет никакой возможности сделать так, чтобы сервер просто проверял сертификат на валидность (корневой CA доверенный, срок действия не истек, не отозван): сертификат действительный - одобрить подключение, не действительный - отклонить?

Vadims Podāns

> Сертификаты пользователей обязательно должны быть присоединены к учетным записям? не обязательно. Тогда проверка по UPN сертификата с UPN пользователя. UPN'ы существуют только в домене. > Нет никакой возможности сделать так, чтобы сервер просто проверял сертификат на валидность (корневой CA доверенный, срок действия не истек, не отозван) Можно, как я говорил, вам придётся написать собственное приложение, эмулирующее функции аутентификации контроллера домена с интегрированием с LSA. Задача не из простых и стоит будет недёшево.

Альберт

То есть получается, что в принципе, можно и не привязывать сертификат к учетным записям. Но тогда на сайт сможет зайти любой, предъявивший действительный клиентский сертификат, причем не обязательно выданный нашим CA. Однако, в своем web-приложении мы можем определить с каким именно клиентским сертификатом вошли на сайт и таким образом аутентифицировать и авторизовать пользователя на уровне нашего приложения. А если бы мы сделали привязку сертификатов к учетным записям, то на сайт смогли бы войти только предъявившие клиентский сертификат, привязанный к какой-то нашей учетной записи, то есть аутентификация и авторизация прошла бы на уровне IIS. Я правильно понимаю?

Vadims Podāns

> Но тогда на сайт сможет зайти любой, предъявивший действительный клиентский сертификат, причем не обязательно выданный нашим CA неа. Как я уже сказал, вы не можете использовать системные средства аутентификации в вашем сценарии, потому что они бесполезно. Следовательно, вам весь процесс аутентификации придётся реализовывать на уровне вашего приложения. А это потребует включения анонимной аутентификации в IIS. И вам в вашем приложении придётся реализовать запрос клиентского сертификата (вы не можете это делать средствами IIS), поскольку клиент просто так не будет предъявлять вам сертификат.

anon

Есть мнение что в CApoliсy.inf некоторые значения нужно указывать в шестнадцатеричном формате, потому что половина параметров не применяется во время установки ЦС. http://technet.microsoft.com/ru-ru/library/cc775815%28WS.10%29.aspx [certsrv_server] renewalkeylength=2048 RenewalValidityPeriodUnits=0x18 RenewalValidityPeriod=years CRLPeriod = days CRLPeriodUnits = 2 CRLDeltaPeriod = hours CRLDeltaPeriodUnits = 4

Vadims Podāns

какие парамеры у вас не применяются?

anon

RenewalValidityPeriodUnits из файла capolicy.inf не применяется 100%, остальные не проверял.

anon

Еще хотелось бы уточнить, а для чего нужно делать certutil -dspublish -f C:\CertData\Adatum_RCA.crt RootCA ? Я так понимаю что это нужно для публикации сертификата в АД, но не совсем понимаю для чего это нужно и как это будет работать. Можно ли пнуть в нужное направление? :)

Vadims Podāns

> RenewalValidityPeriodUnits из файла capolicy.inf не применяется 100% а у меня применяются. > а для чего нужно делать certutil -dspublish -f C:\CertData\Adatum_RCA.crt RootCA для того, чтобы члены леса доверяли вашему корневому CA.

Дмитрий

Столкнулся с ситуацией что сервер в домене под Windows Server 2008 R2 SP1 Enterprise с установленным Enterprise CA (Root) нельзя повысить до контроллера домена (пока уровня 2003), хотя роль Directory Service ставится, но ругается DCpromo что есть роль CA. Что теперь наоборот (по стравнению с Windows 2000) роль Active Directory Domain Services не ставится рядом с ролью Active Directory Certificate Services? Обойти можно это? Спасибо за интересный блог.

Vadims Podāns

> роль Active Directory Domain Services не ставится рядом с ролью Active Directory Certificate Services? а зачем вам CA на контроллере домена? Перестаньте этого хотеть раз и навсегда. Ваша проблема — одна из нескольких, почему нельзя совмещать роль CA с контроллером домена. Пока на сервере устанвлена роль CA, вы лишаетесь следующих возможностей: 1) переименование компьютера 2) переименование домена 3) повышение сервера до контроллера домена 4) понижение контроллера домена до рядового сервера. Самое лучшее — это установить CA на простой доменный сервер. Если вы всё-таки, до сих пор хотите установить CA на контроллер (или повысить/понизить роль сервера), тогда надо сделать полный бакуп сервера CA, удалить CA, провести нужные операции с сервером (повысить до контроллера домена), установить CA, восстановить CA из бакупа. Но если что-то пойдёт не так — не говорите, что я не предупреждал вас :)

Дмитрий

Огромное спасибо за внятный ответ. А то Internet по этому поводу забит всякой ерундой. Дело в том что ни 1) ни 2) ни 4) я делать в ближайшие годы не собирают, т.к. домен новый, а на CA лежат 5 несчастных сертификатов для одного ПО. Если придётся менять имя домена, то я думаю CA просто убъют и сделают новый, а имя ПК тоже навечно (другие сервисы, принтеры например). Если делать отдельно CA, то это означает виртуализировать BL460c G7 - уж лучше его нагрузить. Если дело только в именах. то это для меня ерунда, но вопрос в другом. Что значит - "не говорите, что я не предупреждал вас": есть ещё известные ошибки типа как в вашей заметке "OCSP на Windows Server 2008 R2" http://www.sysadmins.lv/PermaLink,guid,b0079f99-da21-4c42-8db4-51ab55d8fd83.aspx. Если таких багов много и Microsoft отказывается о них заботиться, то я суваться в эту историю с совмещением ролей не хочу. Что Вы слышали об этом?

Vadims Podāns

я не знаю о них. Просто ещё раз прочитайте мой предыдущий ответ. Я вам дал воркэраунд. Просто я не знаю чем это может обернуться.

Дмитрий

Проделал процедуру для добавления роли Domain Controller на сервер с CA. Может кому пригодиться. Дано: сервер W8K R2 Ent SP1 как просто сервер в домене с поднятой ролью Active Directory Certificate Services Enterprise (роль содержит службы Certification Autothority + Certification Autothority Web Enrollment + Online Responder + Network Device Enrollment Service). После установки роли Active Directory Domain Service и попытке запуска Dcpromo для поднятия сервера до контроллера домена, мастер говорит что это невозможно, т.к. стоит роль AD Certificate Services Последовательность шагов для на одном сервере роли CA и DC 1. Классический Backup CA (приватный ключ CA в файл *.pfx или *.p12, БД сертификатов, ключ реестра в файл [HKLM\SYSTEM\CurrentControlSet\services\CertSvc\Configuration] 2. Удалить роль Active Directory Certificate Services (без предварительной чистки AD, большая часть настроек СА останется в домене по пути ADSIedit\Configuration\Services\Public Key Services 3. После перезагрузки добавить роль Active Directory Domain Service и, запустив dcpromo, поднять сервер до DC 4. После перезагрузки добавить Certification Autothority\ службу Certification Autothority, указав сохранённый ключ центра сертификации из файла *.pfx или *.p12 5. После перезагрузки добавить Certification Autothority\ службу Certification Autothority Web Enrollment. Но сразу она не поставится – мастер установки службы роли вывалится с ошибкой “Сannot install Certification Authority Web Enrollment. Active Directory Certificate Services setup failed with the following error: The parameter is incorrect. 0x80070057 (WIN32: 87)“. Нужно изменить значение в реестре HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\SetupStatus на 0x6001 (было dword 00006003) 6. Добавить Certification Autothority\ службу Online Responder - Это делать не надо http://www.sysadmins.lv/PermaLink,guid,b0079f99-da21-4c42-8db4-51ab55d8fd83.aspx (ошибка была только в RTM, но знать это стоит) – все настроится само. 7. Попробовать добавить Certification Autothority\ службу NDES - при установке будет ошибки: Если указать доменную учётку - This account is not a member of the local machine's ISS_IUSRS group. The specified user account is not a member of the specified group account. 0x80070529 (WIN32: 1321) Если указать встроенную учётку - Application Pool Identity account cannot send authenticated certificate request to a local Enterprise CA. Specify a user account. The access code is invalid. 0x8007000c (WIN32: 12) Нужно: Включить видимость на контроллере домена локальной группы IIS_IUSRS выполнив в командной строке под администратором скрипт *.js (тело скрипта взять здесь http://support.microsoft.com/?kbid=946139 и перегрузиться). Затем добавить в эту группу доменную учётку типа Domain\serviceNDES и установить службу NDES указав эту именно её. У меня эта учётка – та под которой работаю я как Domain Admins. Иначе установка пройдёт, но при открытии web-сайта NDES будет такая ошибка: “Service Unavailable. HTTP Error 503. The service is unavailable”. Но теперь сайт открывается только под моей учёткой. Под другими - You do not have sufficient permission to enroll with SCEP. Вопрос к знающим - какие права дать Domain\serviceNDES ?

Дмитрий

Дополнение к предыдущему посту: Если не работает запрос сертификатов из консоли The RPC server is unavailable 1) В группу CERTSVC_DCOM_ACCESS добавить недостающих: The Domain Users group The Domain Computers group The Domain Controllers group 2) выполнить команду certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG и перезапустить службу CA, без перезагрузки сервера и клиентов. взято отсюда http://social.technet.microsoft.com/Forums/ru-RU/ws2008ru/thread/c717967a-b356-461f-883c-34b0aa667618

Денис

Всем доброго времени суток. Мы в данный момент имеем две структуры CA в доменной сети - старую - один сервер Enterprise Root CA, который постепенно будет выводиться из эксплуатации, и новую - 2-уровневую+отдельный WEB и OCSP-сервер, сделанную правильно с помощью данного замечательного блога, на которую мы постепенно перетаскиваем сертификаты. Вадимс, нужен ваш совет. Как сделать так, чтобы, пока мы выводим старый сервер CA из эксплуатации, новые сертификаты (включая выдаваемые через Active Directory) через него не выдавались, но старые проверялись. Это возможно? Если да - киньте ссылку, плз. Спасибо.

Vadims Podans

Вам достаточно отключить все шаблоны на старом СА и назначить их на новом.

Vitaly

Добрый день, Возникла необходимость миграции в другой домен, На новом месте поднял Offline RootCA (на основе старого корневого сертификата) и выдал сертификат Online SubCA(из нового домена), настроил CrossForest со старым доменом (чтобы пользователи могли использовать старые сертификаты). Проблема с импортом базы старых сертификатов, файлик не подгружается. Ошибка - The expected data does not exist in this directory/ please choose a diferent directory. The directory name is invalid. 0x8007010b (WIN32/HTTP: 267) Подскажите пожалуйста, возможн ли вообще такой импорт? Или при миграции домена нужна другая схема?

Vadims Podāns

Честно говоря я не понял, что вы делали, но вам надо было выполнить бэкап БД существующего CA и восстановить её на новом сервере.

Vitaly

Бекап сделал: certutil –backup c:\RootCA_%date% (как в Вашей статье) пытаюсь восстанавливать: C:\CertData>certutil -restore C:\CertData\RootCA_010313 Enter PFX password: Restored keys and certificates for c-ca.test-contoso.com\Corp-Contoso_root from C:\CertData\RootCA_010313\Corp-Contoso_root.p12. Restoring database for c-ca.test-contoso.com\test-contoso_sub-ca. Not a valid backup directory: C:\CertData\RootCA_010313. CertUtil: -restore command FAILED: 0x8007010b (WIN32/HTTP: 267) CertUtil: The directory name is invalid. Получается что в случае успешной загрузки в рамках одного СА будут сертификаты - * Подгруженные сертификаты будут иметь цепочку Root.crt->User.crt (не уточнил, старый CA был 3 в одном) * Выдаваемые сертификаты будут иметь цепочку Root.crt->Sub.crt->User.crt Подозреваю что проблема связана с такой не стыковкой. Хотел узнать Ваше мнение, такое вообще возможно, или нужно какое то другое решение?

Vadims Podāns

Вы уберите p12 файл из папки с бэкапом, тогда база восстановится. Certutil не любит, когда лишние файлы в папке. Ну и убедитесь, что вы восстанавливаете родную БД (т.е. не от другого CA).

Vitaly

Добрый день, продолжил изучение вопроса, также открыл вопрос на форуме microsoft Technet (там с картинками) http://social.technet.microsoft.com/Forums/ru-RU/ws2008r2ru/thread/ae36f188-4a91-4bb3-89d8-48347912d394?referrer=http://social.technet.microsoft.com/Forums/ru-RU/ws2008r2ru/thread/ae36f188-4a91-4bb3-89d8-48347912d394 В кратце - базу загрузил командой - certutil -f -config "c-ca.test-contoso.com\Corp-Contoso_root" -restore C:\CertData\RootCA_03112013 Особенность в том что с-са это SubCA а Corp-Contoso_root это бывший RootCA а теперь OffLine RootCA. Но перестала запускаться служба Certification Authority, с ошибкой: Active Directory Certificate Services did not start: Unable to initialize the database connection for testcontoso-sub. Error 0xc8000713 (ESE: -1811). testcontoso-sub - это имя выпускающего сертификата SubCA

Vitaly

Не внимательно прочитал Ваш предшествующий коментарий, Пытался восстановить БД от CA с другим корневым сертификатом.

Vadims Podāns

> Пытался восстановить БД от CA с другим корневым сертификатом. вот и чудненько. Теперь постарайтесь найти и восстановить правильный бэкап БД. А последний пост в треде (от Дмитрия Зобнина) -- чушь собачья.

Comments are closed.