Генерация SSL/TLS сертификата с OpenSSL

Содержание

• Что такое OpenSSL?
• Ограничения самоподписанных сертификатов
• Установка
• Базовое использование
• Генерация сертификата с конфигурационным файлом
• Генерация сертификата без конфигурационного файла
• Проверка ключей и сертификатов
• Безопасность и рекомендации
• Альтернативы
• Критерии приёмки
• Часто задаваемые вопросы
• Краткое резюме

Что такое OpenSSL?

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

Ограничения самоподписанных сертификатов

Самоподписанный сертификат подписывается своим собственным приватным ключом, а не доверенным центром сертификации (CA). Следствия:

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

Важно: для публичных сервисов используйте бесплатные сертификаты от Let’s Encrypt или платные от проверенных CA.

Установка

Большинство дистрибутивов Linux поставляют OpenSSL в стандартных репозиториях.

На Ubuntu/Debian:

sudo apt update && sudo apt install openssl -y

На CentOS/RHEL (yum/dnf):

sudo yum install openssl -y

Или скачайте исходники с официального сайта в виде .tar.gz и соберите вручную, если нужна специфическая версия.

Также читайте: Как использовать cURL для передачи данных из командной строки

Базовое использование

Проверка установленной версии и информации:

openssl version -a

Просмотр встроенной справки:

openssl help

Эти команды пригодны для быстрой диагностики и подтверждения работоспособности утилиты.

Генерация сертификата с конфигурационным файлом

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

1. Создайте файл конфигурации, например example.conf:

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

[dn]
C = US
ST = California
L = Los Angeles
O = Org
OU = Sales
emailAddress = test@test.com
CN = www.org.test.com

[v3_ca]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = test.example.com

Редактирование с nano:

sudo nano example.conf

2. Сгенерируйте приватный RSA-ключ (2048 бит — минимально рекомендуемый размер для общего использования):

openssl genrsa -out example.key 2048

3. Создайте CSR, используя ключ и конфигурацию:

openssl req -new -key example.key -out example.csr -config example.conf

4. Сгенерируйте корневой сертификат (локальный CA) — самоподписанный, используемый для подписи выпускных сертификатов:

openssl req -x509 -sha256 -nodes -new -key example.key -out example.crt -config example.conf

5. Подпишите конечный сертификат CA (вариант: подписать CSR локальным CA и указать расширения из конфигурации):

openssl x509 -sha256 -CAcreateserial -req -days 365 -in example.csr -extfile example.conf -extensions req_ext -CA example.crt -CAkey example.key -out final.crt

Пояснения: -days задаёт срок действия в днях; -extfile и -extensions позволяют применить SAN и другие расширения из конфигурации.

Генерация сертификата без конфигурационного файла

Для быстрого локального сертификата можно обойтись без конфигов.

1. Генерация ключа:

openssl genrsa -out example.key 2048

2. Создание CSR (утилита задаст вопросы — страна, штат, CN и т.д.):

openssl req -new -key example.key -out example.csr

3. Подпись сертификата тем же ключом (получаем самоподписанный cert):

openssl x509 -req -days 365 -in example.csr -signkey example.key -out example.crt

Без конфигурации SAN не будет включён, и браузеры могут не считать сертификат валидным для альтернативных имён. Для тестов в CLI этого обычно достаточно.

Проверка ключей и сертификатов

Проверка приватного RSA-ключа:

openssl rsa -check -in example.key

Просмотр CSR в читаемом виде:

openssl req -text -noout -in example.csr

Просмотр сертификата:

openssl x509 -text -noout -in example.crt

Проверка соответствия приватного ключа и сертификата (сравнение модулей):

openssl rsa -noout -modulus -in example.key | openssl md5
openssl x509 -noout -modulus -in example.crt | openssl md5

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

Безопасность и рекомендации

Важно соблюдать базовые принципы безопасности при работе с ключами и сертификатами:

• Храните приватные ключи с ограниченным доступом (chmod 600). Например:

chmod 600 example.key

• Используйте ключи не короче 2048 бит; для большей долговечности — 3072 или 4096 бит.
• Срок действия сертификатов: для тестовых — короткий (30–90 дней), для production — согласно политике CA; часто сейчас рекомендуют обновлять чаще.
• Для публичных сервисов используйте проверенные CA (Let’s Encrypt, коммерческие CA). Let’s Encrypt автоматизирует выдачу и продление через ACME.
• Регулярно обновляйте OpenSSL до актуальных версий для избегания известных уязвимостей.

Риск-минимизация:

• Не храните приватные ключи в репозиториях кода.
• Делайте ротацию ключей при подозрении на компрометацию.
• Проверяйте и ограничивайте набор поддерживаемых шифров на сервере.

Альтернативы

• Let’s Encrypt — бесплатный автоматизированный CA, лучший выбор для публичных сайтов.
• Коммерческие CA (DigiCert, Sectigo и др.) — подходят для расширенного доверия, EV/OV сертификатов и поддержки.
• Управляемые решения (например, HashiCorp Vault) — удобны для большого числа сервисов и автоматической ротации ключей.

Когда этот подход не годится

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

Критерии приёмки

Минимальные критерии для считания сертификата корректно сгенерированным:

• Наличествуют приватный ключ (example.key) и сертификат (example.crt).
• CSR (example.csr) содержит правильный CN и SAN (если требуются альтернативные имена).
• Приватный ключ имеет права доступа 600 и хранится в безопасном месте.
• Сертификат валиден в течение заданного срока (проверка openssl x509 -noout -dates).

Полезные чек-листы по ролям

Для системного администратора:

• Проверить установку openssl и версию.
• Сгенерировать ключ/CSR и подписать сертификат.
• Настроить права на файлы ключей.
• Перезагрузить сервис (nginx/apache) и проверить HTTPS.

Для разработчика:

• Убедиться, что CN/SAN в CSR соответствует тестовому окружению.
• Добавить самоподписанный корневой сертификат в доверенные хранилища при необходимости.
• Тестировать HTTPS-клиенты на корректное поведение при самоподписанном cert.

Мини‑методология (быстрый план действий)

1. Решите, нужен ли самоподписанный сертификат или CA.
2. Подготовьте конфигурацию с SAN, если потребуется.
3. Сгенерируйте ключ и CSR.
4. Подпишите сертификат (локально или через CA).
5. Проверка и деплой на целевой сервис.
6. Автоматизируйте продление (ACME/скрипты) для production.

Часто задаваемые вопросы

1. Нужно ли волноваться о Heartbleed?

Heartbleed (CVE-2014-0160) — уязвимость OpenSSL, обнаруженная в 2014 году. Она была исправлена вскоре после обнаружения. Если вы используете современную поддерживаемую версию OpenSSL и регулярно устанавливаете обновления, то эта уязвимость вас не должна беспокоить. На Debian/Ubuntu обновление OpenSSL выполняется командами:

sudo apt update && sudo apt upgrade openssl -y

2. На сколько долго действуют SSL сертификаты?

Срок действия задаётся при генерации параметром -days. Для самоподписанных сертификатов вы сами выбираете срок (например, 30, 90, 365 дней). Для сертификатов от публичных CA действуют политики CA (Let’s Encrypt, например, выдаёт сертификаты обычно на 90 дней).

Проверка и отладка — типичные проблемы и решения

• Браузер показывает предупреждение о недоверенном сертификате: добавьте корневой сертификат в доверенные хранилища или используйте сертификат от доверенного CA.
• SAN отсутствует, и сайт доступен только по CN: при генерации включите subjectAltName через конфиг или опцию -addext (OpenSSL 1.1.1+ позволяет использовать -addext).
• Несовпадение ключа и сертификата: проверьте модуль ключа и сертификата (см. раздел Проверка).

Факто-бокс: ключевые числа и рекомендации

• Минимальная рекомендуемая длина RSA-ключа: 2048 бит.
• Популярный срок действия для тестов: 30 дней; для production — согласно политике CA (обычно 90–365 дней).
• Let’s Encrypt выдаёт сертификаты на 90 дней и рекомендует автоматическое обновление.

Совместимость и миграция

• Старые клиенты могут не поддерживать современные шифры и TLS 1.3; при настройке сервера учитывайте клиентов и включайте обратную совместимость аккуратно.
• При смене сертификата проверьте цепочку доверия (CA bundle) и проверьте на тестовых клиентах перед массовым деплоем.

Краткое резюме

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

Изображение: Sls, надпись на деревянном кубике (авторское право 123RF)