Перейти к основному содержимому
Версия: 5.1

Работа с OpenSSL

В данной статье приведено руководство по работе с OpenSSL, включая генерацию RSA-ключей, создание и подпись CSR-запросов, настройку расширений сертификатов (SAN, Key Usage) и проверку их валидности. Рассмотрены форматы хранения сертификатов (PEM, DER, PKCS#12), их конвертация и обмен, а также настройка доверенных хранилищ.

Генерация приватного ключа RSA​

Генерация приватного ключа RSA является первым шагом генерации сертификата. RSA (Rivest-Shamir-Adleman) — это один из самых распространенных алгоритмов асимметричного шифрования, который используется для защиты данных и аутентификации.

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

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

openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048
Примечание

Минимальная длина ключа - 2048 бит. В целях повышения безопасности можно использовать длину ключа 3072 или 4096 бит.

Создание запроса подписания сертификата (CSR)​

CSR (Certificate Signing Request) — это файл, содержащий информацию о владельце сертификата и его публичный ключ. CSR не является готовым сертификатом. Чтобы получить полноценный сертификат, необходимо подписать CSR с использованием сертификата удостоверяющего центра (CA).

Для генерации CSR используется следующая команда:

openssl req -new -key private_key.pem -out request.csr -sha256

В ходе процесса потребуется указать сведения о субъекте:

  • Country Name — 2-буквенный код страны, например, RU

  • State or Province Name — штат или регион, например, Moscow

  • Locality Name — город, например, Moscow

  • Organization Name — название организации

  • Organizational Unit Name — название подразделения

  • Common Name — полное доменное имя субъекта, для которого выпускается сертификат

  • Email Address — электронная почта

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

  • Challenge password — пароль для проверки

  • Optional company name — необязательное название компании

Обратите внимание!

При вводе символа . поле останется пустым.

Обратите внимание!

Сертификат узла каждого компонента (Logstash, OpenSearch и др.) должен включать необходимые расширения:

  • Subject Alternative Name (SAN), включающий все IP-адреса и DNS-имена соответствующего компонента Smart Monitor

  • Key Usage: critical Digital Signature, Key Encipherment

  • Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication

Subject Alternative Name (SAN)​

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

Subject Alternative Name (SAN) — это расширение, которое позволяет определять дополнительные домены и IP-адреса, которые будут считаться валидными для данного сертификата при его проверке.

Добавление альтернативных имен в сертификат возможно на этапе создания CSR. Для этого необходимо создать конфигурационный файл (например, san.cnf). В данном файле необходимо указать следующие параметры:

  • основные данные (Common Name, Organization и пр.)

  • список SAN (дополнительные домены и IP)

Пример конфигурационного файла приведен ниже:

[req]
default_bits = 2048
prompt = no
distinguished_name = req_distinguished_name
req_extensions = v3_req


[req_distinguished_name]
countryName = RU
stateOrProvinceName = Moscow
localityName = Moscow
organizationName = My Company
organizationalUnitName = IT
commonName = example.com
emailAddress = example@mail.com

[v3_req]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alt_section

[alt_section]
DNS.1 = example.com         # Основной домен (можно дублировать CN)
DNS.2 = www.example.com     # Поддомен
DNS.3 = api.example.com     # Еще один поддомен
DNS.4 = test.example.org    # Внешний домен
Обратите внимание!

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

Далее необходимо сгенерировать CSR с указанием SAN:

openssl req -new -key private_key.pem -out request.csr -config san.cnf -sha256

Убедитесь, что поле SAN было успешно добавлено:

openssl req -in request.csr -noout -text | grep -A1 "Subject Alternative Name"

Форматы сертификатов и конвертация​

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

Основные форматы сертификатов​

  • PEM - текстовый (Base64), стандарт для Linux/OpenSSL

  • DER - бинарный, используется в Java/Windows

  • PKCS#12 (.p12/.pfx) - содержит сертификат + ключ с паролем

  • PKCS#7 (.p7b) - только цепочка сертификатов

Основные команды конвертации​

PEM ↔ DER

openssl x509 -in cert.pem -outform der -out cert.der
openssl x509 -inform der -in cert.der -out cert.pem

PEM → PKCS#12 (с ключом)

openssl pkcs12 -export -in cert.pem -inkey key.pem -out bundle.p12

PKCS#12 → PEM (сертификат + ключ)

openssl pkcs12 -in bundle.p12 -out cert.pem -nodes

Извлечение только закрытого ключа из PKCS#12

openssl pkcs12 -in bundle.p12 -nocerts -nodes -out private.key

Просмотр и проверка сертификатов​

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

openssl x509 -in cert.pem -noout -text

Команда отображает:

  • основные данные (версия, серийный номер, алгоритм подписи)

  • срок действия (Validity)

  • издателя (Issuer) и владельца (Subject)

  • публичный ключ

  • расширенные поля (SAN, Key Usage)

  • подпись сертификата

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

  • DER:
openssl x509 -in cert.der -inform der -noout -text
  • PKCS#12:
openssl pkcs12 -in bundle.p12 -nodes -info -nokeys
Обратите внимание!

Не рекомендуется указывать пароль в открытом виде в командной строке, так как такая команда сохраняется в истории выполнения команд. Пример небезопасного использования с открытым паролем:

openssl pkcs12 -in bundle.p12 -nodes -info -nokeys -password pass:"123"
  • PKCS#7:
openssl pkcs7 -in chain.p7b -print_certs -inform der
Обратите внимание!

Некоторые форматы (например, PKCS#12 и PKCS#7) не содержат полной информации о сертификатах. Для более детального анализа рекомендуется конвертировать их в формат PEM и использовать openssl x509.

Проверка валидности сертификата и ключа​

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

Примечание

Команды просмотра содержимого сертификатов в различных форматах указаны в разделе Просмотр и проверка сертификатов.

Команды для проверки:

  • проверка соответствия ключа и сертификата (хеши должны совпадать)
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5
  • если используется ключ в формате PKCS#8:
openssl pkey -noout -modulus -in private.key | openssl md5
  • проверка соответствия ключа и сертификата из PFX-файла:
openssl pkcs12 -in bundle.pfx -nocerts -nodes | openssl rsa -noout -modulus | openssl md5
  • проверка срока действия сертификата:
openssl x509 -in certificate.crt -noout -dates
  • проверка структуры PEM-файла (если формат неверный, будет ошибка):
openssl x509 -in certificate.crt -noout
Обратите внимание!

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

Подпись сертификатов​

Цифровая подпись — это результат криптографической обработки данных сертификата (включая информацию о субъекте, публичном ключе и сроке действия) с использованием приватного ключа удостоверяющего центра (CA). Подпись позволяет удостовериться, что сертификат:

  • был выдан доверенным центром сертификации (CA)

  • не был подделан или изменен

  • относится к конкретному публичному ключу

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

Способы заверения сертификатов​

Существует два основных типа заверенных сертификатов:

  • Самоподписанный (self-signed) — подписывается собственным приватным ключом

  • Подписанный внешним CA — подписывается удостоверяющим центром, приватный ключ которого недоступен

Обратите внимание!

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

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

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

Создание сертификата корневого CA (root CA) выполняется в два этапа:

  • создание приватного ключа:
openssl req -x509 -new -key private.key -out cert.crt -days 365 -sha256
  • создание самоподписанного сертификата:
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt
Примечание

Этот сертификат будет использоваться для подписи других сертификатов.

Подписание CSR с помощью самоподписанного CA​

После генерации файла запроса на сертификат request.csr, следующим этапом является его подписание CA сертификатом для получения полноценного действующего сертификата.

Если требуется использовать расширения сертификата (например, SAN или Extended Key Usage), используйте конфигурационный файл OpenSSL (openssl_ca.cnf) и команду openssl ca:

openssl ca -config openssl_ca.cnf -in request.csr -out server.crt \
-days 825 -extensions v3_req -batch -notext -md sha256

Пояснение к параметрам, используемым в команде openssl ca:

  • -config — путь к конфигурационному файлу (openssl_ca.cnf)

  • -in — путь к CSR-файлу

  • -out — путь, по которому будет сохранен выходной сертификат

  • -extensions v3_req — имя секции в конфигурационном файле с нужными расширениями

  • -batch — отключить интерактивные запросы

  • -notext — не добавлять человекочитаемую часть в сертификат

  • -sha256 — использовать алгоритм хеширования SHA256

В результате выполнения команды будет создан подписанный сертификат server.crt на основе запроса request.csr подписанного файлами CA сертификата ca.crt и ca.key.

Проверка подписи и цепочки доверия​

Проверить, что сертификат был подписан конкретным CA, можно с помощью следующей команды:

openssl verify -CAfile ca.crt server.crt

При успешной проверке будет выведено сообщение: server.crt: OK.

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

Прежде чем добавить сертификат в список доверенных, необходимо выполнить следующие проверки:

  • подлинность подписи (проверка цепочки доверия)

  • актуальность срока действия сертификата

  • отсутствие в списках отзыва

Данная команда:

openssl verify -CAfile root_ca.crt -untrusted intermediate.crt server.crt

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

  • root_ca.crt — корневой (доверенный) сертификат удостоверяющего центра (CA)

  • intermediate.crt — промежуточный сертификат, выданный корневым CA

  • server.crt — проверяемый конечный сертификат

Для проверки PEM-сертификата с CA-цепочкой используется команда:

openssl verify -CAfile ca_bundle.pem certificate.pem

Обмен сертификатами​

Настройка доверенных сертификатов​

Java-приложения используют специальные хранилища (truststore) для управления доверенными сертификатами. Для добавления CA-сертификата в truststore используйте следующую команду:

$JAVA_HOME/bin/keytool -import -trustcacerts -alias ca_cert -file ca_cert.der -keystore truststore.jks -storepass password
Обратите внимание!

Команда требует установленной Java и корректно заданной переменной окружения JAVA_HOME. Убедитесь, что Java установлена, и путь к keytool доступен по $JAVA_HOME/bin/keytool. Если JAVA_HOME не задан, можно использовать полный путь вручную, например:

/usr/lib/jvm/java-17-openjdk-amd64/bin/keytool -import -trustcacerts -alias ca_cert -file ca_cert.der -keystore truststore.jks -storepass password

Пояснения к параметрам команды:

  • -trustcacerts — указывает, что импортируемый сертификат является доверенным сертификатом центра сертификации (CA)

  • -alias ca_cert — псевдоним (alias) для импортируемого сертификата, используется для идентификации внутри хранилища

  • -file ca_cert.der — путь к файлу сертификата, который нужно импортировать (формат DER)

  • -keystore truststore.jks — имя файла truststore, куда будет добавлен сертификат

  • -storepass password — пароль для доступа к truststore

Получение сертификатов удаленных узлов​

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

openssl s_client -connect remote-host:9200 -showcerts </dev/null 2>/dev/null | openssl x509 -out remote_cert.pem
Обратите внимание!

Информация о проверке корректности сертификатов, в том числе цепочки доверия и подписи, содержится в разделе Проверка подписи и цепочки доверия.