Самоподписанный SSL в Linux — создание и настройка

Клавиатура с навесным замком, символ цифровой безопасности

Создать самоподписанный SSL-сертификат в Linux просто: достаточно OpenSSL и одной команды. Это подходит для разработки, тестирования и внутренних сетей, но браузеры будут показывать предупреждение, поэтому для публичных сайтов предпочтительнее доверенный CA (например, Let’s Encrypt).

В этой статье вы найдёте пошаговые команды, расширенные варианты (с SubjectAltName), проверку, рекомендации по безопасности и чеклисты для ролей.

Что такое SSL-сертификат?

Одной строкой: SSL/TLS-сертификат подтверждает идентичность сервера и устанавливает зашифрованный канал между сервером и браузером.

Определение: SSL (Secure Socket Layer) и его преемник TLS — криптографические протоколы, шифрующие трафик и предотвращающие перехват и подмену данных в канале.

Почему это важно:

Защита конфиденциальных данных пользователей.
Предотвращение атак “man-in-the-middle”.
Требование для современных браузеров при передаче паролей, платежей и личной информации.

Когда уместен самоподписанный сертификат

Используйте самоподписанный сертификат для:

Локальной разработки и тестов.
Внутренних сервисов в защищённой сети (интранет, VPN).
Пилотных развертываний и демо-окружений.

Когда не стоит применять:

Для публичных веб-сайтов, где пользователи должны доверять сайту без предупреждений.
Для платёжных систем и сервисов, где требуется аудит сторонних CA.

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

Установка OpenSSL на Linux

Проверьте, установлен ли OpenSSL:

openssl version

Если не установлен, выполните команду для вашей дистрибуции:

Debian/Ubuntu/Mint:

sudo apt install openssl

Fedora/CentOS (DNF):

sudo dnf install openssl

Arch Linux:

pacman -S openssl

После установки команда openssl должна вернуть версию. OpenSSL — инструмент командной строки для создания ключей, CSR, сертификатов и конвертации форматов.

Простое создание самоподписанного сертификата

Перейдите в каталог, где хотите сохранить файлы, затем выполните команду (замените myserver на нужные имена файлов):

openssl req -newkey rsa:4096 -x509 -sha256 -days 365 -nodes -out myserver.crt -keyout myserver.key

Что делает команда:

-newkey rsa:4096 — создаёт новый RSA-ключ 4096 бит.
-x509 — создаёт самоподписанный сертификат вместо CSR.
-sha256 — алгоритм хэширования для подписи.
-days 365 — срок действия сертификата (здесь — 1 год).
-nodes — приватный ключ не шифруется паролем (не рекомендуется для продакшена).
-out / -keyout — имена файла сертификата и ключа.

При выполнении вы увидите запросы: Country, State/Province, Locality, Organization, Organizational Unit, Common Name (CN) и Email. В поле Common Name укажите доменное имя (например, example.local или myserver.internal).

Терминал Linux с командой OpenSSL, создание SSL-сертификата

Важно: современные браузеры игнорируют CN, если не указан SubjectAltName (SAN). По умолчанию самоподписанный сертификат, созданный выше, может не соответствовать требованиям браузера для доменов/поддоменов. Следующие разделы показывают, как добавить SAN.

Создание сертификата с SubjectAltName (SAN)

Чтобы браузеры корректно принимали сертификат (при ручном доверии) и чтобы сертификат соответствовал современным требованиям, создайте конфигурационный файл OpenSSL с расширениями для SAN.

Пример файла openssl-san.cnf:

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

[req_distinguished_name]
C = RU
ST = Moscow
L = Moscow
O = My Company
OU = Dev
CN = myserver.local

[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.local
DNS.2 = www.myserver.local
IP.1 = 192.168.1.10

Создание ключа и сертификата с использованием этого конфига:

openssl req -new -newkey rsa:2048 -nodes -keyout myserver.key -out myserver.csr -config openssl-san.cnf
openssl x509 -req -in myserver.csr -signkey myserver.key -days 365 -out myserver.crt -extensions v3_req -extfile openssl-san.cnf

Эта последовательность создаёт CSR и затем подписывает его вашим приватным ключом, добавляя SAN. Таким сертификатам проще доверять вручную в браузере.

Импорт сертификата в браузер и ОС

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

Примеры:

Firefox: Настройки → Приватность и безопасность → Просмотреть сертификаты → Authorities → Импорт.
Chrome (на Linux): системное хранилище сертификатов; команды зависят от дистрибутива.
Для автоматизации в корпоративной среде используйте групповую политику (Windows AD) или управление конфигурацией (Puppet/Ansible).

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

Конвертация в PKCS#12 (для импортов и проксей)

Некоторые сервисы (например, IIS или некоторые балансировщики нагрузки) ожидают PKCS#12 (.p12/.pfx). Создайте пакет из ключа и сертификата:

openssl pkcs12 -export -out myserver.p12 -inkey myserver.key -in myserver.crt

Вам будет предложено задать пароль для .p12-файла — он защитит пакет при переносе.

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

Пара полезных команд для проверки:

Проверить содержимое сертификата:

openssl x509 -in myserver.crt -text -noout

Соединиться к серверу и посмотреть цепочку (полезно для проверки SAN и версии TLS):

openssl s_client -connect myserver.local:443 -servername myserver.local

Проверить доступность HTTPS через curl (игнорируя проверку сертификата):

curl -v --insecure https://myserver.local/

Если браузер всё ещё жалуется на “не доверено”, убедитесь, что:

Сертификат импортирован в правильное хранилище (Authorities).
Имя в SAN совпадает с URL, который вы открываете.
Сервер отдаёт правильный сертификат (на виртуальных хостах — конфигурация сервера должна указывать сертификат для конкретного хоста).

Лучшие практики безопасности

Не храните приватный ключ без защиты, если это продакшен: используйте шифрование ключа и безопасное хранилище (HSM, Vault).
Ограничьте права на файл ключа: chmod 600 myserver.key и владелец root или пользователь сервиса.
Используйте надежный размер ключа (2048+ бит для RSA; 4096 для большей криптостойкости).
Для публичных сайтов используйте сертификат от доверенного CA (Let’s Encrypt — бесплатный автоматизированный вариант).
Автоматизируйте обновления сертификатов (cron, systemd timer, Certbot, ACME-клиенты).

Important: опция -nodes означает, что приватный ключ не шифруется паролем. Это удобно для автоматического запуска сервисов, но увеличивает риск компрометации при утечке файловой системы.

Альтернативы самоподписанному сертификату

Let’s Encrypt (ACME) — бесплатный, автоматизированный и доверенный CA.
Собственный корпоративный CA — если нужно централизованное управление внутренними сертификатами и автоматическое распространение доверия.
Сертификаты от коммерческих CA — для публичных ресурсов с гарантией и поддержкой.

Рольные чеклисты

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

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

Для инженера по безопасности:

Проверить права на ключи (chmod, владелец).
Убедиться в сроках действия и планах продления.
Настроить мониторинг и оповещения об истечении сертификатов.

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

Развернуть сертификат в конфигурации web-сервера (Nginx/Apache).
Перезапустить сервис и протестировать шифрование (TLS).
Конвертировать в PKCS#12 при необходимости импортов.

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

Сертификат присутствует и корректно загружается сервером.
Имя сервера присутствует в SubjectAltName.
Приватный ключ защищён правами доступа (не world-readable).
Для внутренних сервисов сертификат добавлен в доверенное хранилище клиентов, если нужно.

Частые ошибки и способы их устранения

Ошибка: браузер жалуется на имя хоста. Решение: добавить правильный SAN и пересоздать сертификат.
Ошибка: сервер отдаёт не тот сертификат (при SNI). Решение: проверить конфигурацию виртуальных хостов и приоритизацию сертификатов.
Ошибка: забытый пароль от .p12. Решение: пересоздать пакет из исходных cert/key.

Короткая методология (шаблон)

Установить OpenSSL и перейти в рабочий каталог.
Подготовить openssl-san.cnf с нужными SAN.
Создать ключ и CSR.
Подписать CSR своим ключом (самоподписать) или отправить в CA.
Импортировать/установить сертификат на сервер и перезапустить сервис.
Проверить соединение и цепочку.
Автоматизировать продление и мониторинг.

FAQ

Q: Будет ли самоподписанный сертификат шифровать трафик?
A: Да — шифрование работает так же, как и для сертификатов от CA; отличие в доверии (браузер покажет предупреждение, если сертификат не доверен).

Q: Можно ли использовать самоподписанный сертификат в продакшене?
A: Только в строго контролируемых средах (внутренние сети). Для публичных сайтов используйте сертификаты от доверенных CA.

Q: Как добавить SAN в сертификат?
A: Создайте конфиг OpenSSL с секцией [alt_names] и используйте его при генерации CSR/сертификата, как в примере выше.

Q: Как продлить самоподписанный сертификат?
A: Пересоздать сертификат с новым сроком действия и заменить файл на сервере; затем перезапустить сервис.

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

Самоподписанный SSL в Linux — быстрый инструмент для разработки и внутренних сервисов. Для публичных веб-сайтов рекомендуется использовать доверенный центр сертификации. Всегда добавляйте SubjectAltName и защищайте приватный ключ.

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