Настройка центра сертификации linux

Обновлено: 07.07.2024

Если в сети есть домен с контроллером и центр сертификации Microsoft, для внутреннего использования можно создавать собственные сертификаты, для которых браузер не будет выдавать ошибку. Если с запросом и установкой сертификата на Windows возникает меньше вопросов, то получение сертификата для Linux выполнить немного сложнее.

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

1. Формируем файл запроса (на компьютере с Linux)

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

mkdir -p /etc/ssl/adcs

Создаем закрытый ключ:

openssl genrsa -out private.key 2048

Создаем файл с описанием запроса:

[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_extensions
distinguished_name = dn

[req_extensions]
subjectAltName = @alter_name

[alter_name]
DNS.1 = *.dmosk.local

* где стоит обратить внимание на следующее:

sha256 (или SHA-2) — алгоритм шифрования;
*.dmosk.local — имя узла, к которому мы будем обращаться. Это очень важный пункт — нужно, чтобы имя совпадало с именем, по которому будут выполняться обращения. В данном примере создается wildcart (домен и все его поддомены)
subjectAltName — альтернативные имена стали иметь значение с 2017 года, когда некоторые браузеры перестали принимать сертификаты без указания альтернативных DNS-имен.

Далее создаем ключ запроса сертификата:

openssl req -new -key private.key -out request.csr -config openssl.conf

* где private.key — закрытый ключ, который был сформирован на предыдущем шаге; request.csr — файл, который будет сформирован. В нем будет запрос на открытый ключ;

После выполнения команды, в каталоге появится файл request.csr. Выведем его содержимое, чтобы посмотреть запрос:

Должны увидеть что-то на подобие:

2. Выпускаем сертификат

В открывшемся окне переходим по ссылкам Запроса сертификата - расширенный запрос сертификата.

В поле «Сохраненный запрос» вставляем скопированный запрос, в а поле «Шаблон сертификата» выбираем Веб-сервер:

Нажимаем Выдать и скачиваем сертификат по ссылке Загрузить сертификат:

3. Установка сертификата на Linux

Переносим полученный сертификат на компьютер с Linux, например, при помощи WinSCP.

После необходимо сконвертировать DER-сертификат (от AD CS) в PEM-сертификат (для Linux). Для этого вводим следующую команду:

Условие1. поднять PKI-AD, при этом корневой центр сертификации должен быть установлен на отдельной станции ROOT-CA.
Условие2. так как станция ROOT-CA используется крайне ограниченные время и только на выпуск CRT и CRL, то на 99% станция находится отключенном состоянии, бюджет на данную станцию равен нулю.

Размышления

Размышления крайне просты: для экономии бюджета PKI-AD будет установлена непосредственно на сервер Active Directory, а вот ROOT-CA требуется поднять на Linux.

Далее по тексту:

ROOT-CA – станция либо сертификат корневого центра.

PKI AD-CA – станция с ролью “Службы сертификатов Active Directory”

Решение

Подготовка ROOT-CA. (CentOS7)

Корневой сертификат ROOT-CA, будем выпускать на CentOS, там-же будем подписывать сертификат для PKI AD-CA.

Для решения данной задачи на машине с Linux необходимо установить пакет easy-rsa, который содержится в репетиторе epel-release

yum install epel-releas

yum install easy-rsa

Более подробно с документацией к easy-rsa можно ознакомится на GitHub/OpenVPN

После того как мы установили easy-rsa мы можем создать главный удостоверяющий центр сертификации.

(Все операции буду выполнять из под пользователя root)

Создадим в директории пользователя, каталог - в котором будем хранить наш PKI

Далее нужно скопировать последнюю версию easy-rsa в наш каталог ROOTca,

В моём случаи последняя версия 3.0.8. Её и будем копировать.

Копируем easy-rsa в каталог ROOTca

cp -R /usr/share/easy-rsa/3.0.8/*

создаем и сразу редактируем

собираем файл vars, у меня получилось так:

Теперь все готово, можно начинать!

Внимание! Вовремя всех действий, вы должны находится в директории ROOTca

Инициализируем наш центр сертификации

Отлично, мы готовы выпустить наш ROOT-CA

Выпускаем

Система попросит придумать пароль для секретного ключа нашего ROOT-CA

(для наших задач, пароль должен быть не менее 4 символов)

Проверяем параметры выпускаемого сертификата, они берутся из vars, соглашаемся либо меняем на нужные.

. В какой-то момент система спросит название “Common Name”. Это название будет основным названиям нашего сертификата

Common Name (eg: your user, host, or server name) [Easy-RSA CA]: Указываем CompanyName Certificate 2021.

По окончанию мы получим корневой сертификат ROOT-ca нашего PKI

Он располагается пути /root/ROOTca/pki/ca.crt

Копируем корневой сертификат на станцию c PKI AD-CA

Сервер с PKI AD-CA (Windows Server)

Проверяем полученный файл на станции PKI AD-CA

Открываем ca.crt и проверяем содержимое

ca.crt

Все отлично! Переименуем ca.crt в ROOT-ca.crt, так как-то удобнее. Теперь нужно подготовить службу Центра сертификации Windows.

Устанавливаем роль “Службы сертификатов Active Directory”

в моем случае, устанавливаю “Службы сертификатов Active Directory” на отдельный ПК, все действия для PKI AD-CA идентичны

После установки переходим к настройке - Службы сертификатов Active Directory

в момент настройки выбираем следующие опции:

Наш сервер будет- подчиненным ЦС

Нам нужно создать новый закрытый ключ

Шифрование - выбираем по вкусу

Указываем имя CA

Запрос сертификата - указываем через REQ файл

Хорошо, теперь у нас есть файл pki-ca_PKI-CA-CA.req

Копируем полученный файл на машину с Linux ROOT-ca в директорию /root/ROOTca/pki/

Все готово к выпуску сертификата для PKI AD-CA

Перед тем как выпустить сертификат нужно импортировать req файл в PKI

импортируем

./easyrsa import-req /root/ROOTca/pki/pki-ca_PKI-CA-CA.req CompanyName-AD

Где CompanyName-AD – название центра PKI AD-CA

Проверяем что получилось

./easyrsa show-req CompanyName-AD

Пора выпустить сертификат для CompanyName-AD

./easyrsa sign-req ca CompanyName-AD

Так как мы выпускаем сертификат для “Центра сертификации” указываем именно ca, если нужно выпустить на отдельный сервер указываем server.

мы получили наш сертификат для PKI AD-CA по пути /root/ROOTca/pki/issued/CompanyName-AD.crt

Копируем его на станцию с PKI AD-CA

Также нам нужны списки отзыва CRL, с генерируем и их

(Напоминаю что действия наших списков 92 дня см файл vars,в течении 92 дней нужно повторить операцию передачи CRL)

Копируем crl.pem также на станцию с AD-PKI

Сервер с PKI AD-CA (Windows Server)

Сейчас у нас есть все, что нам нужно.

Корневой сертификат: ROOT-ca.crt

Сертификат CA для нашего сервера: CompanyName-AD.crt

Списки отзыва: crl.pem

Импорт ROOT-ca

Нам нужно сделать ROOT-ca.crt стал валидным сертификатом в системе Windows, напоминаю, что сейчас он с крестом и нас, конечно, такой вариант не устраивает.

Запускам MMC-консоль и подключаем оснастку “Сертификаты” для учетной записи компьютера.

Переходим по пути: Сертификаты\Доверительные корневые центры\Сертификаты

Добавим наш сертификат ROOT-ca.crt в "Доверительные корневые центры"

Для этого правой кнопкой по папке “сертифкаты” -> импорт

Указываем путь к сертификату ROOT-ca.crt и импортируем его.

После импорта сертификат должен появиться в списке

Теперь, проверяем сам файл ROOT-ca.crt

Так-то куда лучше!

(Данный сертификат нужно также распространить через групповые политики, на все ПК в AD)

Импорт CRL.

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

(теперь можно изучить файл ROOTca.crl)

Импортируем его точно также как и сертификат в доверительные корневые центры ROOT-ca.crt

Активация PKI AD-CA

Теперь можно приступить к активации нашего CA PKI AD-CA

Запускаем средство "Центр сертификации"

Перед установкой сертификата в CA, лучше предварительно настроить публикацию CDP и AIA

Активируем CA

Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Установить сертификат ЦС

Далее, указываем файл CompanyName-AD.crt и подтверждаем.

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

Если вы не можете импортировать CompanyName-AD.crt система просит P7B файл.
Необходимо выполнить слияние CompanyName-AD.crt с ROOT-ca.crt в OpenSSL следующей командой:
openssl crl2pkcs7 -nocrl –certfile ROOT-ca.crt -certfile CompanyName-AD.crt -out CompanyName-AD.p7b

Запуск PKI AD-CA

теперь мы можем запустить службу Центра сертификации

Правой кнопкой мыши по серверу PKI AD-CA > Все задачи > Запуск службы

Итог

мы получили рабочий PKI - Active Directory и можем начать выпуск сертификатов для пользователей, станций, серверов. При этом ROOT-ca находится на станции с Linux, и нам не пришлось отдавать под данную задачу отдельный сервер с Windows.

Эта инструкция демонстрирует, как работает собственный центр сертификации (CA – Certificate Authority), используя набор инструментов командной строки OpenSSL. Это полезно в ряде случаев, таких как выдача сертификата сервера для защиты вебсайта в интранете, или для выдачи сертификатов для клиентов, чтобы позволить им проверить подлинность сервера.

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

Центр сертификации (CA) является объектом, который подписывает цифровые сертификаты. Многие веб-сайты нуждаются в том, чтобы их клиенты знали, что соединение является безопасным, поэтому они платят международным доверенным центрам сертификации (например, VeriSign, DigiCert) за подпись сертификата для своего домена.

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

Выступая в качестве центра сертификации (CA) означает иметь дело с криптографическими парами приватных (частных) ключей и публичными сертификатами. Самой первой криптографической парой создадим корневую пару. Она состоит из корневого ключа (ca.key.pem) и корневого сертификата (ca.cert.pem). Эта пара образует идентичность нашего центра сертификации.

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

Подготовка каталогов

Выберите каталог для хранения всех ключей и сертификатов. К примеру, /root/ca (все производится на Ubuntu 14.04.3 LTS)

Создадим структуру каталогов. Файлы index.txt и serial будут выступать в качестве плоской базы для отслеживания подписанных сертификатов.

Подготовка конфигурационных файлов

Необходимо создать конфигурационный файл для OpenSSL. Создадим файл /root/ca/openssl.cnf , скопируем в него следующее содержимое root-config.txt.
Раздел [ca] является обязательным. Здесь мы говорим OpenSSL использовать параметры из раздела [CA_default] :

Раздел [CA_default] содержит ряд значений по умолчанию:

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

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

Параметры из секции [ req ] применяются когда создаются сертификаты или запросы на подписывание сертификатов.

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

Следующие несколько секций являются расширениями, которые могут применять при подписывании сертификатов. Например, при указании аргумента командной строки -extensions v3_ca будут применены расширения из секции [ v3_ca ] . Эти расширения будут применяться при создании корневого сертификата.

При создании сертификата промежуточного центра сертификации будут применяться расширения из v3_ca_intermediate . Параметр pathlen:0 указывает, что не может быть никаких дальнейших центров сертификации ниже промежуточного центра сертификации.

Расширение usr_cert будет применяться при подписывании клиентских сертификатов, таких, которые используются для аутентификации удаленных пользователей.

Расширение server_cert будет применяться при подписывании серверных сертификатов, таких, которые используются для веб-серверов.

Расширение crl_ext будет автоматически применяться при создании списков отзыва сертификатов (CRL — certificate revocation lists).

Расширение ocsp будет применяться при подписывании сертификата OCSP (Online Certificate Status Protocol, онлайн протокол статуса сертификатов).

Создание корневого ключа

Создадим корневой ключ (ca.key.pem), который следует хранить защищенно. Любой, владеющий корневым ключом, может выдавать доверенные сертификаты. Зашифруем ключ стойким алгоритмом AES-256 и надежным паролем. Следует использовать 4096 битное шифрование для ключей корневого и промежуточных центров сертификации. Серверные и клиентские сертификаты возможно подписывать шифрованием с меньшей битностью.

Создание корневого сертификата

Для создания корневого сертификата (ca.cert.pem) используется корневой ключ (ca.key.pem). Следует указать длинный срок годности сертификата, например, 20 лет. После того, как истечет корневой сертификат, все сертификаты, подписанные центром сертификации становятся недействительными. Всякий раз при использовании утилиты req следует указывать файл конфигурации для использования с опцией –config , в противном случае OpenSSL будет использовать по умолчанию конфигурационный файл /etc/pki/tls/openssl.cnf !

Проверка корневого сертификата

Используемый алгоритм Signature Algorithm
Даты периода действия сертификата Validity
Длину публичного ключа Public-Key
Эмитент сертификата Issuer, который является объектом, который подписал сертификат
Предмет Subject, который относится к самому сертификату.

Эмитент (Issuer) и предмет (Subject) идентичны для самоподписанных сертификатов. Все корневые сертификаты являются самоподписанными.

Вывод также показывает расширения X509v3, т.к. было применено расширение v3_ca , и опции из секции [ v3_ca ] отражены в выводе.

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

Цель использования промежуточного центра сертификации, прежде всего, для обеспечения безопасности. Корневой ключ должен храниться «оффлайн» и использоваться как можно реже. Если промежуточный ключ будет скомпрометирован, корневой центр сертификации может отозвать промежуточный сертификат и создать новую промежуточную криптографическую пару.

Подготовка каталогов

Файлы корневого центра сертификации хранятся в /root/ca. Выберем каталог (/root/ca/intermediate) для хранения файлов промежуточного центра сертификации.

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

Добавим файл crlnumber к дереву каталогов промежуточного центра сертификации. Crlnumber будет использоваться для отслеживания списков отзывов сертификатов.

Создадим конфигурационный файл /root/ca/intermediate/openssl.cnf , скопируем в него следующее содержимое intermediate-config.txt. В нем изменены пять опций, по сравнению с конфигурационным файлов корневого центра сертификации:

Создание промежуточного ключа

Создадим промежуточный ключ (intermediate.key.pem). Зашифруем ключ стойким алгоритмом AES-256 и надежным паролем.

Создание промежуточного сертификата

Используя промежуточный ключ создадим запрос на подписывание сертификата (CSR — certificate signing request). Сведения должны, как правило, соответствовать корневому центру сертификации. Общие имена (Common Name), однако, должны быть разными. И убедитесь, что используете конфигурационный файл промежуточного центра сертификаци ( intermediate/openssl.cnf ).

Чтобы создать промежуточный сертификат используем корневой центр сертификации с расширением v3_intermediate_ca для подписывания промежуточного запроса. Промежуточный сертификат должен быть действителен на меньший период, чем корневой. К примеру, на 10 лет. В этот раз следует использовать конфигурационный файл корневого центра сертификации ( /root/ca/openssl.cnf ).

V 250408122707Z 1000 unknown . /CN=Alice Ltd Intermediate CA

Проверка промежуточного сертификата

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

Сверим промежуточный сертификат с корневым сертификатом. ОК показывает, что цепочка доверия не повреждена.

Создание файла цепочки сертификатов

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

Чтобы создать цепочку сертификатов требуется объеденить промежуточные и корневые сертификаты вмете. Позже мы будем использовать этот файл для проверки сертификатов подписанных промежуточным центром сертификации.

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

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

Указанные ниже шаги с вашей точки сзрения, где вы выступаете в качестве центра сертификации. Стороннее лицо, однако, вместо этого может создать свой собственный частный ключ и запрос на подпись сертификата (CSR) без раскрытия вам своего частного ключа. Они дают вам собственный CSR, а вы отдаете им подписанный сертификат. В этом случае, пропустите команды genrsa и req.

Создание ключа

Наши корневая и промежуточная пары 4096 бит. Серверный и клиентский сертификат обычно истекают после одного года, поэтому мы можем безопасно использовать 2048 бит.

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

Создание сертификата

Для создания сертификата воспользуемся промежуточным центром сертификации для подписи CSR. Если сертификат будет использоваться на сервере, используйте расширение server_cert . Если сертификат будет использоваться для аутентификации клиентов, то используйте расширение usr_cert . Сертификаты обычно даются сроком на один год, на центре сертификации обычно дают несколько дней для удобства.

Файл intermediate/index.txt должен содержать строку, которая относится к этому сертификату

Проверка сертификата

Issuer сертификата наш промежуточный центр сертификации. Subject относится к самому сертификату.

Вывод также покажет расширения X509V3. При создании сертификата можно использовать расширения server_cert или usr_cert . Варианты о соответствующем разделе конфигурации будут отражаться в выводе.

Используя файл цепочки сертификатов центра сертификации, который мы создали ранее (ca-chain.cert.pem) для проверки того, что новый сертификат имеет действительную цепочку доверия.

Установка сертификата

Теперь можно установить новый сертификат на сервере, или распространить сертификат на клиентов. При установке на серверное приложение (к примеру, Apache), понадобятся следующие файлы:

Списки отзывов сертификатов (CRL) предоставляют список сертификатов, которые были отозваны. Клиентское приложение, к примеру, веб-браузер, может использовать CRL для проверки подлинности сервера. Серверные приложения, такие как Apache или OpenVPN, могут использовать CRL для запрета доступа клиентам, которые больше не являются доверенными.

Подготовка файла конфигурации

Когда центр сертификации подписывает сертификат, он обычно зашифровывает расположение CRL в сертификат. Добавляется crlDistributionPoints в подходящие секции. В нашем случае, добавляет к секции server_cert .

Создание CRL

Секция CRL OPTIONS в man ca содержит больше информации о том, как создавать CRL.

Можно проверить содержимое CRL с помощтю утилиты crl.

Пока еще не было отозванных сертификатов, поэтому в выводе указано:

No Revoked Certificates.

Необходимо пересоздавать CRL на регулярной основе. По умолчанию, CRL истекает через 30 дней. Это настраивается опцией default_crl_days в секции CA_default .

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

Давайте разберем пример. Алиса запустила веб-сервер Apache и имеет личную папку с сердцу трогательными милыми картинками котят. Алиса хочет предоставить своему другу, Бобу, доступ к этой коллекции.

Боб создает запрос частного ключа и запрос на подпись сертификата (CSR).

Боб посылает свой CSR Алисе которая затем подписывает его.

Алиса проверяет, что сертификат действителен:

Файл index.txt должен содержать новую запись.

Алиса посылает Бобу подписанный сертификат. Боб устанавливает сертификат в своем веб-браузере и теперь у него есть доступ к фотографиям котят Алисы. Ура!

К сожалению, выясняется, что Боб себя плохо вел. Боб отправил фотографии котят Алисы в Hacker News, заявляя, что они его и теперь набирает огромную популярность. Алиса это узнает и нуждается в немедленном отзыве его доступа.

Строка в index.txt, которая относится к сертификату Боба теперь начинается с буквы R. Это означает, что он был отозван (Revoked).

После отзыва сертификата Боба, Алисе необходимо пересоздать CRL.

Ипользование CRL на сервере

Обычно серверное приложение (к примеру, Apache) делает проверку для клиентских сертификатов.Это приложение должно иметь локальный доступ до CRL.

В случае Алисы, она может добавить директиву SSLCARevocationPath в ее конфигурацию Apache и скопировать CRL на свой сервер. В следующий раз, когда Боб подключится к веб-серверу, Apache проверит его клиентский сертификат в CRL и запретит доступ. По аналогии, OpenVPN имеет директиву crl-verify , и можно блокировать клиентов, чьи сертификаты были отозваны.

Использование CRL клиентами

Для серверных сертификатов, обычно клиентское приложение (к примеру, веб-браузер) выполняет проверку. Это приложение должно иметь удаленный доступ к CRL.

Если сертификат был подписан с расширением, которое включает crlDistributionPoints , клиентское приложение может прочитать эту информацию и получить CRL из указанного места.

Точки распространения CRL видны в спецификациях X509v3 сертификата.

Online Certificate Status Protocol (OCSP) был создан в качестве альтернативы CRL. Как и CRL, OCSP позволяет запрашивающей стороне (к примеру, веб-браузеру) определять статус отзыва сертификата.

Например, когда веб-браузеру предоставлен сертификат сервера, он посылает запрос на адрес сервера OCSP, указанном в сертификате. По этому адресу OCSP слушает запросы и отвечает статусом отзыва сертификата.

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

Подготовка конфигурационного файлы

Для использования OCSP центр сертификации должен закодировать расположение сервера OCSP в сертификат, который он подписывает. Используем опцию authorityInfoAccess в соответствующей секции, в нашем случае в секции server_cert .

Создание пары OCSP

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

Создадим частный ключ и зашифруем его алгоритмом AES-256.

Создадим запрос на создание сертификата (CSR). Детали должны, как правило, совпадать с подписывающим центром сертификации. Common Name, однако, должен быть полным доменным именем.

Подпишем CSR промежуточным центром сертификации.

Проверим, что сертификат содержит коррестные расширения X509v3.

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

Утилита OpenSSL ocsp может выступать в качестве ответчика OCSP, но она предназначена только для тестирования. Для производственной среды OCSP ответчики тоже существуют, но они выходят за рамки данной статьи.

Создадим серверный сертификат для тестирования.

Запустим ответчик OCSP на локальной машине. Вместо того, чтобы хранить статус отзыва в отдельном CRL файле ответчик OCSP напрямую читает файл index.txt. Ответ подписывается криптографической парой OCSP (используя опции –rkey и –rsigner).

В другом терминале пошлем запрос к OCSP ответчику. Опция –cert указывает сертификат для запроса.

Начало вывода показывает следующее:

был ли получен положительный ответ (OCSP Response Status)
идентичность ответчика (Responder Id)
статус отзыва сертификата (Cert Status)

Как и раньше, запускаем ответчик OCSP в другом терминале и шлем запрос. В этот раз вывод показывает "Cert Status: revoked" и "Revocation Time" .

Как добавить корневой сертификат в доверенные в Linux на уровне системы

Сертификат с расширением .crt можно открыть двойным кликом и просмотреть его содержимое:

Если вы работаете в системе от обычного пользователя (не root), то кнопка «Импортировать» будет недоступна.

Чтобы разблокировать кнопку «Импортировать», выполните следующую команду:

Данный способ может не сработать, поэтому рассмотрим, как добавить доверенные корневые центры сертификации в командной строке.

Суть метода очень проста:

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

Пути и команды в разных дистрибутивах Linux чуть различаются.

Просмотреть Subject всех корневых CA сертификатов можно уже знакомой командой:

Для демонстрации я добавлю сертификат с Common Name, включающим «HackWare», тогда для проверки, имеется ли сертификат с таким именем среди корневых CA, я могу использовать команду:

Для добавления своего корневого CA в доверенные в Debian, Kali Linux, Linux Mint, Ubuntu и их производных:

1. Проверьте, существует ли директория /usr/local/share/ca-certificates:

Если её ещё нет, то создайте:

Сертификат должен быть в формате PEM (обычно так и есть) и иметь расширение .crt — если расширение вашего сертификата .pem, то достаточно просто поменять на .crt.

2. Скопируйте ваш сертификат командой вида:

3. Запустите следующую команду для обновления общесистемного списка:

Проверим наличие нашего CA сертификата среди доверенных:

Сертификат успешно найден:

Чтобы его удалить:

Для добавления своего корневого CA в доверенные в Arch Linux, BlackArch и их производных:

1. Выполните команду вида:

2. Обновите общесистемный список доверенных CA:

Чтобы удалить этот сертификат:

Добавление сертификатов в базу данных NSS

Некоторые приложения используют базу данных NSS, и у вас может быть необходимость добавить доверенные CA в неё.

Последующие изменения повлияют только на приложения, использующие базу данных NSS и учитывающие файл /etc/pki/nssdb.

1. Сначала создайте структуру каталогов для системных файлов базы данных NSS:

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

2. Убедитесь, что файлы базы данных доступны для чтения всем:

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

3. Теперь, когда доступны файлы базы данных NSS, добавьте сертификат в хранилище следующим образом:

Биты доверия, используемые в приведённом выше примере, помечают сертификат как надёжный для подписи сертификатов, используемых для связи SSL/TLS. Имя (указывается после опции -n), используемое в команде, можно выбрать любое, но убедитесь, что его легко отличить от других сертификатов в магазине.

Аналогичные инструкции можно использовать для включения сертификата только в базу данных NSS конкретного пользователя:

Удаление из файлов базы данных NSS

Чтобы удалить сертификат из любой базы данных NSS, используйте команду certutil следующим образом. В этом примере используется общесистемное расположение базы данных NSS, но его можно легко изменить на пользовательское

Как добавить корневой сертификат в доверенные в Linux в веб браузеры

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

Причём эти браузеры хотя и используют NSS, они игнорируют общесистемные сертификаты NSS, которые можно добавить в файл /etc/pki/nssdb!

Тем не менее приложения, которые используют NSS (такие как Firefox, Thunderbird, Chromium, Chrome) хранят свои списки доверенных сертификатов в файлах cert9.db. Чтобы добавить свой сертификат в каждый из этих файлов можно использовать скрипт.

Сохранить следующий код в файл CAtoCert9.sh:

В этом файле измените значение certfile на имя файла вашего сертификата и значение certname на имя вашего сертификата, сохраните и закройте файл.

Затем запустите его следующим образом:

В результате в домашней папке пользователя будут найдены все файлы cert9.db и в каждый из них будет добавлен указанный CA сертификат.

Вы можете добавить CA сертификаты в графическом интерфейсе каждого браузера.

В настройках Chrome: Конфиденциальность и безопасность → Безопасность → Настроить сертификаты → Центры сертификации
В настройках Chromium: Конфиденциальность и безопасность (выбрать «Ещё») → Настроить сертификаты → Центры сертификации

Выберите файл с сертификатом.

Укажите, какие полномочия вы даёте этому сертификату:

В настройках Firefox: Приватность и Защита → Сертификаты → Просмотр сертификатов → Центры сертификации:

Выберите файл с сертификатом.

Укажите, какие полномочия вы даёте этому сертификату:

Для глубокого понимания OpenSSL смотрите также полное руководство: «OpenSSL: принципы работы, создание сертификатов, аудит».

Читайте также: