Создание и настройка центра сертификации (Certificate Authority, CA) в CentOS 8 — Сайт одного DevOpsa

Что такое wildcard сертификат

Ранее я вам рассказывал, что из себя представляют SSL сертификаты и там я описывал принцип работы wildcard, давайте я напомню его определение. Wildcard (Подстановочный сертификат) – это цифровой сертификат, который применяется к домену и всем его поддоменам.

Обозначение подстановочного знака состоит из звездочки и точки (*.) перед доменным именем. Сертификаты Secure Sockets Layer ( SSL ) часто используют подстановочные знаки для расширения шифрования SSL для поддоменов. Обычный SSL-сертификат работает на одном домене, например root.my-sertif.ru.

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

Например, если поддомен, такой как payment.my-sertif.ru, скомпрометирован, то это касается и поддоменов mail и vpn . Приобретение отдельных сертификатов может стоить немного больше и потребовать больше администрирования, но это также гарантирует, что каждый поддомен индивидуально защищен.

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

(необязательно) — подписание csr

На предыдущем шаге мы создали запрос тренировочного сертификата и ключ вымышленного сервера. Мы скопировали его в директорию /tmp на сервере ЦС, моделируя процесс, который мы бы использовали при отправке запросов CSR на подпись реальными клиентами или серверами.

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

Поскольку мы будем работать внутри инфраструктуры PKI в ЦС, где доступна утилита easy-rsa, мы будем использовать утилиту easy-rsa для большего удобства в отличие от использования openssl, как мы делали в предыдущем примере.

Первым шагом для подписания вымышленного CSR будет импорт запроса сертификата с помощью скрипта easy-rsa:

cd ~/easy-rsa
./easyrsa import-req /tmp/sammy-server.req sammy-server

Output

. . .
The request has been successfully imported with a short name of: sammy-server
You may now use this name to perform signing operations on this request.

Теперь вы можете подписать запрос, запустив скрипт easyrsa с опцией sign-req, указав затем тип запроса и общее имя, включаемое в CSR. Запрос может иметь тип client, server или ca. Поскольку мы тренируемся с сертификатом для вымышленного сервера, нужно использовать тип запроса server:

./easyrsa sign-req server sammy-server

В результатах вам будет предложено подтвердить, что запрос поступил из надежного источника. Для подтверждения введите yes и нажмите ENTER:

Output

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 3650 days:

subject=
    commonName                = sammy-server


Type the word 'yes' to continue, or any other input to abort.
  Confirm request details: yes
. . .
Certificate created at: /home/sammy/easy-rsa/pki/issued/sammy-server.crt

Если вы зашифровали ключ ЦС, вам будет предложено ввести пароль.

Выполнив эти шаги, мы подписали CSR sammy-server.req с помощью закрытого ключа сервера ЦС в директории /home/sammy/easy-rsa/pki/private/ca.key. Полученный файл sammy-server.crt содержит открытый ключ шифрования тренировочного сервера, а также новую подпись от сервера ЦС. Подпись сообщает всем, кто доверяет ЦС, что они также могут доверять сертификату sammy-server.

Если бы это был запрос веб-сервера, сервера VPN или другого реального сервера, последним шагом на сервере ЦС стало бы распространение новых файлов sammy-server.crt и ca.crt с сервера ЦС на удаленный сервер, отправивший запрос CSR:

scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
scp pki/ca.crt sammy@your_server_ip:/tmp

На этом этапе выпущенный сертификат можно было бы использовать с веб-сервером, сервером VPN, инструментом управления конфигурацией, СУБД, системой аутентификации клиентов и т. п.

(необязательно) — создание и подписание образца запроса сертификата

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

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

Следующие шаги будут выполняться на второй системе Linux под управлением CentOS, Fedora или другого производного от RedHat дистрибутива Linux. Это может быть другой удаленный сервер или локальная система Linux, например ноутбук или настольный компьютер.

openssl обычно устанавливается по умолчанию в большинстве дистрибутивов Linux, но для уверенности стоит запустить в системе следующую команду:

sudo dnf install openssl

Когда вам будет предложено установить openssl, введите y, чтобы продолжить выполнение установки. Теперь вы готовы создать тренировочный CSR с помощью openssl.

В первую очередь для создания CSR необходимо сгенерировать закрытый ключ. Чтобы создать закрытый ключ с помощью openssl, создайте директорию practice-csr и сгенерируйте ключ в этой директории. Мы будем выполнять этот запрос на фиктивном сервере под названием sammy-server, в отличие от случая создания сертификата для идентификации пользователя или другого ЦС.

mkdir ~/practice-csr
cd ~/practice-csr
openssl genrsa -out sammy-server.key

Output

Generating RSA private key, 2048 bit long modulus (2 primes)
. . .
. . .
e is 65537 (0x010001)

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

openssl req -new -key sammy-server.key -out sammy-server.req

Output

. . .
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:New York
Locality Name (eg, city) [Default City]:New York City
Organization Name (eg, company) [Default Company Ltd]:DigitalOcean
Organizational Unit Name (eg, section) []:Community
Common Name (eg, your name or your server's hostname) []:sammy-server
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

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

openssl req -new -key sammy-server.key -out sammy-server.req -subj 
/C=US/ST=New York/L=New York City/O=DigitalOcean/OU=Community/CN=sammy-server

Чтобы проверить содержимое CSR, вы можете прочитать файл запроса с помощью команды openssl и проверить поля внутри него:

openssl req -in sammy-server.req -noout -subject

Output

subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

Когда вас устроит тема запроса тренировочного сертификата, скопируйте файл sammy-server.req на сервер ЦС с помощью scp:

scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

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

Изучение и проверка содержимого списка crl

Если вы хотите изучить содержимое файла CRL, в том числе с целью подтверждения списка отозванных сертификатов, выполните следующую команду openssl в директории easy-rsa на вашем сервере ЦС:

cd ~/easy-rsa
openssl crl -in pki/crl.pem -noout -text

Также вы можете запустить эту команду на любом сервере или на любой системе, где установлен инструмент openssl с копией файла crl.pem. Например, если вы перенесли файл crl.pem на вторую систему и хотите убедиться в отзыве сертификата sammy-server, вы можете использовать следующий синтаксис команды openssl, указав записанный при отзыве сертификата серийный номер вместо выделенного здесь:

openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A

Output

  Serial Number: 8348B3F146A765581946040D5C4D590A
Revocation Date: Apr  1 20:48:02 2020 GMT

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

Как проверяется доверие на практике?

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

В Windows сертификаты можно просмотреть через оснастку certmgr.msc:

Если поместить сертификат в хранилище «Доверенные корневые центры сертификации», то такому центру система будет доверять. А поскольку это хранилище корневых центров сертификации, система потом будет доверять и всем объектам, которые подписаны этим сертификатом.

В ОС Ubuntu Linux сертификаты хранятся в каталоге /etc/ssl/cetrs. Причём часть из них — ссылки на другой объект:

Настройка 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):

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

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

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

Настройка аутентификации клиентов

Веб-сервер Apache поддерживает аутентификацию клиента. Это значит, что мы можем выписать клиенту сертификат SSL, а сервер сможет его проверить. Если у пользователя не будет сертификата — аутентификация не пройдёт. Для активации такой возможности надо добавить в конфиг default-ssl.conf такие опции:

SSLCACertificateFile /opt/simple_CA/ca.cer 
SSLVerifyClient require 
SSLVerifyDepth 2

После этого к сайту сможет подключиться только тот пользователь, сертификат которого:

• установлен в браузере, если клиентом является браузер, — тогда сертификат будет предъявлен при подключении к серверу;
• подписан сертификатом доверенного УЦ.

Сначала сгенерируем сертификат для клиента. Первым делом создаём ключ:

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

Затем на основе ключа сгенерируем CSR:

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

Теперь на базе запроса сгенерируем сам сертификат:

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

И импортируем сертификат в формате p12:

root@shpc:/opt/simple_CA# openssl pkcs12 -export-inkey client.key -in client.cer -out client.p12 

В итоге у нас должен получиться файл client.p12. Нужно поменять права на файл, иначе сертификат не импортируется:

root@shpc:/opt/simple_CA# chmod555 client.p12

Теперь можно импортировать его в браузер по аналогии с корневыми сертификатами:

После импорта должно получиться примерно так:

После этого перезапускаем веб-сервер и возвращаемся на сайт. Видим окно выбора сертификата того пользователя, которого мы импортировали в браузер:

Обновление сервисов, поддерживающих crl

Перечень необходимых шагов для обновления сервисов, использующих файл crl.pem, не входит в содержание этого руководства. Обычно требуется скопировать файл crl.pem в место, где сервис ожидает его найти, а затем перезапустить сервис с помощью systemctl.

После обновления сервиса с указанием нового файла crl.pem этот сервис будет отклонять запросы подключения от клиентов и серверов, на которых используется отозванный сертификат.

Разворачиваем собственный цс

Чтобы лучше понять все процессы, лежащие в основе PKI, рассмотрим на практике развёртывание небольшого ЦС на виртуальной машине под управлением Ubuntu 18 (без выхода в глобальную сеть). Мы не будем жёстко придерживаться правил и стандартов выдачи сертификатов — просто разберём работу с ними.

С учетом того, что. все эксперименты мы проводим в виртуальной среде (без выхода в глобальную сеть), мы можем использовать любое доменное имя — например www.simple.org. Однако надо помнить, что в глобальной сети такое имя вполне может быть зарегистрировано за каким-нибудь сайтом.

Центры сертификации: как они используются

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

Допустим, условная сущность Аlice имеет сертификат, подписанный ЦС Comp, а сущность Bob пытается проверить подлинность этого сертификата. Проверка будет успешной, если Bob и Alice доверяют одному и тому же ЦС. Для решения такой проблемы в ОС Alice и ОС Bob установлено множество сертификатов различных ЦС.

Шаг 1 — установка easy-rsa

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

Шаг 1: обновите свою систему

Сначала обновите систему Ubuntu, выполните следующую команду:

apt update

Вы можете пропустить этот шаг, если устанавливаете easy-rsa из официального репозитория.

Шаг 3 — создание центра сертификации

Прежде чем создавать закрытый ключ и сертификат ЦС, необходимо создать файл с именем vars и заполнить его значениями по умолчанию. Используйте команду cd для перехода в директорию easy-rsa, а затем создайте и отредактируйте файл vars с помощью nano или другого предпочитаемого текстового редактора:

Предоставляемый с CentOS 8 по умолчанию текстовый редактор — vi. vi является очень мощным текстовым редактором, но освоить работу с ним неопытным пользователям достаточно сложно. Вы можете установить более удобный для пользователя редактор, например nano, для облегчения редактирования файлов конфигурации на сервере CentOS 8:

sudo dnf install nano

Когда вам будет предложено установить nano, введите y, чтобы продолжить выполнение установки. Теперь вы готовы к редактированию файла vars:

cd ~/easy-rsa
nano vars

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

Шаг 3: настройка сервера уц

Здесь мы настроим каталог инфраструктуры публичных ключей и создадим публичный/частный сертификат для сервера CA.

Теперь измените каталог на easy-rsa, который был создан ранее:

cd easy-rsa

Мы создадим файл vars, который будет использоваться для хранения информации об организации

$ cp vars.example vars

Теперь добавьте информацию об организации в конец файла

$ vim vars

Шаг 4 — распространение публичного сертификата центра сертификации

Мы настроили ЦС и можем использовать его в качестве корня доверия для любых систем, которые захотим настроить для этого. Сертификат ЦС можно добавлять на серверы OpenVPN, веб-серверы, почтовые серверы и т. д. Каждый пользователь или сервер, которому потребуется подтвердить подлинность другого пользователя или сервера в вашей сети, должен иметь копию файла ca.crt, импортированную в хранилище сертификатов операционной системы.

Чтобы импортировать публичный сертификат ЦС во вторую систему Linux, например на сервер или локальный компьютер, нужно предварительно получить копию файла ca.crt с сервера ЦС. Вы можете использовать команду cat для ее вывода в терминал, а затем скопировать и вставить ее в файл на втором компьютере, который импортирует сертификат.

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

Шаг 4: импорт публичного сертификата уц

Теперь мы получили сгенерированный публичный сертификат, и нам нужно импортировать его на другой сервер.

Войдите на сервер, на который вы хотите импортировать сертификат, затем выполните удаленное копирование файла ca.crt с сервера CA.

scp itsecforu@X.Y.Z.T:/opt/easy-rsa/pki/ca.crt

The authenticity of host 'X.Y.Z.T (X.Y.Z.T)' can't be established.
 ECDSA key fingerprint is SHA256:ffUgP5/d0Z3miOKqxBVoF9JbFvIZFs/gxr7ESBZ0kmQ.
 Are you sure you want to continue connecting (yes/no)? yes
 Warning: Permanently added '139.177.204.145' (ECDSA) to the list of known hosts.
itsecforu@X.Y.Z.T's password: 
 ca.crt    

Переместите файл сертификата в каталог /usr/local/share/ca-certificates/:

sudo mv ca.crt /usr/local/share/ca-certificates/

Теперь импортируйте сертификат сервера CA с помощью следующей команды:

sudo update-ca-certificates

Updating certificates in /etc/ssl/certs…
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d…
done.

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

(необязательно) — создание запросов на подписание сертификатов и отзыв сертификатов

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

Заключение

В этом руководстве мы узнали, как создать частный центр сертификации (ЦС) на Ubuntu 20.04.

Оставляйте свои отзывы и предложения в разделе комментариев.

(необязательно) — отзыв сертификата

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

Далее кратко описана процедура отзыва сертификата:

1. Для отзыва сертификата используется команда ./easyrsa revoke client_name.
2. Сгенерируйте новый CRL с помощью команды ./easyrsa gen-crl.
3. Переместите обновленный файл crl.pem на сервер или серверы, использующие ваш ЦС, а на этих системах скопируйте этот файл в директорию или директории программ, которые на него ссылаются.
4. Перезапустите все службы, использующие ваш ЦС и файл CRL.

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

Отзыв сертификата

Для отзыва сертификата перейдите в директорию easy-rsa на вашем сервере ЦС:

cd ~/easy-rsa

Затем запустите скрипт easyrsa с опцией revoke, указав имя клиента, у которого хотите отозвать сертификат: В соответствии с приведенным выше практическим примером, сертификат имеет обычное имя sammy-server:

./easyrsa revoke sammy-server

Система предложит вам подтвердить отзыв сертификата. Введите yes:

Output

Please confirm you wish to revoke the certificate with the following subject:

subject=
    commonName                = sammy-server


Type the word 'yes' to continue, or any other input to abort.
  Continue with revocation: yes
. . .
Revoking Certificate 8348B3F146A765581946040D5C4D590A
. . .

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

После подтверждения действия ЦС выполнит отзыв сертификата. Однако удаленные системы, использующие ЦС, не имеют возможности проверить отзыв сертификатов. Пользователи и серверы смогут использовать этот сертификат, пока список отзыва сертификатов ЦС (CRL) не будет распространен по всем системам, использующим данный ЦС.

На следующем шаге мы сгенерируем CRL или обновим существующий файл crl.pem.

Передача списка отзыва сертификатов

Мы сгенерировали список CRL на сервере ЦС, и теперь нам нужно передать его на удаленные системы, использующие ваш ЦС. Для передачи этого файла на ваши серверы можно использовать команду scp.

Примечание. В этом руководстве описывается генерирование и распространение списка CRL вручную. Хотя существуют более надежные автоматические методы распространения и проверки списков отзыва (например, OCSP-Stapling), настройка этих методов не входит в состав данного руководства.

Генерирование списка отзыва сертификатов

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

Чтобы сгенерировать CRL, запустите команду easy-rsa с опцией gen-crl, оставаясь в директории ~/easy-rsa:

./easyrsa gen-crl

Если вы использовали фразу-пароль при создании файла ca.key, вам будет предложено ввести ее. Команда gen-crl сгенерирует файл с именем crl.pem, содержащий обновленный список отозванных сертификатов для этого ЦС.

Далее вам нужно будет передавать обновленный файл crl.pem на все серверы и клиенты, использующие этот ЦС, при каждом запуске команды gen-crl. В противном случае клиенты и системы сохранят доступ к сервисам и системам, использующим ваш ЦС, так как данным сервисам нужно сообщить об отзыве сертификата.