Skip to content
Tags

Добавление стороннего центра сертификации в иерархию PKI Microsoft

26.08.2014

Если в вашей организации развернута PKI на платформе Windows, то, как правило, не возникает проблем в использовании издаваемых сертификатов на разных операционных системах и иных устройствах: стандарты сертификатов и PKI являются кроссплатформенными. Дополнительные сложности могут возникнуть, например, в поддержке российских криптографических алгоритмов шифрования и электронной подписи, однако этот вопрос решается установкой специализированного ПО, добавляющего поддержку данных алгоритмов, как на центры сертификации, так и на клиентов PKI.

Недавно столкнулся со специфической проблемой, когда потребовалось установить в инфраструктуре PKI, построенной полностью на серверах Microsoft, центр сертификации на другой платформе. Может возникнуть вопрос о целесообразности данного действия, ведь сервер сертификатов Microsoft прекрасно справляется с выдачей сертификатов самого разного назначения. Все это так, однако продукт Wesbense Content Gateway, который требовалось установить, содержит в качестве компонента собственный центр сертификации, динамически издающий сертификаты на каждую клиент-серверную SSL-сессию.

Таким образом, требовалось выпустить сертификат (с закрытым ключом) для создания подчиненного центра сертификации (CA). И вот здесь возникла суровая проблема. Мне не удалось найти способ запросить сертификат на шаблоне Subordinate CA, используя веб-интерфейс корневого центра сертификации. С другой стороны, имелась возможность установить подчиненный CA на Windows-сервере и при этом пройти стандартную процедуру запроса/получения сертификата для подчиненного CA, однако экспортировать этот сертификат вместе с закрытым ключом не представлялось возможным.

При этом всевозможные сертификаты с закрытыми ключами, генерируемые на корневом CA, упорно отвергались со стороны Websense Content Gateway. Стало ясно, что требуется сертификат с особыми параметрами, предназначенный именно работы подчиненного центра сертификации.

Совсем немного теории: сертификат, предназначенный для установки в подчиненном CA, должен иметь расширение Basic Constraints, в котором обязательному полю CA должно быть присвоено значение True, причем указанное расширение должно присутствовать уже в запросе на сертификат. Ниже описывается последовательность шагов,  для того чтобы сформировать закрытый ключ и запрос на сертификат подчиненного CA, так чтобы он был подписан корневым центром сертификации на Windows-платформе. Все перечисленные действия выполняются с использованием свободно распространяемого продукта OpenSSL для Windows, который можно загрузить с этой страницы:

http://slproweb.com/products/Win32OpenSSL.html

1. Установите пакет OpenSSL (если он еще не установлен) на жесткий диск в папку C:\OpenSSL.

2. В папке C:\OpenSSL\bin найдите файл openssl.cfg и сделайте копию этого файла. Как вариант, вы можете скопировать файл в другую папку или сохранить его здесь же под именем openssl1.cfg. Нам потребуется отредактировать копию файла текстовым редактором. К сожалению, в Блокноте файл открывается с нарушением форматирования, поэтому используйте другой редактор, например, входящий в популярный Far Manager.

3. Файл openssl.cfg, копию которого мы будем редактировать, имеет структуру, типичную для ini-файлов. Разделы в нем обозначаются именами в квадратных скобках и содержат параметры. Каждый параметр записывается на отдельной строке, и ему через знак равенства присваивается параметр. Комментарии обозначаются знаком # в начале строки.

В разделе [req] найдите следующий закомментированный параметр

# req_extensions = v3_req # The extensions to add to a certificate request

«раскомментируйте» его и отредактируйте значение следующим образом:

req_extensions = v3_ca # The extensions to add to a certificate request

В разделе [v3_ca]

«закомментируйте» параметр

authorityKeyIdentifier=keyid:always,issuer 

(поставьте # в начале строки) и убедитесь, что в этом же разделе присутствует следующая незакомментированная строка:

basicConstraints = CA:true

Напоминаю, что все исправления должны быть сделаны в копии файла openssl.cfg, а не в исходном файле.

4. Используя ПО OpenSSL, сгенерируйте закрытый ключ. Для этого в командной строке выполните:

c:\openssl\bin\openssl.exe genrsa -des3 -out  private.key 1024

Здесь private.key — имя файла, в котором будет сохранен закрытый ключ, а последний параметр в командной строке (1024) задает длину ключа. У вас должны быть права на запись файла в текущей папке. Ключ сохраняется в файле в зашифрованном виде, при этом в процессе создания ключа вы должны дважды ввести придуманную вами парольную фразу, на которой будет зашифрован ключ.

5. Сформируйте запрос на сертификат. Для этого в командной строке выполните

c:\openssl\bin\openssl.exe req -new -key private.key -out cert.csr -config c:\openssl\bin\openssl1.cfg

При этом в текущей папке у вас должен находиться файл закрытого ключа private.key, а сам запрос будет сохранен в файле cert.csr. В процессе создания запроса на сертификат будет запрошена парольная фраза. Обратите внимание на параметр -config: за ним через пробел следует указать путь к отредактированной вами копии файла openssl.cfg.

5. Откройте файл cert.csr в текстовом редакторе и скопируйте его содержимое в буфер обмена. Далее откройте стандартный веб-интерфейс вашего корневого центра сертификации (http://<Root-CA>/certsrv), последовательно выбрать Request a certificate -> Advanced certificate request -> Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file и вставьте запрос на сертификат из буфера обмена в поле Saved request. Щелкните кнопку Submit.

6. Выполните на корневом CA стандартные шаги по выпуску сертификата. Обратите внимание, что изданный сертификат имеет атрибут Basic Constraints, как показано на рисунке.

cert_basic_constraints

Таким образом, у вас имеются зашифрованный закрытый ключ и сертификат подчиненного центра сертификации, подписанный корневым CA. Полученные ключ и сертификат можно использовать по назначению: для развертывания стороннего центра сертификации в инфраструктуре PKI Microsoft.

 

Реклама
One Comment
  1. Спасибо тебе добрый человек. Благодаря твоей статье смог быстренько всё сделать.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: