На пути к автоматизации выпуска SSL / Хабр

Начальные настройки

Сперва заполним файл /root/.rnd, который используется как источник начальных случайных значений в генераторе псевдослучайных чисел OpenSSL. Суть использования этого файла описана на сайте OpenSSL. Нам надо заполнить свой файл случайными данными, как вариант — скопировав из /dev/urandom 32768 байт в файл .rnd таким образом:

Далее создадим сертификат для CA:

root@shpc:/opt/simple_CA# openssl req -newkey rsa:4096-keyform PEM -keyout ca.key -x509-days3650-outform PEM -out ca.cer

Опции для сертификата берутся из файла /etc/ssl/openssl.cnf. Сам файл довольно большой, мы не будем приводить здесь его содержимое. В реальности стоит создать свой конфигурационный файл с необходимыми опциями и блоками — и использовать его для генерации сертификатов.

На выходе получим два файла: ключ и сертификат. 

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

root@shpc:/opt/simple_CA# openssl x509 -text-noout-in ca.cer

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

root@shpc:/opt/simple_CA# openssl genrsa -out server.key 4096

Теперь используем этот ключ для генерации запроса на выдачу сертификата (CSR):

root@shpc:/opt/simple_CA# openssl req -new-key server.key -out server.req -sha256

Отметим, что данные, которые вы вводите в поля, должны совпадать со значениями в тех полях, что указывались при создании сертификата корневого сервера. Теперь возьмём корневой сертификат CA и запрос — и сгенерируем на их основе сертификат для сервера:

root@shpc:/opt/simple_CA# openssl x509 -req-in server.req -CA ca.cer -CAkey ca.key -set_serial 100-extensions server -days1460-outform PEM -out server.cer -sha256

Должно получиться 5 файлов.

Файл server.req можно удалить — а при необходимости создать заново. Теперь надо перенастроить веб-сервер для работы с сертификатами.

Вопросы реализации

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

Следует также определить, будете ли вы использовать внешний или собственный корневой CA. Выбирая известный внешний корневой CA, такой как VeriSign или Thawte, вы избавитесь от необходимости задавать явное внешнее доверительное отношение с этим корневым CA, добавляя его сертификат в свое хранилище.

Кроме того, не придется организовывать обмен корневыми сертификатами с другими участниками обмена документами. Это может оказаться весьма важным фактором, поскольку организация такого обмена — занятие достаточно трудоемкое, а сертификаты основных внешних сертификационных центров, как правило, есть везде.

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

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

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

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

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

Когда срок действия сертификата подходит к концу, выполняется обновление этого сертификата, и новый сертификат CA обрабатывает запросы на сертификацию. Как ориентировочные значения можно принять 20-летний жизненный цикл для корневого сертификата, промежуточные CA имеют срок действия 10 лет, выдающие CA — пять лет, но, конечно, эти значения могут варьироваться в зависимости от принятых в организации политик и бизнес-требований.

Далее требуется определить необходимую стойкость ключа шифрования для своих сертификатов. Чем больше длина ключа в битах, тем более стойким он считается и тем меньше вероятность, что он может быть вычислен с использованием математических методов. Обратной стороной медали в данном случае является длительное время, необходимое для создания или обновления сертификатов и расшифровки сообщений, зашифрованных асимметричным ключом.

Консоли certificate services и certificates templates mmc

Консоль Certificate Services MMC (службы сертификатов или certsrv.msc) – это ваша основная консоль для администрирования PKI. Вы должны потратить немного времени и познакомиться с этой консолью лучше, так как с ее помощью можно глубже заглянуть в мир Microsoft PKI.

С помощью этой консоли вы можете лучше понять, что такое AIA, CDP, шаблоны сертификатов V2 certificate templates, и т.п., как они связаны с областями, о которых мы рассказывали в предыдущих статьях. Встроенная помощь может также существенно помочь, т.к. она содержит небольшой раздел с рекомендациями (как и многие другие встроенные файлы помощи в операционной системе Windows Server 2003).

Одна из наиболее частых ошибок, связанных с PKI – это устаревший или недоступный CRL. Самый быстрый способ ее решения – это опубликовать CRL с помощью консоли Certificate Services MMC, но это можно также выполнить из командной строки, о чем вы очень скоро узнаете.

Рисунок 1: Публикация CRL

Это должно войти у вас в привычку проверять, выпущен сертификат или нет, проверяя в подменю “Failed Requests (невыполненные запросы)” в левой части консоли MMC console. Из этого меню вы сможете выяснить, почему возникла ошибка при попытке выпустить сертификат.

Очень часть эту ошибку очень сложно прочитать в разделе “Failed Request (невыполненные запросы)”. Но эта же самая ошибка будет записана в прикладной журнал (application log). И поэтому проще скопировать запись из журнала событий (event log) из Event Viewer (просмотр событий), чем просмотреть в консоли Certificate Services MMC, то это будет более предпочтительным способом проверить наличие ошибок, связанный с PKI, если конечно, вы не используете некий способ для передачи администрирования и настройки вашей консоли.

Еще одна частая ошибка – это неправильные настройки безопасности для шаблонов сертификатов (certificate template). Вы можете изменить безопасность для шаблонов сертификатов с помощью консоли Certificate Services MMC, либо щелкнув правой кнопкой мыши на Certificate Templates (шаблоны сертификатов) и выбрав пункт Manage (управление) или запустить новую консоль MMC, в которую вы добавите шаблоны сертификатов Certificate Templates (certtmpl.msc).

В любом случае в консоли Certificate Templates MMC, вы должны выбрать свойства для шаблона сертификата, который вы хотите использовать. Затем перейдите на закладку Security (безопасность) и убедитесь, что правильной группе безопасности (security group) разрешено получать сертификаты, задав для этой групп права на чтение “Read” и на внесение в список “Enroll”.

Рисунок 2: Проверьте правильность настроек безопасности для шаблонов сертификатов

Настройка apache 2 для использования сертификатов

Переходим в каталог /etc/apache2:

root@shpc:/mnt# cd/etc/apache2/

Создаём каталог для хранения сертификатов:

root@shpc:/etc/apache2# mkdir ssl

Включаем модуль SSL для веб-сервера. Тестирование проводилось на ОС Ubuntu Linux, поэтому модуль достаточно просто включить:

a2enmod headers

Перезапускаем веб-сервер:

root@shpc:/etc/apache2# systemctl restart apache2

Аналогично нужно включить поддержку заголовков: 

Теперь создадим конфигурационный файл для модуля SSL. Пример содержимого для него можно взять на Syslink.pl. Команды такие:

root@shpc:/mnt# cd /etc/apache2/conf-available
root@shpc:/etc/apache2/conf-available# nano ssl-params.conf

Сам файл будет содержать следующие параметры (чтобы было проще работать, мы отключили заголовки Strict-Transport-Securrity, X-Frame-Options и X-Content-Type-Options):

Далее созданный конфиг надо активировать:

root@shpc:/etc/apache2/conf-available# a2enconf ssl-params

Теперь переходим в каталог /etc/apache2/sites-available:

root@shpc:/etc/apache2/conf-available# cd/etc/apache2/sites-available

И делаем на всякий случай резервные копии всех хранящихся там файлов:

root@shpc:/etc/apache2/sites-available# cp 000-default.conf 000-default.conf.bak
root@shpc:/etc/apache2/sites-available# cp default-ssl.conf default-ssl.conf.bak

Теперь ещё раз проверяем подключённые модули headers и SSL:

Далее нам надо перенести созданные сертификаты (сертификат CA и сертификат сервера) в каталог /etc/ssl/certs, а ключ сертификата сервера — в каталог /etc/ssl/private:

root@shpc:/opt/simple_CA# cp ca.cer /etc/ssl/certs/
root@shpc:/opt/simple_CA# cp server.cer /etc/ssl/certs/server.crt
root@shpc:/opt/simple_CA# cp server.key /etc/ssl/private/server.key

Далее откроем конфиг сайта (/etc/apache2/sites-available/000-default-ssl.conf) и добавим туда следующие опции:

SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCACertificateFile /etc/ssl/certs/ca.cer

Теперь перезагружаем веб-сервер:

root@shpc:/etc/apache2# a2ensite default-ssl
root@shpc:/etc/apache2/sites-available# service apache2 restart

Проверяем доступность сайта:

Видим, что Firefox не может проверить сертификат сайта. Чтобы смог, надо импортировать цепочку сертификатов, подтверждающих сертификат сервера, в список доверенных. Создадим цепочку:

root@shpc:/opt/simple_CA# openssl crl2pkcs7 -nocrl-certfile ca.cer -certfile server.cer -out serve-and-ca-chain.p7c -outform der

У полученного файла не забываем сменить атрибуты на 555:

root@shpc:/opt/simple_CA# chmod555 serve-and-ca-chain.p7c 

Теперь откроем в браузере менеджер сертификатов и импортируем полученную цепочку (кнопка Import):

Далее можно просмотреть сертификаты и настроить доверие — вдруг что-то упущено:

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

Сейчас время настроить аутентификацию для клиентов. 

Обязательные атрибуты квалифицированных сертификатов

Состав квалифицированного сертификата регулируется Федеральным законом “Об электронной подписи” от 06.04.2021 N 63-ФЗ и Приказом ФСБ РФ от 27 декабря 2021 г. N 795 “Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи”.

Несколько раз встречались квалифицированные сертификаты проверки подписи юридических лиц, выпущенные аккредитованным УЦ, в которых в поле Subject – субъект сертификации отсутствовал атрибут L – Местоположение.

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

Удостоверяющий центр данную ситуацию комментировал так:

атрибут L для юридических лиц, зарегистрированных в г. Москве, не проставляется согласно 63-ФЗ и Приказа №795

На конкретный пункты Закона и Приказа в УЦ не ссылались.

Собственный повторный анализ юридических аспектов показал:

63-ФЗ от 06.04.2021 “Об электронной подписи”

Статья 14. Сертификат ключа проверки электронной подписи

2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:

2) фамилия, имя и отчество (если имеется) – для физических лиц, наименование и место нахождения – для юридических лиц или иная информация, позволяющая идентифицировать владельца сертификата ключа проверки электронной подписи;

Статья 17. Квалифицированный сертификат

2. Квалифицированный сертификат должен содержать следующую информацию:

2) фамилия, имя, отчество (если имеется) владельца квалифицированного сертификата – для физического лица, не являющегося индивидуальным предпринимателем, либо фамилия, имя, отчество (если имеется) и основной государственный регистрационный номер индивидуального предпринимателя – владельца квалифицированного сертификата – для физического лица, являющегося индивидуальным предпринимателем, либо наименование, место нахождения и основной государственный регистрационный номер владельца квалифицированного сертификата – для российского юридического лица, либо наименование, место нахождения владельца квалифицированного сертификата, а также идентификационный номер налогоплательщика (при наличии) – для иностранной организации (в том числе филиалов, представительств и иных обособленных подразделений иностранной организации);

Приказ ФСБ РФ от 27 декабря 2021 г. № 795

III. Требования к порядку расположения полей квалифицированного сертификата

5) stateOrProvinceName (наименование штата или области).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего субъекта Российской Федерации. Объектный идентификатор типа атрибута stateOrProvinceName имеет вид 2.5.4.8;

6) localityName (наименование населенного пункта).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего населенного пункта. Объектный идентификатор типа атрибута localityName имеет вид 2.5.4.7;

7) streetAddress (название улицы, номер дома).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую часть адреса места нахождения соответствующего лица, включающую наименование улицы, номер дома, а также корпуса, строения, квартиры, помещения (если имеется). Объектный идентификатор типа атрибута streetAddress имеет вид 2.5.4.9;

В сертификате партнера в имени субъекта сертификации были указаны: stateOrProvinceName (наименование штата или области), streetAddress (название улицы, номер дома).

И не указано localityName (наименование населенного пункта).

locality – Местонахождение

В Законе 63-ФЗ и Приказе №795 нет информации, что для города Москва не нужно заполнять атрибут locality – Местонахождение.

Наоборот в обоих документах на русском языке применяется термин место нахождения, чему соответствует атрибут localityName ( 2.5.4.7)

После данного разбора удалось найти документ ФСБ РФ «ИЗВЕЩЕНИЕ ОБ ИСПОЛЬЗОВАНИИ АТРИБУТА ИМЕНИ «LOCALITYNAME» ПОЛЯ «SUBJECT» В СТРУКТУРЕ КВАЛИФИЦИРОВАННОГО СЕРТИФИКАТА КЛЮЧА ПРОВЕРКИ ЭЛЕКТРОННОЙ ПОДПИСИ»

Согласно части 2.2 статьи 18 Закона об ЭП для заполнения квалифицированного сертификата в соответствии с частью 2 статьи 17 Закона об ЭП аккредитованный удостоверяющий центр запрашивает и получает из государственных информационных ресурсов, в том числе, выписку из единого государственного реестра юридических лиц в отношении заявителя ‑ юридического лица.

Таким образом, в случае отсутствия в выписке из единого государственного реестра юридических лиц информации о наименовании населенного пункта, но при наличии информации о наименовании муниципального образования, аккредитованному удостоверяющему центру для заполнения квалифицированного сертификата вместо наименования соответствующего населенного пункта следует использовать наименование соответствующего муниципального образования.

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

Данное извещение с разъяснениями регулятора, как правильно заполнять атрибут L в квалифицированном сертификате юридического лица, также было направлено в аккредитованный УЦ.

Прошу использовать данную информацию в работе.

Желаю всем участникам PKI удачи и успехов!

Создать ssl сертификат: пошаговая инструкция

Самостоятельно создать SSL сертификат можно, выполнив 4 простых шага:

1. В Панели управления войдите в раздел «Администрирование» и выберите там пункт «Диспетчер служб IIS». 
2. В Диспетчере служб нужно перейти в раздел «Сертификаты сервера». 
3. Справа расположен столбец «Действия». В нем выберите пункт «Создать самозаверенный сертификат…» 
4. В открывшемся диалоговом окне понадобится ввести название сертификата. 

Специальная настройка промежуточных и выдающих ca

На начальном этапе настройки для промежуточного CA (SUBCA) и выдающего CA (ISSUING) действия совпадают с настройкой корневого CA. Первое отличие заключается в том, что при выборе типа CA указывается Stand-alone subordinate (отдельный подчиненный) и Enterprise subordinate (корпоративный подчиненный) соответственно.

Поскольку промежуточный CA не будет подключен к локальной сети, добавление корневого сертификата в системное хранилище сертификатов необходимо будет выполнить вручную. Копию корневого сертификата можно скопировать через флэш-накопитель с одного из AIA (ISSINGCertEnroll или ROOTCA CertConfig).

Откройте оснастку Certificates и выберите режим управления сертификатами для локального компьютера. Раскройте дерево контейнера так, чтобы можно было добраться до контейнера Certificates, вложенного в Trusted Root Certification Authorities. Щелкните правой кнопкой мыши на контейнере Certificates и выберите в контекстном меню All Tasks пункт Import.

Для подчиненных и выдающих CA необходимо будет сформировать запрос на сертификацию, который будет обрабатываться родительским CA. После копирования установочных файлов на сервер мастер выдает на экран страницу запроса сертификата CA Certificate Request Page, приведенную на экране 3.

Поскольку корневой и подчиненный CA в нашем случае отключены от локальной сети, передать запрос непосредственно на CA невозможно, так что следует выбрать сохранение запроса в файл Save the request to a file и ввести имя файла на флэш-накопителе. Мастер сохранит запрос в текстовом файле. Для завершения настройки серверов SUBCA и ISSUING нужно выполнить следующие шаги:

1. Вставить флэш-накопитель в сервер CA родительского уровня. С помощью утилиты Certreq (Certificate Request), расположенной в папке system32, передать запрос сертификации на CA. Запустить командный интерпретатор cmd.exe и, в зависимости от уровня CA, выполнить одну из приведенных ниже команд. Для SUBCA:

   CERTREQ -config "ROOTCAHP Root CA" a:SubCA.req
   Для ISSUING выполните 
   CERTREQ -config "SUBCAHP Subordinate CA" a:IssueCA.req

   ключ -config указывает утилите, CA какого уровня следует использовать. Имя слева от обратной косой черты указывает имя сервера, а справа – имя CA. После выполнения команд будет выдан идентификатор запроса (Request ID number), который следует сохранить (запомнить).

2. Открыть оснастку Certificate Authority на CA родительского уровня. В ней будут представлены четыре контейнера: отозванные сертификаты Revoked Certificates, выданные сертификаты Issued Certificates, отложенные запросы Pending Requests и отвергнутые запросы Failed Requests. Выберите контейнер отложенных запросов Pending Request – в нем вы увидите запрос, сформированный CERTREQ. Если было сформировано несколько запросов, то для определения нужного запроса следует воспользоваться сохраненным значением, определенным в пункте 1. Щелкните правой кнопкой мыши на запросе и в меню Tasks выберите Issue, после чего закройте MMC.
3. Запустить командный интерпретатор cmd.exe и, в зависимости от уровня CA, выполнить одну из приведенных ниже команд. Для SUBCA:

   CERTREQ -retrieve -config "ROOTCAHP Root CA" 2
   a:SubCA.crt a:chain.p7b

   Для ISSUING, введите

   CERTREQ -retrieve -config "SUBCAHP Subordinate CA"
   4 a:SubCA.crt a:chain.p7b

   Ключ -retrieve сообщает утилите о необходимости загрузить и сохранить выданный сертификат с информацией о цепочке сертификации в файлы. В приведенном выше примере номера запросов, сохраненные из пункта 1, – это 2 и 4. После номеров запроса указываются имена файлов – файл, в котором будет сохранен сертификат, и файл для сохранения информации о цепочке сертификации. Для файлов сертификатов необходимо использовать расширение .crt, а для цепочек сертификации – .p7b. Для завершения сертификации перенесите эти файлы на CA.

4. Запустить оснастку Certificate Authority, щелкнуть Tools, выбрать Install CA Sertificate и в диалоговом окне открыть сохраненный на флэш-накопителе файл chain.p7b. Поскольку сервер SUBCA отключен от локальной сети, попытка проверки файла CRL будет неудачной, при этом система выдаст запрос на продолжение сертификации. Нажмите OK. Теперь в иерархии Certificate Authority появится красный флажок вместо красной точки.

Установка выдающего CA завершена. При установке промежуточного CA придется выполнить почти те же самые действия, что и для корневого CA. Потребуется отредактировать реестр для настройки срока действия сертификата, скопировать CRL и сертификат в папку общего доступа CertEnroll и обновить адреса CDP и AIA таким образом, чтобы они указывали на доступный Web-сервер и AD для доступа к этим ресурсам.

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

Я надеюсь, что эта статья поможет читателям разобраться с вопросами реализации простой иерархии CA, которая может использоваться, например, для организации цифровой подписи электронной почты. Формирование собственного центра сертификации — это нетривиальная задача.

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

Установка серверов ca

В первую очередь устанавливается сервер ROOTCA, затем SUBCA и, наконец, сервер ISSUING. В целом процесс практически одинаков для каждого из трех CA; в табл. 2 приведены отличия в установке этих серверов, которая была произведена для построения трехуровневой иерархии нашего примера.

Для начала установки каждого из наших CA в приложении «Установка/удаление программ» в панели управления выберите закладку «Установка компонентов Windows». Выберите Certificate Services и нажмите Next. В диалоговом окне с предупреждением о том, что вы не можете изменить имя сервера или его членство в домене, следует нажать Yes.

Далее предлагается установить уровень авторизации сертификата (Certification Authority Type). Выберите тип CA в соответствии со значениями, приведенными в табл 2. После выбора типа CA отметьте флажок Advanced options (Дополнительно), как показано на экране 1, и нажмите Next (Далее). Параметр Enterprise CA будет недоступен, если компьютер не является членом домена AD.

Мастер Windows Components Wizard позволяет задать параметры пары открытый/закрытый ключ, а также выбрать провайдера службы шифрования Cryptographic Service Provider (CSP) и алгоритм, используемый для шифрования и формирования электронной подписи. Выбор различных поставщиков CSP и алгоритмов шифрования обеспечивает разные возможности, в том числе учет экспортных требований по криптостойкости ключей шифрования и поддержку внешних устройств, таких как смарт-карты для хранения ключей.

Обычно, если у пользователя нет каких-то специфических требований, можно оставить значение по умолчанию (Microsoft Base Cryptographic Provider 1.0 и SHA-1). Далее мастер позволяет установить длину ключа в соответствии со значениями, приведенными в табл. 2, после чего следует нажать Next.

На странице CA Identifying Information (Идентификация CA), изображенной на экране 2, указывается информация, которая должна быть включена в сертификат, а также информация, которую операторы CA смогут использовать для проверки полномочий при выдаче подтверждения или отказа в ответ на запрос на сертификацию.

Наиболее важным на этой станице является параметр CA name. Имя должно быть уникальным, подсистема безопасности использует его для определения местоположения соответствующего родительского сертификата в цепочке сертификации. Другие поля позволяют идентифицировать организацию (эта информация может совпадать для всех CA).

Последнее поле указывает срок действия данного корневого сертификата. Поскольку корневой CA сертифицирует сам себя, этот параметр доступен только через интерфейс ROOTCA. Продолжительность жизни сертификатов подчиненных и выдающих CA зависит от продолжительности действия родительского CA и управляется через системный реестр на серверах ROOTCA и SUBCA соответственно. Более подробно об этом будет рассказано ниже.

Для продолжения работы мастера нужно нажать Next. Процедура установки сформирует криптографический ключ и предложит указать местоположение для файлов базы данных, используемой службой сертификатов Certificate Service. Мастер позволяет разделить первичную (primary) базу данных и журнал базы транзакций.

Я рекомендую, чтобы эти файлы были размещены на различных разделах. Помимо размещения файлов базы данных необходимо указать папку общего доступа для организации точки доступа к информации авторизации Authority Information Access (AIA) для получения сертификата CA.