Вадим, не много не в тему миграции, а в сторону иерархии служб сертификации: как вы относитесь к конструкции с отсутствующим RootCA в плане ОС. Т.е. когда мы просто имеем ключ и сертификат и пользуясь, например, возможностями OpenSSL подписываем сертификаты SubordinateCA\Issuing CA? Это значительная экономия на лицензии ОС! Так же прошу вас осветить такой момент: Вначале мы имеем свой собственный RootCA сертификат, сгенерили его сами, но организация растёт, у неё появляются публичные сервисы, которые нужно подписывать. Покупается публичный сертификат - но что делать с существующей инфпраструктурой? Запускать в работу еще один схему сертификации? Постепенно уходить от непубличной схемы? Нужны ли нам публичные сертификаты в закрытой сети? P.S. я заранее приношу извинения, если непрвильно использую термины или вообще "не в теме", я скорее начинающий в службах сертификации, чем дока.

Ну нормально отношусь, пока корень является PKI-compliant. Т.е. кроме выдачи сертификатов нужно обеспечить: 1) расширение AIA в сертификате; 2) расширение CDP в сертификате; 3) возможность создания и подписывания CRL. т.е. если вы это можете обеспечить средствами OpenSSL, то почему бы и нет? Просто мне кажется, что это будет не очень удобно. Что касается публичных сервисов, то как правило покупаются конкретные сертификаты для конкретных сервисов (если я правильно понимаю вопрос). Инфраструктуру этих сертификатов поддерживает коммерческий CA и вам заботиться тут не о чем. Разве что позаботиться о безопасности ключей этих сертификатов. Возможны варианты, когда у коммерческого CA приобретается сертификат для Subordinate CA, как это делает, например, Microsoft. Либо по договору с коммерческим CA можно устроить Qualified Subordination. Тогда коммерческий CA выдаёт вам сертификат, который можно использовать только для каких-то определённых целей, которые оговорены в договоре. Но это уж слишком дорогое удовольствие, поэтому нет однозначного ответа на этот вопрос, поскольку техническая составляющая вопроса будет не самой главной.

> Просто мне кажется, что это будет не очень удобно. Почему же? Сложно сделать изначально правильный сертификат - так ведь и сертификация вещь не простая! CRL для SubordinateCA\Issuing CA нужны раз в два, три месяца. Их всё равно носить на флешке! :-) Так почему бы не запускать заранее подготовленный скрипт на временной виртуальной машине для генерации CLR? Еще один плюс - не нужно ставить обновления на RootCA (обновлять OopenSSL конечно нужно - но, насколько я знаю, эти библиотеки не требуют установки). Но в итоге - кому как нравится, конечно. P.S. Зато "оффлайновей" не придумаешь, со всеми вытекающими.

> Сложно сделать изначально правильный сертификат вы так говорите, будто это действительно сложно. В Windows 2000 и 2003 — да, надо было использовать capolicy.inf, но начиная с 2008, генерация корневого сертификата просто делается через Next-Next. Хотя, по большому счёту capolicy.inf использовать следует всегда при поднятии CA. > Их всё равно носить на флешке! :-) на котором будет сидеть медвежный троян. И как вы обеспечите безопасность ключей и аудит доступа к ним? И как у OpenSSL с безопасностью (наличие уязвимостей) и с поддержкой?

> вы так говорите, будто это действительно сложно. Я имею ввиду создать его средствами OpenSSL - там нет никаких "Next-Next". Маны прийдётся покурить. Наверняка есть различные GUI с OpenSSL? которые могут облегчить этот процесс. А так же создать корневой сертификат можно и на Win, потом выгрузить его в стандартизованном формате и уже средствами OpenSSL делать все другие операции. > на котором будет сидеть медвежный троян. Технические детали как носить мы опустим. > И как вы обеспечите безопасность ключей и аудит доступа к ним? И как у OpenSSL с безопасностью.... Аудит конечно не автоматизирован. Можно вести бумажный журнал, использовать корневой сертификат при участии комисси, например из 3-х человек. Вариантов много. Всё зависит от того, насколько он (аудит) вам важен. OpenSSL широкоприменяемый софт. Уязвимости конечно находят. По моему мнению очень редко, чаще наращивают функционал.

> Технические детали как носить мы опустим. почему это? > Можно вести бумажный журнал, использовать корневой сертификат при участии комисси, например из 3-х человек выглядит не очень удобно. > OpenSSL широкоприменяемый софт вот я его не применял ни разу. > Уязвимости конечно находят :)

>> Технические детали как носить мы опустим. > почему это? Это конечно не мелоч, но если мы уж делаем надёжный rootCA то о безопасности флешки тоже должны позаботиться. Форматить её каждый раз, например. тут можно много полемизировать вплоть до того, что производитель ( в том числе процессора) делает закладки в своих продуктах и всё равно АНБ (ФБР) всё что нужно достанет. > выглядит не очень удобно. я ж говорил - со всеми вытекающими. >> OpenSSL широкоприменяемый софт > вот я его не применял ни разу. Всевозможные Linux, BSD, Unix, далее софт Apache, OpenVPN и много много много чего. Просто под Windows он не так нужен - есть встроенные средства.

> Форматить её каждый раз, например ну для таких случаев придуманы HSM. > Просто под Windows он не так нужен - есть встроенные средства что и требовалось доказать :)

Вадим, спасибо за отличный блог. Возможно посоветуете, как лучше поступить. По вашей статье в разделе Configuration –> Services –> Public Key Services –> Enrollment Services удалил не тот параметр - запись действующего CA. Соответственно вопрос, как ее можно восстановить (КД 2 штуки и репликация уже прошла). Имеется backup system state, но есть сомнения, что в нем содержится информация о конфигурации. Если она есть, восстановление надо производить на владельце ролей или на любом КД домена, для которого имеется соответствующий system state? Возможно, этот параметр можно вернуть другим способом?

самое простое: сделать бакуп действующего CA (включая ключи, БД и конфигурацию реестра). Переустановить роль CA и восстановить БД и конфигурацию из бакупа. При установке просто укажете существующий сертификат из PFX.

Спасибо, помогло. Но возник один нюанс. При установке заново, видимо, я не импортировал ключ на нужном этапе, и у меня создался новый сертификат. После импорта, по пути в AD опубликован почему-то этот новый сертификат. По http и физически на диске в папке лежат правильные сертификаты. Как поправить сертификат в AD?

вам надо переустанавливать CA полностью и повторять процедуру миграции (в данном случае восстановления из бакупа).

Если переустанавливать с импортом в процессе установки - тоже самое. Я полагаю, у меня и раньше по пути в АД был опубликован неверный сертификат, я просто не обращал на это внимания. Поэтому? при импорте по этому пути ничего и не перезаписывается. Если полностью снести CA и поставить заново без импорта - всё публикуется верно. Возможно, есть способ принудительно опубликовать сертификат в AD?

По поводу публикации в AD, в статье есть же примеры команды 'certutil -dspublish'. Они и публикуют сертификат в AD.

Немного непонятно выразился. Я полностью сношу CA, ставлю заново, создаю новый сертификат и новый закрытый ключ. После этого смотрю pkiview - всё нормально. Потом импортирую из бэкапа свой CA - все настройки перезаписываются, кроме сертификата, опубликовонного в AD - там остается новый, который создался на этапе предыдущей полной установки. PS Пробовал certutil –dspublish (с сертификатом нужного CA-восстановленного из бэкапа)- пишет, что сертификат уже содержится в хранилище DS и ничего не меняется. PPS Сори, что загружаю, но ситуация не совсем стандартная видимо, сам не разберусь.

Ну нет, если вы генерируете новый сертификат CA, вы не должны восстанавливать БД, потому что сертификаты и CRL'ы в базе подписаны совсем другим ключом. Как я уже сказал, если вы хотите сделать миграцию — вы должны указывать сертификат CA из PFX (ну или предварительно установленного в хранилище) и только его. В вашем случае вы просто создали совершенно новый CA.

Понял. А в AD по пути, где хранится сертификат моего CA, могут хранится сертификаты нескольких CA, допустим, Offline и Issuing? У меня получилось так, что в pkiview по пути в AD опубликован неправильный сертификат (тот, что опубликовался туда при новой установке CA). И даже снеся службы сертификации и переустановив из бэкапа нужный CA я никак не могу заменить сертификат по тому пути. certutil –dspublish –f C:\RootCA.crt SubCA возвращает что сертификат уже существует. А по http записывается верный. Из-за чего такое может быть, не знаете?

Вопрос снят. То ли повторная публикация вашим powershell скриптом помогла то ли что, но по прошествии некоторого времени сертификат по пути в AD записался, и pkiview его там отображает. Немного странное поведение, если честно.

"Установка Offline Standalone CA ... конфигурацию восстановить простым запуском Reg файла" Вот тут нужно добавить "... открыть "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Adatum Root CA" и ключ UseDS:DWORD поменять на "0" ..." У меня в лабе (W2K8R2) данный ключик приплывает с конфигом сервера и блокирует запуск службы CertSvc. Вываливается с ошибкой 1351: System error 1351 has occurred. Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied.

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

"установите курсор на ключе: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Adatum Root CA Экспортируйте этот ключ в Reg файл и сохраните в папке, где расположен бэкап базы CA" Может я где просмотрел конечно, но дальше идёт "конфигурацию восстановить простым запуском Reg файла" На первом этапе мы получаем *.reg-файл, а на втором его импортируем. При этом импортируется указанный параметр. И ещё один момент, правда пока не понял, какой ключик за это отвечает. После всех манипуляций с восстановлением, у меня отображаются ещё и "Certificate Templates", хотя на этапе установки был выбран вариант "Standalone". Судя по всему при импорте подтянулся ещё какой-то "лишний" ключик :(

И ещё один момент, правда пока не понял, какой ключик за это отвечает. После всех манипуляций с восстановлением, у меня отображаются ещё и "Certificate Templates", хотя на этапе установки был выбран вариант "Standalone". Судя по всему при импорте подтянулся ещё какой-то "лишний" ключик :( Ключик называется CAType:DWORD. Когда было значение "0" - отображался "Certificate Templates", после того, как поставил значение "3" - отображаться перестал.

Т.к. certutil –restore c:\RootCA_%date% –f –config "OfflineRCA\Adatum Root CA" выполняться отказалась - пришлось экспериментировать, в результате правильная команда: certutil -f -config "OfflineRCA\Adatum Root CA" -restore c:\RootCA_%date%, но в процессе была выполнена команда "certutil -f -restore c:\RootCA _%date%", что могло привести к возникновению проблемы. Хотя маловероятно это могло привести к такой реакции, т.к. вышеописанные ключи содержатся в reg-файле, который импортируется целиком. PS: Видимо от перемены мест слагаемых сумма изменяется, что было установлено опытным путём. При выполнении команды из примера возникала ошибка: "Expected no more than 1 args, received 4".