Это руководство показывает вам, как сгенерировать CSR на NGINX. NGINX сам не генерирует запросы на подпись сертификата: вы создаёте закрытый ключ и CSR с помощью OpenSSL на том же сервере, который будет обслуживать сертификат, а затем отправляете CSR в свой Центр сертификации. Когда выпущенный сертификат придёт обратно, вы указываете NGINX на него с помощью директив ssl_certificate и ssl_certificate_key.
Приведённые ниже шаги работают на любом поддерживаемом дистрибутиве Linux, поставляемом с NGINX (Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Amazon Linux), поскольку каждый из них поставляется с OpenSSL 1.1.1 или 3.x. Современный OpenSSL по умолчанию подписывает запросы с использованием SHA-256, поэтому добавлять флаг дайджеста не требуется.
Шаг 1: Подключитесь к вашему серверу NGINX
Подключитесь к серверу, на котором работает NGINX, по SSH со своей локальной машины (Terminal на macOS или Linux, PowerShell или Windows Terminal на Windows). Замените имя пользователя и хост на свои собственные:
ssh your-user@your-nginx-server
Сгенерируйте CSR на сервере, который будет обслуживать сертификат. Закрытый ключ создаётся рядом с CSR и должен оставаться на этом сервере. Выполнение этих команд локально с последующим копированием ключа куда-либо лишает смысла сам факт наличия закрытого ключа.
Шаг 2: Сгенерируйте закрытый ключ и CSR
Выполните следующую команду. Она создаёт закрытый ключ RSA длиной 2048 бит и соответствующий CSR за один шаг, с указанием субъекта и альтернативных имён субъекта (SAN) прямо в командной строке, чтобы OpenSSL не задавал дополнительных вопросов:
openssl req -new -newkey rsa:2048 -nodes
-keyout yourdomain.key
-out yourdomain.csr
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com"
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"
Что делает каждая часть:
- -newkey rsa:2048 генерирует новый ключ RSA длиной 2048 бит. 2048 бит — это текущий минимум, который принимают публичные CA; вы можете использовать rsa:4096 для более крупного ключа или переключиться на ECDSA (см. ниже).
- -nodes оставляет закрытый ключ незашифрованным, чтобы NGINX мог прочитать его при запуске без запроса пароля. Если вы предпочитаете зашифровать ключ, удалите -nodes и используйте директиву NGINX ssl_password_file, чтобы указывать пароль при запуске и перезагрузке.
- -keyout и -out задают имена файлов закрытого ключа и CSR.
- -subj задаёт субъект сертификата. Укажите здесь реальное название вашей компании, штат и город, а не значения-заполнители. CN (Common Name, общее имя) — это ваш основной домен.
- -addext «subjectAltName=…» перечисляет все имена хостов, которые должен покрывать сертификат. Публичные CA проверяют список SAN, поэтому включите туда и общее имя (Common Name). Флаг -addext требует OpenSSL 1.1.1 или новее; каждый поддерживаемый релиз Linux поставляется как минимум с этой версией.
Замените yourdomain.com на ваш реальный домен во всех местах. Чтобы покрыть дополнительные имена хостов, добавьте их в список SAN, разделяя запятыми, например DNS:api.yourdomain.com. Для wildcard-сертификата укажите как wildcard, так и обычный домен: DNS:*.yourdomain.com,DNS:yourdomain.com.
Если вы предпочитаете ключ ECDSA (меньше по размеру и быстрее, с широкой поддержкой P-256), сгенерируйте ключ и CSR следующим образом:
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes
-keyout yourdomain.key
-out yourdomain.csr
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com"
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"
Если ваш OpenSSL не поддерживает -addext
На очень старых системах с OpenSSL старше версии 1.1.1 флаг -addext недоступен. Создайте небольшой конфигурационный файл с именем san.cnf следующего содержания:
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext
[ dn ]
C = US
ST = YourState
L = YourCity
O = YourCompany
CN = yourdomain.com
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = yourdomain.com
DNS.2 = www.yourdomain.com
Затем выполните:
openssl req -new -newkey rsa:2048 -nodes
-keyout yourdomain.key -out yourdomain.csr -config san.cnf
Шаг 3: Найдите ваши файлы
Выведите список файлов в текущем каталоге, чтобы убедиться, что оба файла были созданы:
ls
Вы должны увидеть два новых файла:
- yourdomain.key: ваш закрытый ключ. Храните его на сервере, делайте надёжные резервные копии и никогда никому его не отправляйте, включая Центр сертификации. Тот, кто владеет ключом, может выдать себя за ваш сайт.
- yourdomain.csr: ваш запрос на подпись сертификата. Это файл, который вы отправляете провайдеру SSL.
Сразу же установите строгие права доступа на закрытый ключ, чтобы его мог читать только root:
sudo chmod 600 yourdomain.key
sudo chown root:root yourdomain.key
Шаг 4: Проверьте CSR (необязательно, но рекомендуется)
Перед отправкой убедитесь, что CSR содержит правильный субъект и SAN, а его подпись действительна. Эта команда расшифровывает запрос локально с помощью OpenSSL:
openssl req -noout -text -verify -in yourdomain.csr
Убедитесь, что строка Subject показывает ваши данные, что X509v3 Subject Alternative Name перечисляет все ожидаемые имена хостов, и что проверка подписи выводит verify OK. Алгоритм подписи должен отображаться как sha256WithRSAEncryption (или ecdsa-with-SHA256 для ключа ECDSA). Если вы предпочитаете не использовать командную строку, вставьте CSR в наш онлайн декодировщик CSR, чтобы просмотреть те же поля в браузере.
Шаг 5: Отправьте ваш CSR
Чтобы скопировать CSR для вашего заказа, выведите его содержимое:
cat yourdomain.csr
Вы увидите блок текста, похожий на этот:
-----BEGIN CERTIFICATE REQUEST-----
MIIBozCB... (a long string of characters)
-----END CERTIFICATE REQUEST-----
Скопируйте весь блок, включая строки ——BEGIN CERTIFICATE REQUEST—— и ——END CERTIFICATE REQUEST—— (у каждого маркера по пять дефисов с обеих сторон). Весь этот блок является вашим CSR. Вставьте его в форму заказа при покупке и сохраните соответствующий закрытый ключ на сервере.
Если вы предпочитаете не использовать командную строку, вы также можете создать запрос с помощью нашего онлайн генератора CSR. Обратите внимание, что он генерирует закрытый ключ в вашем браузере, поэтому сохраните этот ключ самостоятельно и переместите его на сервер.
Что происходит после того, как CA выпускает сертификат
После того как CA проверит CSR и выпустит сертификат, вы, как правило, получите свой серверный сертификат (файл .crt, названный по имени вашего домена) плюс один или несколько промежуточных сертификатов, иногда объединённых в файл .ca-bundle. NGINX ожидает, что серверный сертификат и промежуточная цепочка объединены в один файл («fullchain»), на который указывает ssl_certificate; закрытый ключ, сгенерированный вами выше, указывается отдельно с помощью ssl_certificate_key. Полная процедура (сборка fullchain, редактирование блока сервера, тестирование и перезагрузка) рассматривается в нашем руководстве по установке SSL на NGINX.
Сэкономьте 10% на SSL-сертификатах при заказе сегодня!
Быстрая выдача, надежное шифрование, 99,99% доверия к браузеру, специализированная поддержка и 25-дневная гарантия возврата денег. Код купона: SAVE10


