Введение
Центр сертификации (ЦС) — это служба, отвечающая за выдачу цифровых сертификатов удостоверения личности в Интернете. Хотя публичные ЦС часто используются для подтверждения подлинности сайтов и других общедоступных служб, для закрытых групп и частных служб обычно используются частные ЦС.
Создание частного ЦС позволит вам настраивать, тестировать и запускать программы, требующие шифрованного канала связи между клиентом и сервером. Частный ЦС позволяет выпускать сертификаты для пользователей, серверов или отдельных программ и служб в вашей инфраструктуре.
Существует множество программ для Linux, использующих частные ЦС, в том числе OpenVPN и Puppet. Также вы можете настроить веб-сервер для использования сертификатов, выпущенных частным ЦС, с целью обеспечить соответствие сред разработки и тестирования и производственных сред, где используется служба TLS для шифрования соединений.
Из этого руководства мы узнаем, как настроить частный Центр сертификации на сервере Debian 10, а также как сгенерировать и подписать сертификат тестирования, используя новый ЦС. Также вы научитесь импортировать публичный сертификат сервера ЦС в хранилище сертификатов операционной системы, чтобы проверять цепочку доверия между ЦС и удаленными серверами или пользователями. Кроме того, вы научитесь отзывать сертификаты и распространять Список отзыва сертификатов, чтобы службы на основе вашего ЦС могли использовать только уполномоченные пользователи и системы.
Предварительные требования
В настоящем обучающем руководстве мы будем называть его сервер ЦС.
Сервер ЦС должен представлять собой отдельную систему. Она будет использоваться только для импорта, подписания и отзыва запросов сертификатов. На ней не должны работать никакие другие службы, и в идеале ее следует отключать от сети или полностью отключать в периоды, когда вы активно не работаете с ЦС.
Примечание. Последний раздел этого обучающего руководства необязательный. Из него вы сможете узнать о подписании и отзыве сертификатов. Если вы решите выполнить эти практические шаги, вам потребуется второй сервер Debian 10. Также вы можете использовать собственный локальный компьютер Linux под управлением Debian, Ubuntu или их производных дистрибутивов.
Шаг 1 — Установка Easy-RSA
Первая задача этого обучающего руководства заключается в установке набора скриптов easy-rsa
для запуска на сервере ЦС. Мы будем использовать инструмент управления ЦС easy-rsa
для генерирования частного ключа и публичного корневого сертификата, с помощью которых вы будете подписывать запросы клиентов и серверов, использующих ваш ЦС.
- update
- easy-rsa
Вам будет предложено загрузить пакет и установить его. Нажмите y
, чтобы подтвердить установку пакета.
Теперь у вас есть все необходимое для настройки и использования Easy-RSA. На следующем шаге мы создадим инфраструктуру открытых ключей, а затем приступим к созданию Центра сертификации.
Шаг 2 — Подготовка директории для инфраструктуры открытых ключей
- ~/easy-rsa
Создайте символические ссылки с помощью команды ln
:
- /usr/share/easy-rsa/* ~/easy-rsa/
Примечание. Хотя другие руководства могут предписывать скопировать файлы пакета easy-rsa
в директорию PKI, в этом обучающем руководстве мы используем подход на основе символических ссылок. Таким образом, любые изменения пакета easy-rsa
будут автоматически отражаться в ваших скриптах PKI.
Чтобы ограничить доступ к созданной директории PKI, используйте команду chmod
для предоставления доступа к ней только владельцу:
- /home/sammy/easy-rsa
Затем инициализируйте PKI в директории easy-rsa
:
- ~/easy-rsa
- ./easyrsa init-pki
init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /home/sammy/easy-rsa/pki
После выполнения указаний этого раздела у нас будет директория, содержащая все необходимые файлы для создания Центра сертификации. На следующем шаге мы создадим закрытый ключ и публичный сертификат для ЦС.
Шаг 3 — Создание Центра сертификации
Прежде чем создавать закрытый ключ и сертификат ЦС, необходимо создать файл с именем vars
и заполнить его значениями по умолчанию. Используйте команду cd
для перехода в директорию easy-rsa
, а затем создайте и отредактируйте файл vars
с помощью nano
или другого предпочитаемого текстового редактора:
- ~/easy-rsa
- vars
Открыв файл, вставьте следующие строки и измените каждое выделенное значение для отражения информации о вашей организации. При этом важно, чтобы ни одно значение не оставалось пустым:
set_var EASYRSA_REQ_COUNTRY "US"
set_var EASYRSA_REQ_PROVINCE "NewYork"
set_var EASYRSA_REQ_CITY "New York City"
set_var EASYRSA_REQ_ORG "DigitalOcean"
set_var EASYRSA_REQ_EMAIL "admin@example.com"
set_var EASYRSA_REQ_OU "Community"
После завершения редактирования сохраните и закройте файл. Если вы используете nano
, вы можете сделать это, нажав CTRL+X
, а затем Y
и ENTER
для подтверждения. Теперь вы готовы к созданию ЦС.
Для создания корневой пары открытого и закрытого ключей для Центра сертификации необходимо запустить команду ./easy-rsa
еще раз, но уже с опцией build-ca
:
- ./easyrsa build-ca
Вы увидите несколько строк с указанием версии OpenSSL, а затем вам будет предложено ввести фразу-пароль для пары ключей. Используйте надежную фразу-пароль и запишите ее в безопасном месте. Вам нужно будет вводить фразу-пароль каждый раз, когда вам потребуется взаимодействовать с ЦС, в частности при подписании или отзыве сертификата.
Также вам будет предложено подтвердить обычное имя (CN) вашего ЦС. CN — это имя, которое будет использоваться для данного компьютера в контексте Центра сертификации. Вы можете использовать любую строку символов как обычное имя ЦС, но для простоты нажмите ENTER, чтобы использовать имя по умолчанию.
. . .
Enter New CA Key Passphrase:
Re-Enter New CA Key Passphrase:
. . .
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:
CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/home/sammy/easy-rsa/pki/ca.crt
Примечание. Если вы не хотите вводить пароль при каждом взаимодействии с ЦС, вы можете запустить команду build-ca
с опцией nopass
:
- ./easyrsa build-ca nopass
Теперь у нас имеется два важных файла, ~/easy-rsa/pki/ca.crt
и ~/easy-rsa/pki/private/ca.key
. Эти файлы соответствуют публичному и частному компонентам Центра сертификации.
-
ca.crt
— файл публичного сертификата ЦС. Пользователи, серверы и клиенты будут использовать этот сертификат для подтверждения единой сети доверия. Копия этого файла должна иметься у всех пользователей и серверов, использующих ваш ЦС. Все стороны будут использовать публичный сертификат для подтверждения подлинности системы и предотвращения атак через посредника. -
ca.key
— закрытый ключ, который ЦС будет использовать для подписания сертификатов серверов и клиентов. Если злоумышленник получит доступ к ЦС и файлуca.key
, вам нужно будет уничтожить ЦС. Поэтому файлca.key
должен храниться только на компьютере ЦС, и для дополнительной безопасности компьютер ЦС следует выключать, когда он не используется для подписания запросов сертификатов.
Мы установили ЦС и готовы использовать его для подписания запросов сертификатов и отзыва сертификатов.
Шаг 4 — Распространение публичного сертификата Центра сертификации
Мы настроили ЦС и можем использовать его в качестве корня доверия для любых систем, которые захотим настроить для этого. Сертификат ЦС можно добавлять на серверы OpenVPN, веб-серверы, почтовые серверы и т. д. Каждый пользователь или сервер, которому потребуется подтвердить подлинность другого пользователя или сервера в вашей сети, должен иметь копию файла ca.crt
, импортированную в хранилище сертификатов операционной системы.
Чтобы импортировать публичный сертификат ЦС во вторую систему Linux, например на сервер или локальный компьютер, нужно предварительно получить копию файла ca.crt
с сервера ЦС. Вы можете использовать команду cat
для ее вывода в терминал, а затем скопировать и вставить ее в файл на втором компьютере, который импортирует сертификат. Также вы можете использовать scp
, rsync
и другие подобные инструменты для передачи файла между системами. Мы используем для копирования и вставки текстовый редактор nano
, поскольку этот вариант подойдет для всех систем.
- ~/easy-rsa/pki/ca.crt
На терминале появится примерно следующее:
-----BEGIN CERTIFICATE-----
MIIDSzCCAjOgAwIBAgIUcR9Crsv3FBEujrPZnZnU4nSb5TMwDQYJKoZIhvcNAQEL
BQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMjAwMzE4MDMxNjI2WhcNMzAw
. . .
. . .
-----END CERTIFICATE-----
Скопируйте все, включая строки -----BEGIN CERTIFICATE-----
и -----END CERTIFICATE-----
и символы дефиса.
Используйте nano
или предпочитаемый текстовый редактор на второй системе Linux, чтобы открыть файл с именем /tmp/ca.crt
:
- /tmp/ca.crt
Вставьте в редактор содержимое, скопированное вами из сервера ЦС. После завершения редактирования сохраните и закройте файл. Если вы используете nano
, вы можете сделать это, нажав CTRL+X
, а затем Y
и ENTER
для подтверждения.
Теперь у нас имеется копия файла ca.crt
на второй системе Linux, и мы можем импортировать сертификат в хранилище сертификатов операционной системы.
В системах под управлением Debian и Ubuntu для импорта сертификата нужно использовать следующие команды:
Debian and Ubuntu derived distributions
- /tmp/ca.crt /usr/local/share/ca-certificates/
- update-ca-certificates
Чтобы импортировать сертификат сервера ЦС в систему на базе CentOS, Fedora или RedHat, скопируйте и вставьте содержимое файла в файл /tmp/ca.crt
, как описано в предыдущем примере. Затем скопируйте сертификат в директорию /etc/pki/ca-trust/source/anchors/
и запустите команду update-ca-trust
.
CentOS, Fedora, RedHat distributions
- /tmp/ca.crt /etc/pki/ca-trust/source/anchors/
- update-ca-trust
Теперь вторая система Linux будет доверять любому сертификату, подписанному нашим сервером ЦС.
Примечание. Если вы используете ЦС с веб-серверами и браузер Firefox, вам нужно будет импортировать публичный сертификат ca.crt
в Firefox напрямую. Firefox не использует локальное хранилище сертификатов операционной системы. Подробную информацию о добавлении сертификата ЦС в Firefox можно найти в статье поддержки Mozilla Настройка Центров сертификации (ЦС) в Firefox.
Если вы используете ЦС для интеграции со средой Windows или настольными компьютерами, ознакомьтесь с документацией по использованию certutil.exe
для установки сертификата ЦС.
(Необязательно) — Создание запросов на подписание сертификатов и отзыв сертификатов
Следующие разделы этого обучающего руководства являются необязательными. Если вы выполнили все предыдущие шаги, у вас имеется полностью настроенный и работающий Центр сертификации, который вы сможете использовать для выполнения других обучающих руководств. Вы можете импортировать файл ca.crt
вашего ЦС и проверить сертификаты в вашей сети, которые были подписаны вашим ЦС.
(Необязательно) — Создание и подписание образца запроса сертификата
Мы настроили ЦС для использования и теперь можем попробовать сгенерировать закрытый ключ и запрос сертификата, чтобы познакомиться с процессом подписания и распространения.
Запрос на подписание сертификата (CSR) состоит из трех частей, а именно открытого ключа, идентификационной информации запрашивающей системы и подписи запроса, создаваемой на основе закрытого ключа запрашивающей системы. Закрытый ключ остается секретным, и его можно будет использовать для шифрования информации, которую сможет расшифровать любой пользователь с подписанным открытым сертификатом.
Следующие шаги будут выполняться на второй системе Linux с Debian, Ubuntu или одним из производных дистрибутивов. Это может быть другой удаленный сервер или локальная система Linux, например ноутбук или настольный компьютер. Поскольку по умолчанию easy-rsa
доступна не на всех системах, мы используем инструмент openssl
для создания тренировочного закрытого ключа и сертификата.
openssl
обычно устанавливается по умолчанию в большинстве дистрибутивов Linux, но для уверенности стоит запустить в системе следующую команду:
- update
- openssl
Когда вам будет предложено установить openssl
, введите y
, чтобы продолжить выполнение установки. Теперь вы готовы создать тренировочный CSR с помощью openssl
.
В первую очередь для создания CSR необходимо сгенерировать закрытый ключ. Чтобы создать закрытый ключ с помощью openssl
, создайте директорию practice-csr
и сгенерируйте ключ в этой директории. Мы будем выполнять этот запрос на фиктивном сервере под названием sammy-server
, в отличие от случая создания сертификата для идентификации пользователя или другого ЦС.
- ~/practice-csr
- ~/practice-csr
- openssl genrsa sammy-server.key
Generating RSA private key, 2048 bit long modulus (2 primes)
. . .
. . .
e is 65537 (0x010001)
Теперь у нас имеется закрытый ключ, с помощью которого можно создать CSR, используя утилиту openssl
. Вам будет предложено заполнить ряд полей, в том числе указать страну, область и город. Вы можете ввести .
, если хотите оставить поле пустым, но для реальных CSR лучше использовать правильные значения при указании своего расположения и организации:
- openssl req sammy-server.key sammy-server.req
. . .
-----
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 sammy-server.key server.req
- /CUS/STNew York/LNew York City/ODigitalOcean/OUCommunity/CNsammy-server
Чтобы проверить содержимое CSR, вы можете прочитать файл запроса с помощью команды openssl
и проверить поля внутри него:
- openssl req sammy-server.req
subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server
Когда вас устроит тема запроса тренировочного сертификата, скопируйте файл sammy-server.req
на сервер ЦС с помощью scp
:
- sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req
На этом шаге вы сгенерировали запрос подписи сертификата для вымышленного сервера sammy-server
. В реальной ситуации запрос может исходить от веб-сервера разработки, которому требуется сертификат TLS для тестирования, или от сервера OpenVPN, который запрашивает сертификат, чтобы пользователи могли подключиться к VPN. На следующем шаге мы перейдем к подписанию запроса на подписание сертификата с использованием закрытого ключа сервера ЦС.
(Необязательно) — Подписание CSR
На предыдущем шаге мы создали запрос тренировочного сертификата и ключ вымышленного сервера. Мы скопировали его в директорию /tmp
на сервере ЦС, моделируя процесс, который мы бы использовали при отправке запросов CSR на подпись реальными клиентами или серверами.
Продолжим рассматривать вымышленный сценарий. Теперь серверу ЦС необходимо импортировать тренировочный сертификат и подписать его. Когда ЦС подтвердит сертификат и отправит ответ серверу, клиенты, доверяющие Центру сертификации, смогут также доверять новому сертификату.
Поскольку мы будем работать внутри инфраструктуры PKI в ЦС, где доступна утилита easy-rsa
, мы будем использовать утилиту easy-rsa
для большего удобства в отличие от использования openssl
, как мы делали в предыдущем примере.
Первым шагом для подписания вымышленного CSR будет импорт запроса сертификата с помощью скрипта easy-rsa
:
- ~/easy-rsa
- ./easyrsa import-req /tmp/sammy-server.req sammy-server
. . .
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
:
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:
- pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
- pki/ca.crt sammy@your_server_ip:/tmp
На этом этапе выпущенный сертификат можно было бы использовать с веб-сервером, сервером VPN, инструментом управления конфигурацией, СУБД, системой аутентификации клиентов и т. п.
(Необязательно) — Отзыв сертификата
Иногда сертификат требуется отозвать, чтобы пользователь или сервер не могли его использовать. Например, это может потребоваться в случае кражи ноутбука, взлома веб-сервера, увольнения сотрудника, расторжения договора с подрядчиком и т. д.
Далее кратко описана процедура отзыва сертификата:
- Для отзыва сертификата используется команда
./easyrsa revoke client_name
. - Сгенерируйте новый CRL с помощью команды
./easyrsa gen-crl
. - Переместите обновленный файл
crl.pem
на сервер или серверы, использующие ваш ЦС, а на этих системах скопируйте этот файл в директорию или директории программ, которые на него ссылаются. - Перезапустите все службы, использующие ваш ЦС и файл CRL.
С помощью этой процедуры вы можете отозвать любые сертификаты, которые ранее выпустили для вашего сервера. В следующих разделах мы подробно рассмотрим каждый шаг, начиная с команды revoke
.
Отзыв сертификата
Для отзыва сертификата перейдите в директорию easy-rsa
на вашем сервере ЦС:
- ~/easy-rsa
Затем запустите скрипт easyrsa
с опцией revoke
, указав имя клиента, у которого хотите отозвать сертификат: В соответствии с приведенным выше практическим примером, сертификат имеет обычное имя sammy-server
:
- ./easyrsa revoke sammy-server
Система предложит вам подтвердить отзыв сертификата. Введите yes
:
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, запустите команду easy-rsa
с опцией gen-crl
, оставаясь в директории ~/easy-rsa
:
- ./easyrsa gen-crl
Если вы использовали фразу-пароль при создании файла ca.key
, вам будет предложено ввести ее. Команда gen-crl
сгенерирует файл с именем crl.pem
, содержащий обновленный список отозванных сертификатов для этого ЦС.
Далее вам нужно будет передавать обновленный файл crl.pem
на все серверы и клиенты, использующие этот ЦС, при каждом запуске команды gen-crl
. В противном случае клиенты и системы сохранят доступ к сервисам и системам, использующим ваш ЦС, так как данным сервисам нужно сообщить об отзыве сертификата.
Передача списка отзыва сертификатов
Мы сгенерировали список CRL на сервере ЦС, и теперь нам нужно передать его на удаленные системы, использующие ваш ЦС. Для передачи этого файла на ваши серверы можно использовать команду scp
.
Примечание. В этом обучающем руководстве описывается генерирование и распространение списка CRL вручную. Хотя существуют более надежные автоматические методы распространения и проверки списков отзыва (например OCSP-Stapling), настройка этих методов не входит в состав данного обучающего руководства.
- ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp
Теперь файл передан на удаленную систему и нужно только отправить новую копию списка отзыва во все сервисы.
Обновление сервисов, поддерживающих CRL
Перечень необходимых шагов для обновления сервисов, использующих файл crl.pem
, не входит в содержание этого обучающего руководства. Обычно требуется скопировать файл crl.pem
в место, где сервис ожидает его найти, а затем перезапустить сервис с помощью systemctl
.
После обновления сервиса с указанием нового файла crl.pem
этот сервис будет отклонять запросы подключения от клиентов и серверов, на которых используется отозванный сертификат.
Изучение и проверка содержимого списка CRL
Если вы хотите изучить содержимое файла CRL, в том числе с целью подтверждения списка отозванных сертификатов, выполните следующую команду openssl
в директории easy-rsa
на вашем сервере ЦС:
- ~/easy-rsa
- openssl crl pki/crl.pem
Также вы можете запустить эту команду на любом сервере или на любой системе, где установлен инструмент openssl
с копией файла crl.pem
. Например, если вы перенесли файл crl.pem
на вторую систему и хотите убедиться в отзыве сертификата sammy-server
, вы можете использовать следующий синтаксис команды openssl
, указав записанный при отзыве сертификата серийный номер вместо выделенного здесь:
- openssl crl /tmp/crl.pem 8348B3F146A765581946040D5C4D590A
Serial Number: 8348B3F146A765581946040D5C4D590A
Revocation Date: Apr 1 20:48:02 2020 GMT
Обратите внимание на использование команды grep
для проверки уникального серийного номера, записанного на шаге отзыва. Теперь вы можете подтвердить содержимое списка отзыва сертификатов на любой системе, использующей его для ограничения доступа к пользователям и сервисам.
Заключение
В этом обучающем руководстве мы создали частный Центр сертификации на отдельном сервере Debian 10 с помощью пакета Easy-RSA. Мы узнали, как работает модель доверия между сторонами, полагающимися на ЦС. Также мы создали и подписали запрос на подписание сертификата (CSR) для вымышленного сервера и научились отзывать сертификаты. Наконец, мы научились генерировать и распространять списки отзыва сертификатов (CRL) на любых системах, использующих наш ЦС, чтобы предотвратить доступ к сервисам пользователей и серверов, которым он не разрешен.
Теперь вы можете выдавать сертификаты пользователям и использовать их в OpenVPN и других подобных сервисах. Также вы можете использовать свой ЦС для настройки веб-серверов разработки и тестирования с помощью сертификатов, чтобы защитить свои непроизводственные среды. Использование ЦС с сертификатами TLS во время разработки поможет обеспечить максимальное соответствие вашего кода и сред разработки и тестирования производственной среде.
Если вам требуется дополнительная информация об использовании OpenSSL, вам будет полезно наше обучающее руководство Основы OpenSSL: работа с сертификатами SSL, закрытыми ключами и запросами CSR, который поможет вам лучше познакомиться с основами OpenSSL.
Корневые сертификаты
Корневые сертификаты ФК
Инструкция по установке КриптоПро
Установка сертификатов используя КриптоПРО в Linux
Получить тестовый сертификат
Сертификаты zakupki.gov.ru
Для установки в uRoot админиских прав больше не нужно. Ради этого их с mRoot и разделили. Работает так: если ставить в uRoot — видно будет только текущему пользователю, даже если он root, но права не нужны и будет диалог с предупреждением. Если ставить в mRoot, то нужны права, видно будет всем и предупреждения не будет.
Установка корневого сертификата удостоверяющего центра:
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file ~/Загрузки/<название файла>.cer -store uRoot
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file ~/Загрузки/guts_2012.cer -store uRoot
Просмотор корневых сертификатов:
$ /opt/cprocsp/bin/amd64/certmgr -list -store uRoot
Удалить:
$ /opt/cprocsp/bin/amd64/certmgr -delete -store uRoot
$ /opt/cprocsp/bin/amd64/certmgr -delete -all -store uRoot
Установка списка отозванных сертификатов:
$ /opt/cprocsp/bin/amd64/certmgr -inst -crl -file ~/Загрузки/<название файла>.crl
Установка цепочки промежуточных сертификатов:
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file ~/Загрузки/<название файла>.p7b -store uca
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file ~/Загрузки/fk_2012.cer -store uca
Просмотор промежуточных сертификатов:
$ /opt/cprocsp/bin/amd64/certmgr -list -store uca
Удалить:
$ /opt/cprocsp/bin/amd64/certmgr -delete -store uca
Установка сертификата с рутокена:
$ /opt/cprocsp/bin/amd64/certmgr -inst -cont ‘<путь к контейнеру, начинающийся на \\.\>’ -store uMy
Установка сертификата из контейнера:
$ /opt/cprocsp/bin/amd64/certmgr -inst -store uMy -cont ‘\\.\HDIMAGE\test’
Просмотор личных сертификатов:
$ /opt/cprocsp/bin/amd64/certmgr -list -store uMy
Просмотр контейнеров, рутокенов
$ /opt/cprocsp/bin/amd64/csptest -keyset -enum -verifycontext -fqcn
Экспорт в файл сертификата из хранилища
$ /opt/cprocsp/bin/amd64/certmgr -export -cert -dn «CN=» -dest ‘cert.crt’
$ /opt/cprocsp/bin/amd64/cryptcp -copycert -dn CN=’Фёдорова Галина Борисовна’ -df ~/t.cer
$ CP_PRINT_CHAIN_DETAIL=1 /opt/cprocsp/bin/amd64/cryptcp -copycert -dn CN=’Фёдорова Галина Борисовна’ -df ~/t.cer
$ CP_PRINT_CHAIN_DETAIL=1 /opt/cprocsp/bin/amd64/cryptcp -copycert -dn CN=’Фёдорова Галина Борисовна’ -df ~/t.cer
Установка сертификатов zakupki.gov.ru
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file ‘Сертификат Головного удостоверяющего центра.cer’ -store uRoot
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file ‘Сертификат Удостоверяющего центра Федерального казначейства.cer’ -store uRoot
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file root2013.cer -store uRoot
В наше время одним из самых важных аспектов безопасной передачи информации является шифрование. Данные при передаче от клиента к серверу зашифровываются с помощью SSL-сертификата. Сертификат – это публичный ключ, заверенный удостоверяющим центром.
Все SSL-сертификаты, как правило, выдаются на ограниченный срок, по окончании которого они теряют силу и должны быть переизданы. Однако бывают случаи, когда сертификат может быть отозван ещё до окончания срока действия. Причин на отзыв SSL-сертификата довольно много, самые распространённые из них – закрытый ключ был утерян или скомпрометирован, изменились регистрационные данные компании и т.п.
Существует 2 альтернативных способа проверить, находится ли SSL-сертификат в списках отзыва:
- CRL (Certificate Revocation List) – проверяется наличие серийного номера сертификата в списке отзыва.
- OCSP (Online Certificate Status Protocol) – сертификат отправляется на специализированный сервер, где проверяется его статус.
Рассмотрим оба эти способа более подробно с помощью консоли Ubuntu. А в качестве примера проверим на отзыв сертификат для домена habr.com.
CRL
Скачаем сертификат интересующего нас домена:
echo -n | openssl s_client -connect habr.com:443 -servername habr.com 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/habr.com.crt
Смотрим детали сертификата:
openssl x509 -noout -text -in /tmp/habr.com.crt
Здесь нас интересует в разделе «X509v3 CRL Distribution Points» пункт «Full Name».
Скачиваем по этой ссылке список CLR:
wget http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl
Выдираем серийный номер сертификата:
openssl x509 -in /tmp/habr.com.crt -noout -serial
Смотрим, есть ли этот номер в списке CRL:
openssl crl -inform DER -text -in COMODORSADomainValidationSecureServerCA.crl | grep "90E58B0601C3AD98F07AEE092041C437"
Если ничего не нашлось, значит сертификат не является отозванным.
OCSP
Выведем на экран сертификат интересующего нас домена и цепочки промежуточных (Intermediate) сертификатов:
echo -n | openssl s_client -connect habr.com:443 -showcerts
Сохраним в файлы сертификат домена и промежуточный сертификат (код между строками ——BEGIN CERTIFICATE—— и ——END CERTIFICATE——):
/tmp/habr.com.crt
/tmp/intermediate.crt
openssl x509 -in /tmp/habr.com.crt -noout -ocsp_uri
Отправим запрос OCSP-серверу проверить сертификат на предмет отзыва:
openssl ocsp -url http://ocsp.comodoca.com -issuer /tmp/intermediate.crt -cert /tmp/habr.com.crt -text
Если всё указали правильно, то OCSP-сервер должен вернуть информацию по сертификату.
Здесь интерес представляют последние строчки:
Response verify OK
/tmp/habr.com.crt: good
Об отсутствии сертификата в списке отозванных говорит значение «good», если же сертификат отозвали, то значение будет «revoked».
Автоматизация
Проверять SSL-сертификаты на предмет отзыва вручную не всегда удобно, поэтому процесс проверки можно автоматизировать.
Для этого берём с Github готовый скрипт ssl-check-revoc.sh, который осуществляет проверку сертификатов методом CRL:
wget https://raw.githubusercontent.com/o-pod/security/master/ssl-check-revoc.sh
Далее делаем скрипт исполняемым:
chmod a+x ssl-check-revoc.sh
Теперь можно проверять как уже установленные сертификаты для домена, так и сохранённые локально в файлы (опция -f):
./ssl-check-revoc.sh habr.com -v
Zabbix
Скрипт ssl-check-revoc.sh может проверять сертификаты не только из консоли, он также вполне подходит в качестве чекера для Zabbix, поэтому всю грязную работу по отслеживанию попадания сертификатов в список отзыва можно поручить системе мониторинга.
Заходим в конфиг Zabbix /etc/zabbix/zabbix_server.conf и смотрим, где лежат скрипты для внешних проверок:
ExternalScripts=/etc/zabbix/externalscripts
Копируем в этот каталог наш скрипт и рестартуем Zabbix:
sudo cp ssl-check-revoc.sh /etc/zabbix/externalscripts/
sudo systemctl restart zabbix-server
Также понадобятся два триггера:
Не забываем в экшенах (Configuration >> Actions) настроить способ оповещения в случае срабатывания триггеров.
Теперь осталось создать хосты, сертификаты которых будем регулярно проверять (Configuration >> Hosts >> Create host). На вкладке Templates прилинковываем наш темплейт «Template SSL Checking».
И всё! Можно спать спокойно: если SSL-сертификат вашего домена по какой-либо причине попадёт в список отозванных, Zabbix сразу же вам сообщит.
Корневые сертификаты
Инструкции по установке сертификатов
Для Windows
Для macOS
Квалифицированные корневые сертификаты для ГОСТ Р 34. 10-2012
КриптоПРО
VipNet
Промежуточный сертификат ФНС
Остались вопросы? Как мы можем помочь?
Как мы можем помочь?
Списки отзыва сертификатов (СОС)
Оглавление
1. OpenSSL: инструкция по использованию и аудит безопасности
2. Что такое OpenSSL и для чего используется
3. Как работают SSL сертификаты
4. Как генерировать сертификаты в OpenSSL
5. Какую команду использовать, genpkey или genrsa
6. Как пользоваться OpenSSL (команды OpenSSL)
7. Как создать сертификаты SSL (TLS) для сайтов
8. Рецепты и советы по генерации SSL сертификатов
8.1 Создание запроса на подпись (CSR) из существующих сертификатов
8.2 Автоматическая генерация CSR
8.3 Создание сертификатов, действительных для нескольких имён хостов
8.5 Как получить бесплатный валидный сертификат для сайта
9. Просмотр содержимого ключей и сертификатов
10. Форматы ключей и сертификатов
11. Конвертация ключей и сертификатов
11.1 PEM и DER преобразование
11.2 Конвертация PKCS#12 (PFX)
12. Где хранятся корневые сертификаты Центров Сертификации (CA) в операционной системе
12.1 Корневые сертификаты Центров Сертификации (CA) в Linux
12.1.1 Общесистемные корневые CA сертификаты
12.1.2 Mozilla Network Security Services (NSS)
12.1.3 Google Chrome / Chromium
12.2 Корневые сертификаты Центров Сертификации (CA) в Windows
12.2.1 Общесистемные корневые CA сертификаты
12.2.2 Google Chrome
13. Как добавить корневой сертификат в доверенные
13.1 Как добавить корневой сертификат в доверенные в Linux
13.1.1 Как добавить корневой сертификат в доверенные в Linux на уровне системы
13.1.2 Как добавить корневой сертификат в доверенные в Linux в веб браузеры
13.2 Как добавить корневой сертификат в доверенные в Windows
13.2.1 Как добавить корневой сертификат в доверенные в Windows на уровне системы
13.2.2 Как добавить корневой сертификат в доверенные в Windows в веб браузеры
14. Цепи сертификатов
15. Верификация (проверка) сертификатов
16. Проверка настройки HTTPS
17. Как создать Корневой Центр Сертификации (Root CA)
18. Шифрование файлов в OpenSSL
18.1 Симметричное шифрование файлов в OpenSSL
18.2 Как зашифровать строки в OpenSSL (симметричное шифрование)
18.3 Асимметричное шифрование файлов в OpenSSL
19. Пининг сертификатов (pinning)
20. Словарь основных терминов OpenSSL
21. Программы для проверки настроек SSL и сбора информации
Инструкция по использованию и аудит безопасности
Знаете ли вы, что один единственный корневой сертификат хакера, установленный в вашу систему, фактически лишает её защиты с помощью шифрования SSL (TLS)? Знаете ли вы, что на самом деле для передачи основных данных браузеры не используют ассиметричное шифрование (с помощью сертификатов), а используют симметричное (парольная фраза)? Задумывались ли вы, можете ли Удостоверяющий Центр, выдавший SSL сертификат, расшифровать при желании передаваемый на сайт трафик? Почему VNC сессия, защищённая самодельным сертификатом, считается надёжной, а подключение к сайту, использующего такой же сертификат, нет? Почему для сайтов не подходят самодельные сертификаты? Знаете ли вы, что в вашей системе уже установлены сотни корневых сертификатов различных Центров Сертификации которым безоговорочно доверяют веб браузеры и другие приложения?
В этой статье мы разберёмся, как работает SSL (TLS) шифрование, как пользоваться утилитами OpenSSL, как создавать свои собственные ключи и Центры Сертификации, как подписывать сертификаты для сайтов, как просмотреть детальную информацию о сертификате и ключе, как конвертировать сертификаты в различные форматы и как проверить различные аспекты безопасности SSL (TLS), как проверить, какие сертификаты установлены в качестве доверенных корневых, как добавить новый доверенный сертификат или удалить сертификат из доверенных..
Что такое OpenSSL и для чего используется
OpenSSL — это криптографический инструментарий, реализующий сетевые протоколы Secure Sockets Layer (SSL v2/v3) и Transport Layer Security (TLS v1) и соответствующие им стандарты криптографии.
Программа openssl — это инструмент командной строки для использования различных криптографических функций криптографической библиотеки OpenSSL в консоли. Основны возможности:
- Создание и управление закрытыми ключами, открытыми ключами и параметрами.
- Криптографические операции с открытым ключом
- Создание сертификатов X.509, CSR и CRL
- Расчёт дайджестов сообщений
- Шифрование и дешифрование с помощью шифров
- Клиентские и серверные тесты SSL/TLS
- Обработка подписанной или зашифрованной почты S/MIME
- Запросы отметок времени, генерация и проверка
Как работают SSL сертификаты
Сгенерированные в OpenSSL ключи могут использоваться для шифрования различных данных, но самое популярное использование — шифрование в HTTPS протоколе, где используется ассиметричное шифрование, это означает, что для шифрования используется один ключ, а для расшифровки — второй ключ. Эти ключи называются:
- приватный ключ
- публичный ключ
Как можно понять из названия, публичный ключ не является секретным. Он свободно распространяется и используется для шифрования данных, которые можно расшифровать только приватным ключом.
Публичный и приватный ключ генерируются вмести и криптографически связаны.
Ещё данная пара ключей может использоваться для подписи данных и проверки подписи. Эта подпись подтверждает то, что данные удостоверены владельцем приватного ключа и в последствии эти данные не были изменены. Подписываются данные приватным ключом (которые имеет одно определённое лицо), а проверить подпись можно публичным ключом, который может получить каждый.
Любой может сгенерировать пару ключей, поэтому возникает проблема идентификации — как проверить, что публичный ключ выпущен определённым лицом?
Это можно было бы сделать например так: владелец сайт mysite.org генерирует пару публичный-приватный ключ и просит третью сторону подписать его публичный ключ. В результате публичный ключ распространяется с цифровой подписью, которую можно проверить публичным ключом третьей стороны. На самом деле, всё именно так и происходит, а подписанный публичный ключ, вместе с дополнительной информацией (например, название домена, для которого он подписан) упаковываются в сертификат.
Сертификат, по сути, это публичный ключ, а также информация о домене и другая сопутствующая информация, подписанная электронной подписью.
В результате процедура создания сертификата выглядит так:
- Владельцем сайта генерируется пара приватный и публичный ключ.
- Публичный ключ вместе с другой информацией для подписи (например, название доменного имени) упаковывается в файл в специальном формате. Он называется — Certificate Signing Request (CSR), то есть «запроса на подпись сертификата».
- Данный запрос на подпись (CSR) отправляется в Центр Сертификации (CA), который, используя свой приватный корневой ключ, создаёт подпись для этих данных и всё это упаковывается в другой специальный файл, называемый сертификат.
В результате получается сертификат со следующими свойствами:
- Он может зашифровать данные (в нём есть публичный ключ), которые способен расшифровать только приватный ключ составляющий пару этому сертификату
- Сертификат может быть проверен на подлинность (у него есть цифровая подпись) с помощью сертификата Центр Сертификации (CA), который его создал
При подключении к сайту пользователи получают свою копию сертификата этого сайта, и браузер автоматически проверяет её по доверенным корневым сертификатам, которые содержаться в операционной системе или хранятся в веб браузере.
После этого браузер шифрует с помощью сертификата сайта данные и отправляет их на сервер, эти данные может расшифровать только владелец приватного ключа, то есть сервер. Таким образом происходит согласование ключа, используемого для последующего шифрования.
Как генерировать сертификаты в OpenSSL
На самом деле, приватный ключ веб-сервера и приватный ключ Центр Сертификации (CA) по своей природе ничем не отличаются — они генерируются одной и той же командой. Но Центр Сертификации (CA) имеет особый статус постольку:
- Его приватный ключ используется для подписи сертификатов (поэтому он называется корневым, хотя в физическом смысле не отличается от приватного ключа сервера)
- Его публичный ключ (сертификат) добавлен на компьютеры всех пользователей в качестве доверенного
- Цифровая подпись в сертификате не предназначена для проверки третьей стороной, поскольку сертификат является самоподписанным. Единственное отличие самоподписанного сертификата из Центр Сертификации (CA) от того, который вы можете сгенерировать сами, в том, что он у вас размещён среди доверенных (в операционной системе или в браузере). Вы можете самостоятельно созданный самоподписанный сертификат разместить среди доверенных, и он будет иметь точно такую же силу как и корневой сертификат из Центр Сертификации (CA)
Вернёмся к процедуре подписи, а фактически создания сертификата сервера — создаваемый сертификат должен быть криптографически связан с приватным ключом сервера. Но приватный ключ должен быть известен исключительно его владельцу (серверу). Выходом из данной ситуации является использования уже упомянутого Certificate Signing Request (CSR), то есть «запроса на подпись сертификата». То есть Центру Сертификации передаеъётся публичный ключ и название домена, но приватный ключ остаётся в тайне. Именно в этом смысл существования CSR.
В учебных целях вы можете создать свои корневые ключи и даже свой «Центр Сертификации (CA)». Затем создадим пару приватный и публичный ключ сервера. Используя ключ сервера мы создадим запрос на подпись сертификата (CSR). Приватным ключом CA мы подпишем (создадим) сертификат для сервера.
Также мы научимся добавлять свой корневой сертификат в доверенные, проверять и управлять уже присутствующими доверенными сертификатами.
Какую команду использовать, genpkey или genrsa
В пакете OpenSSL есть две команды, которые выполняют очень похожее действие — генерируют пару приватный-публичный ключ RSA:
openssl genpkey -algorithm RSA openssl genrsa
На самом деле, форматы создаваемых этими программами RSA ключей немного различаются. Команда genpkey заменяет команду genpkey, а также ещё две команды: gendh и gendsa.
То есть использовать надо genpkey с которой нужно указать алгоритм ключа опцией -algorithm.
Как пользоваться OpenSSL (команды OpenSSL)
Команды OpenSSL не столько сложные, сколько запутанные.
Во-первых, их много (48 основных команд, 28 digest команд, 84 cipher команды, а также алгоритмы и методы), некоторые из них выполняют более чем одну функцию, некоторые имеют пересекающиеся функции и не всегда непонятно, какую команду выбрать.
Синтаксис использования команд OpenSSL:
openssl КОМАНДА ОПЦИИ
Ещё один пример как команды OpenSSL могут сбить с толку: у команды x509 есть опция -req, а у команды req есть опция -x509.
Если вы хотите получить справку по командам OpenSSL, то вам нужно знать, что это делается так:
man openssl-КОМАНДА # ИЛИ man КОМАНДА
man openssl-req man openssl-x509 man openssl-genpkey man openssl-enc man openssl-rsa # ИЛИ man req man x509 man genpkey man enc man rsa
Команды openssl могут быть громоздкими за счёт того, что через одну из опций команды передаются опции сертификата.
На самом деле, для типичных задач используется всего несколько команд и несколько опций. Поэтому если понимать суть, то всё довольно просто.
Перечень команд OpenSSL, которые мы будем использовать:
- genpkey (заменяет genrsa, gendh и gendsa) — генерирует приватные ключи
- req — утилита для создания запросов на подпись сертификата и для создания самоподписанных сертификатов PKCS#10
- x509 — утилита для подписи сертификатов и для показа свойств сертификатов
- rsa — утилита для работы с ключами RSA, например, для конвертации ключей в различные форматы
- enc — различные действий с симметричными шифрами
- pkcs12 — создаёт и парсит файлы PKCS#12
- crl2pkcs7 — программа для конвертирования CRL в PKCS#7
- pkcs7 — выполняет операции с файлами PKCS#7 в DER или PEM формате
- verify — программа для проверки цепей сертификатов
- s_client — команда реализует клиент SSL/TLS, который подключается к удалённому хосту с использованием SSL/TLS. Это очень полезный инструмент диагностики для серверов SSL
- ca — является минимальным CA-приложением. Она может использоваться для подписи запросов на сертификаты в различных формах и генерировать списки отзыва сертификатов. Она также поддерживает текстовую базу данных выданных сертификатов и их статус
- rand — эта команда генерирует указанное число случайных байтов, используя криптографически безопасный генератор псевдослучайных чисел (CSPRNG)
- rsautl — команда может быть использована для подписи, проверки, шифрования и дешифрования данных с использованием алгоритма RSA
- smime — команда обрабатывает S/MIME почту. Она может шифровать, расшифровывать, подписывать и проверять сообщения S/MIME
Чтобы увидеть полный список команд выполните:
openssl list -commands
asn1parse ca ciphers cms crl crl2pkcs7 dgst dhparam dsa dsaparam ec ecparam enc engine errstr gendsa genpkey genrsa help list nseq ocsp passwd pkcs12 pkcs7 pkcs8 pkey pkeyparam pkeyutl prime rand rehash req rsa rsautl s_client s_server s_time sess_id smime speed spkac srp storeutl ts verify version x509
Как создать сертификаты SSL (TLS) для сайтов
Создайте корневой приватный ключ
Внимание: этот ключ используется для подписи запросов сертификатов, любой, кто получил этот ключ, может подписывать сертификаты от вашего имени, поэтому храните его в безопасном месте:
Генерация приватного ключа RSA используя параметры по умолчанию (ключ будет сохранён в файл с именем rootCA.key):
openssl genpkey -algorithm RSA -out rootCA.key
Опция -out указывает на имя файла для сохранения, без этой опции файл будет выведен в стандартный вывод (на экран). Имя выходного файла не должно совпадать с именем входного файла.
Для безопасности ключа его следует защитить паролем. Генерация приватного ключа RSA используя 128-битное AES шифрование (-aes-128-cbc) и парольную фразу «hello» (-pass pass:hello):
openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pass pass:hello
Конечно, опцию -pass pass:hello можно не указывать, тогда вам будет предложено ввести пароль во время генерации ключа.
Список поддерживаемых симметричных алгоритмов шифрования приватного ключа можно узнать в документации (раздел SUPPORTED CIPHERS):
man enc
Если для генерируемого ключа не указано количество бит, то по умолчанию используется 2048, вы можете указать другое количество бит с помощью команды вида (будет создан 4096-битный ключ):
openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pkeyopt rsa_keygen_bits:4096
Создание самоподписанного корневого сертификата
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt
Здесь мы использовали наш корневой ключ для создания корневого сертификата (файл rootCA.crt), который должен распространяться на всех компьютерах, которые нам доверяют. А приватный ключ (файл rootCA.key) должен быть секретным, поскольку он будет использоваться для подписи сертификатов серверов.
Создание сертификатов (делается для каждого домена) включает в себя несколько этапов. Эту процедуру необходимо выполнить для каждого домена/сервера, которым требуется доверенный сертификат от нашего ЦС.
Чтобы создать приватный ключ сертификата
openssl genpkey -algorithm RSA -out mydomain.com.key
Обратите внимание, что это та же самая команда, которой мы создавали пару приватный-публичный ключ Центра Сертификации (изменено только имя файла с ключами).
Создание файла с запросом на подпись сертификата (csr)
Получив закрытый ключ, вы можете приступить к созданию запроса на подпись сертификата — Certificate Signing Request (CSR). Это официальный запрос к CA о подписании сертификата, который содержит открытый ключ объекта, запрашивающего сертификат, и некоторую информацию об объекте. Все эти данные будут частью сертификата. CSR всегда подписывается закрытым ключом, соответствующим открытому ключу, который он несёт.
Создание CSR обычно представляет собой интерактивный процесс, в ходе которого вы будете предоставлять элементы отличительного имени сертификата (вводить информацию о стране, городе, организации, email и т.д.). Внимательно прочитайте инструкции, предоставленные инструментом openssl; если вы хотите, чтобы поле было пустым, вы должны ввести одну точку (.) в строке, а не просто нажать «Enter». Если вы сделаете последнее, OpenSSL заполнит соответствующее поле CSR значением по умолчанию. (Такое поведение не имеет никакого смысла при использовании с конфигурацией OpenSSL по умолчанию, что и делают практически все. Это имеет смысл, когда вы осознаете, что можете изменить значения по умолчанию, либо изменив конфигурацию OpenSSL, либо предоставив свои собственные конфигурации в файлах).
В запросе на подпись сертификата вы указываете информацию для сертификата, который хотите сгенерировать. Этот запрос будет обработан владельцем корневого ключа (в данном случае вы его создали ранее) для генерации сертификата.
Я опишу здесь два способа:
- Метод А (интерактивный)
Если вы создадите CSR таким способом, openssl задаст вам вопросы о сертификате, который необходимо сгенерировать, например, сведения об организации и Common Name (CN), которое является веб-адресом, для которого вы создаёте сертификат, например, mydomain.com.
openssl req -new -key mydomain.com.key -out mydomain.com.csr
Метод Б (в одну команду без запросов)
Этот метод генерирует тот же результат, что и метод A, но он подходит для использования в вашей автоматизации.
openssl req -new -sha256 -key mydomain.com.key -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=mydomain.com" -out mydomain.com.csr
Если вам нужно передать дополнительную конфигурацию, вы можете использовать параметр -config, например, здесь я хочу добавить альтернативные имена в мой сертификат.
openssl req -new -sha256 -key mydomain.com.key -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=mydomain.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:mydomain.com,DNS:www.mydomain.com")) -out mydomain.com.csr
Проверьте содержание CSR
После создания CSR используйте его, чтобы подписать собственный сертификат и/или отправить его в общедоступный центр сертификации и попросить его подписать сертификат. Оба подхода описаны в следующих разделах. Но прежде чем сделать это, неплохо бы ещё раз проверить правильность CSR. Это делается так:
openssl req -in mydomain.com.csr -noout -text
Создайте сертификат, используя csr для mydomain.com, корневые ключ и сертификат CA.
Если вы устанавливаете сервер TLS для своего собственного использования, вы, вероятно, не хотите идти в ЦС для покупки публично доверенного сертификата. Намного проще использовать сертификат, подписанный вашим собственным CA. Если вы являетесь пользователем Firefox, при первом посещении веб-сайта вы можете создать исключение для сертификата, после которого сайт будет защищён так, как если бы он был защищён общедоступным сертификатом.
Если у вас уже есть CSR, создайте сертификат, используя следующую команду:
openssl x509 -req -in mydomain.com.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out mydomain.com.crt -days 500 -sha256
В результате выполнения этих команд были созданы следующие файлы:
- rootCA.key — приватный ключ Центра Сертификации, должен храниться в секрете в CA
- rootCA.crt — публичный корневой сертификат Центра Сертификации — должен быть установлен на всех пользовательских устройствах
- mydomain.com.key — приватный ключ веб-сайта, должен храниться в секрете на сервере. Указывает в конфигурации виртуального хоста при настройке веб-сервера
- mydomain.com.csr — запрос на подпись сертификата, после создания сертификата этот файл не нужен, его можно удалить
- mydomain.com.crt — сертификат сайта. Указывает в конфигурации виртуального хоста при настройке веб-сервера, не является секретным.