Как сгенерировать самозаверяющий сертификат с помощью OpenSSL?

Самоподписанный сертификат — это сертификат, который вы выпускаете для себя, а не покупаете у центра сертификации. Браузеры не доверяют ему автоматически, поэтому ему нет места на публичном веб-сайте, но это самый быстрый способ включить HTTPS на машине для разработки, на тестовом сервере, на внутренней панели управления или на любом сервисе, который никогда не будет доступен из открытого интернета.

Это руководство показывает, как создать самоподписанный сертификат с помощью OpenSSL в Windows, Linux и macOS. Команда одна и та же на всех трех платформах. Вы также узнаете, как проверить, что созданный вами сертификат действительно работает, и как заставить вашу собственную машину доверять ему, чтобы предупреждения браузера исчезли.

Что такое самоподписанный сертификат

Самоподписанный сертификат — это цифровой сертификат, подписанный собственным закрытым ключом, а не доверенным центром сертификации (CA). С криптографической точки зрения это обычный сертификат X.509: он шифрует трафик точно так же, как и купленный сертификат. Чего ему не хватает — это цепочки доверия. У ничего за пределами вашей собственной машины нет причин доверять ему, поэтому браузеры показывают предупреждение, если вы не укажете иначе.

Это делает самоподписанные сертификаты хорошим решением для:

• Локальной разработки, где вам нужен HTTPS, чтобы куки, service worker’ы или платежный SDK работали так же, как в продакшене.
• Внутренних сервисов, таких как панель управления интранетом, панель мониторинга или интерфейс управления устройствами в частной сети.
• Тестирования и стейджинга, где вы хотите опробовать конфигурацию TLS без затрат на сертификат.
• Исходных серверов за прокси, который принимает недоверенный сертификат на внутреннем участке, например Cloudflare в режиме Full.

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

Перед началом: проверьте свой OpenSSL

Вам понадобится инструмент командной строки OpenSSL. Проверьте, что у вас установлено:

openssl version

• Linux: OpenSSL предустановлен в большинстве дистрибутивов. Если это не так, смотрите наше руководство по установке OpenSSL на Ubuntu.
• Windows: OpenSSL не включен по умолчанию. Следуйте нашим инструкциям по установке OpenSSL на Windows, затем выполните команду в Command Prompt или PowerShell.
• macOS: Apple поставляет LibreSSL, форк OpenSSL, в качестве встроенной команды openssl, поэтому она возвращает что-то вроде LibreSSL 3.3.6, а не версию OpenSSL.

Основная команда в этом руководстве работает как на LibreSSL 3.3.6, так и на актуальном OpenSSL, поэтому пользователи Mac могут использовать встроенный инструмент. Если вы предпочитаете иметь настоящий OpenSSL (некоторые из дополнительных команд ниже требуют его), установите его с помощью менеджера пакетов Homebrew и вызывайте его по полному пути:

brew install openssl@3
/opt/homebrew/opt/openssl@3/bin/openssl version

На Mac с процессором Intel путь вместо этого будет /usr/local/opt/openssl@3/bin/openssl. Подробнее о том, как читать вывод, см. в нашем руководстве по проверке версии OpenSSL.

Как создать самоподписанный сертификат с помощью OpenSSL

Шаг 1: Откройте терминал

В Linux нажмите Ctrl + Alt + T или найдите «Terminal» в меню приложений. В macOS откройте Applications, затем Utilities, затем Terminal, или нажмите Cmd + Space и введите «Terminal». В Windows нажмите Win + R, введите cmd и нажмите Enter.

Шаг 2: Перейдите в папку, куда хотите поместить файлы

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

mkdir my-cert
cd my-cert

В Windows используйте те же две команды в Command Prompt. Не запускайте команды из папки программы OpenSSL: в Windows этот каталог часто недоступен для записи обычному пользователю, а хранение ключей вместе с исполняемыми файлами делает их легко теряемыми.

Шаг 3: Выполните команду создания сертификата

Эта единственная команда генерирует одновременно закрытый ключ и самоподписанный сертификат. Замените example.com и www.example.com на имена, по которым будет фактически доступен ваш сервис:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Оставьте команду на одной строке. Command Prompt и оболочки Unix используют разные символы переноса строки, а одна строка работает везде. По той же причине используйте двойные кавычки, а не одинарные: Command Prompt не воспринимает одинарные кавычки как кавычки.

Вот что делает каждая часть:

• req -x509: создать готовый, подписанный сертификат вместо запроса на подпись сертификата.
• -newkey rsa:2048: создать новый 2048-битный закрытый ключ RSA в рамках той же команды. 2048 бит — это текущий минимум и разумное значение по умолчанию. Используйте rsa:4096, если ваша политика требует более крупного ключа, за счет более медленного установления соединения.
• -keyout private.key: имя файла для закрытого ключа.
• -out certificate.crt: имя файла для сертификата.
• -days 365: срок действия сертификата. Прежде чем менять это значение, смотрите раздел о сроке действия ниже.
• -nodes: оставить закрытый ключ незашифрованным, чтобы ваш веб-сервер мог запускаться без ввода парольной фразы человеком.
• -addext «subjectAltName=…»: список имен хостов, для которых действителен сертификат. Без этого сертификат не будет соответствовать ничему.
• -addext «basicConstraints=critical,CA:FALSE»: обозначить сертификат как конечный (серверный), а не как сертификат центра сертификации.
• -addext «extendedKeyUsage=serverAuth»: указать, что сертификат предназначен для аутентификации TLS-сервера. Платформы Apple считают это обязательным.

Почему важны три опции -addext

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

Subject Alternative Name — это то, где хранятся имена хостов. Браузеры давно перестали читать поле Common Name и теперь сопоставляют имя хоста только с расширением Subject Alternative Name (SAN). Сертификат без SAN не соответствует ни одному сайту, независимо от того, насколько правильным выглядит Common Name. Укажите все имена, которые вы будете использовать, разделенные запятыми. Для локального сервиса можно также включить IP-адрес:

-addext "subjectAltName=DNS:localhost,DNS:dev.example.com,IP:127.0.0.1"

Без CA:FALSE OpenSSL создаст вам сертификат CA. Когда req -x509 оставлена со своими стандартными настройками, она устанавливает basicConstraints в critical, CA:TRUE, что описывает центр сертификации, а не веб-сервер. Chrome и Safari принимают это на серверном сертификате. Firefox нет и останавливается с ошибкой MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY. Вы все еще можете нажать «Дополнительно» и добавить исключение, но вы будете обходить сертификат, который вы уже знаете, что он некорректно сформирован, а другие клиенты проводят границу в разных местах. Передача basicConstraints=critical,CA:FALSE позволяет избежать этой ситуации с самого начала.

Сборка LibreSSL, которую поставляет macOS, ведет себя здесь иначе: оставленная со своими стандартными настройками, она создает сертификат X.509 версии 1 без каких-либо расширений вообще, поэтому у вас не будет проблемы с CA:TRUE, но также не будет и Subject Alternative Name. Явное указание расширений дает вам один и тот же, корректный сертификат на обоих инструментах.

Без serverAuth платформы Apple отклоняют сертификат. Опубликованные Apple требования к доверенным сертификатам гласят, что сертификат TLS-сервера должен содержать расширение ExtendedKeyUsage, включающее OID id-kp-serverAuth. Сертификат без него не проходит проверку macOS в соответствии с политикой TLS с сообщением «Invalid Extended Key Usage for policy», даже если сертификат предоставлен как собственный якорь доверия. Firefox и Chrome более снисходительны и допускают отсутствие ExtendedKeyUsage на серверном сертификате, поэтому эту деталь легко пропустить, пока именно Mac или iPhone откажется подключаться. Добавление extendedKeyUsage=serverAuth ничего не стоит на других платформах и является тем, что публичный CA выпустил бы в любом случае.

Шаг 4: Заполните данные сертификата

OpenSSL запрашивает поля, составляющие Distinguished Name. Нажмите Enter, чтобы пропустить любое из них, но заполните хотя бы одно, и пусть это будет Common Name. Сборка LibreSSL на macOS останавливается с сообщением «error, no objects specified in config file» и ничего не записывает, если вы оставите все поля пустыми. Приведенные ниже значения — примеры, поэтому используйте свои собственные:

• Country Name: двухбуквенный код вашей страны, например US.
• State or Province Name: написанное полностью, например California.
• Locality Name: ваш город, например San Jose.
• Organization Name: название вашей компании или проекта, например Example Inc.
• Organizational Unit Name: ответственная команда, например IT.
• Common Name: основное имя хоста, например example.com. Используйте то же имя, которое вы указали первым в списке Subject Alternative Name.
• Email Address: контактный адрес, например [email protected]. Необязательно.

На самом деле здесь важно только Common Name, и только как метка: сопоставление имени хоста выполняется по Subject Alternative Name, которое вы уже указали в командной строке. Все остальное — лишь описательная информация.

Вы заметите, что команда никогда не запрашивает пароль для запроса (challenge password). Это приглашение относится к запросам на подпись сертификата, и это рудиментарное поле, которое центры сертификации, как правило, игнорируют или отклоняют. Поскольку эта команда создает готовый сертификат, а не запрос, это приглашение вообще не появляется.

Шаг 5: Проверьте сертификат перед использованием

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

openssl x509 -in certificate.crt -noout -text

В блоке расширений X509v3 вы ищете ровно три вещи:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Extended Key Usage:
    TLS Web Server Authentication

Если строка Subject Alternative Name отсутствует, сертификат не будет соответствовать ни одному имени хоста. Если Basic Constraints указывает CA:TRUE, Firefox остановится на нем. Если строка Extended Key Usage отсутствует, платформы Apple откажут в приеме сертификата. В любом из этих случаев удалите оба файла и выполните команду снова со всеми тремя опциями -addext.

В OpenSSL 3.x вы можете запросить только эти расширения, вместо того чтобы читать весь сертификат:

openssl x509 -in certificate.crt -noout -ext subjectAltName,basicConstraints,extendedKeyUsage

Флаг -ext не существует в сборке LibreSSL, которую поставляет macOS, она выдает «unknown option -ext». На стандартном Mac используйте версию с -text выше.

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

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

Сам сертификат представляет собой текстовый файл. Открыв его в текстовом редакторе, вы увидите блок base64 между строками BEGIN CERTIFICATE и END CERTIFICATE, который вы вставляете в панели управления, запрашивающие сертификат, а не загрузку файла.

Варианты команды

Создание без запросов

Для скриптов и CI-пайплайнов укажите Distinguished Name с помощью -subj, и команда выполнится без вмешательства пользователя:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -subj "/C=US/ST=California/L=San Jose/O=Example Inc/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Использование EC-ключа вместо RSA

Ключи на основе эллиптических кривых меньше и быстрее, чем RSA, при эквивалентной надежности, и каждый современный браузер поддерживает их. P-256 — стандартный выбор:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

Результат подписан с помощью ecdsa-with-SHA256. Оставайтесь на RSA, если вам нужно поддерживать старые встроенные клиенты или устаревшие версии Java, которым иногда не хватает поддержки EC.

Для этого используйте настоящий OpenSSL. Сборка LibreSSL на macOS принимает эту команду, но записывает кривую в сертификат в виде полного набора явных параметров, а не стандартного идентификатора P-256. RFC 5480 указывает, что явная форма не должна использоваться в сертификатах, и сам macOS отклоняет сертификат, закодированный таким образом.

Проверьте результат с помощью openssl x509 -in certificate.crt -noout -text: вам нужна строка «ASN1 OID: prime256v1», а не блок со списком Prime, A, B и Generator. На стандартном Mac либо используйте команду с RSA выше, либо сначала установите OpenSSL через Homebrew.

-nodes или -noenc?

Оба флага делают одно и то же: они предотвращают шифрование закрытого ключа OpenSSL с помощью парольной фразы. OpenSSL 3.x добавил -noenc как более понятное название и обозначает -nodes как устаревшее, хотя все еще принимает его. LibreSSL, которую поставляет macOS, вообще не распознает -noenc и выдает ошибку.

В этом руководстве используется -nodes, потому что это опция, которая работает в любой сборке, с которой вы, вероятно, столкнетесь, включая стандартный Mac. Если вы используете OpenSSL 3.x и хотите избежать устаревшего написания, замените на -noenc. Все остальное остается неизменным.

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

Заставьте вашу машину доверять сертификату

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

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

Связка ключей macOS (Keychain)

Добавьте сертификат в системную связку ключей и отметьте его как доверенный для TLS. Вас попросят ввести пароль администратора:

sudo security add-trusted-cert -d -r trustRoot -p ssl -k /Library/Keychains/System.keychain certificate.crt

Часть -p ssl ограничивает доверие TLS-соединениями. Уберите ее, и сертификат будет доверен для любых целей, известных macOS, включая подпись кода, что гораздо больше, чем требуется для сертификата разработки.

Чтобы сделать это через интерфейс, дважды щелкните файл сертификата, чтобы открыть Keychain Access, найдите запись в связке System, откройте ее, разверните Trust и установите значение When using this certificate в Always Trust. Чтобы отменить это позже, удалите запись из Keychain Access.

Хранилище сертификатов Windows

Откройте Command Prompt от имени администратора (нажмите Win + R, введите cmd, затем нажмите Ctrl + Shift + Enter) и добавьте сертификат в хранилище доверенных корневых центров сертификации:

certutil -addstore -f "Root" certificate.crt

Или же дважды щелкните файл сертификата, выберите Install Certificate, выберите Local Machine, затем Place all certificates in the following store и перейдите к Trusted Root Certification Authorities. Чтобы удалить его позже, откройте certmgr.msc и удалите запись из этого хранилища.

ca-certificates в Linux

В Debian и Ubuntu скопируйте сертификат в локальный каталог доверенных якорей и пересоберите пакет. Файл должен сохранять расширение .crt, иначе инструмент обновления его проигнорирует:

sudo cp certificate.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

В RHEL, CentOS, AlmaLinux, Rocky и Fedora пути отличаются:

sudo cp certificate.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

Исключение в Firefox

Firefox использует собственное хранилище доверенных сертификатов, а не хранилище операционной системы. В Windows и macOS он также по умолчанию читает корневые сертификаты, добавленные в хранилище ОС, поэтому описанные выше шаги обычно решают проблему. В Linux это не так, поэтому сертификат нужно импортировать в Firefox напрямую: откройте Settings, затем Privacy & Security, прокрутите до Certificates, нажмите View Certificates, откройте вкладку Authorities и используйте Import.

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

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

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

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