Коротко. Самый быстрый путь — выпустить сертификат через встроенный в хостинг Let’s Encrypt: одна кнопка в панели, автоматическая валидация домена, готово за 1-5 минут. Если сертификат нужно выпускать вручную (внешний удостоверяющий центр, OV/EV, нестандартный сервер), порядок такой: сгенерировать пару ключей и CSR-запрос, пройти проверку владения доменом одним из трёх способов (файл на сервере, DNS-запись или письмо на почту), получить файл сертификата и установить его вместе с приватным ключом. Весь ручной цикл занимает от 10 минут для DV до нескольких дней для OV.
Два пути: автоматика и ручной выпуск
Прежде чем разбираться с CSR и валидацией, стоит понять, нужно ли это вообще. Если сайт стоит на обычном хостинге с панелью управления (ISPmanager, cPanel, VestaCP, панель у большинства российских хостеров), там почти наверняка есть встроенная интеграция с Let’s Encrypt: выбрал домен, нажал «Выпустить SSL», через пару минут сертификат уже установлен и подключён — никакого CSR руками генерировать не нужно, панель делает это сама. Ручной цикл нужен в трёх случаях: сертификат покупается у стороннего удостоверяющего центра (Sectigo, DigiCert, GlobalSign), нужен уровень OV/EV с проверкой организации, или сервер настроен нестандартно и панели с автоматикой просто нет. При запуске нового сайта этот вопрос обычно закрывается сразу в рамках разработки, без отдельного обращения к CSR и удостоверяющим центрам. Дальше — именно про ручной путь, потому что именно там теряются время и нервы.
Что такое CSR и что в нём зашито
CSR (Certificate Signing Request) — это файл-запрос на выпуск сертификата, который сайт (точнее, сервер) отправляет удостоверяющему центру. Он создаётся вместе с парой ключей: приватный ключ остаётся на сервере и никому не передаётся, а в CSR попадает открытая часть плюс данные о домене — Common Name (сам домен, например example.ru), иногда организация, город, страна. Удостоверяющий центр подписывает эти данные своим ключом — так получается сертификат. Критичный момент, который чаще всего ломает весь процесс: если приватный ключ, сгенерированный вместе с CSR, потерян или заменён на другой до установки сертификата, выпущенный файл просто не подойдёт к серверу — придётся создавать новый CSR и проходить проверку заново.
Как сгенерировать CSR вручную
На сервере с доступом по SSH это делается одной командой через OpenSSL, которая создаёт сразу приватный ключ и сам запрос:
openssl req -new -newkey rsa:2048 -nodes -keyout example.ru.key -out example.ru.csr
Команда попросит заполнить поля: страну (RU), регион, город, название организации (можно пропустить для DV), и обязательно — Common Name, куда нужно вписать точный домен сайта. Здесь встречается частая ошибка: если сайт открывается и по example.ru, и по www.example.ru, а в CSR указан только один вариант, второй адрес окажется без валидного сертификата — браузер покажет предупреждение о несоответствии домена. Решение — либо выпускать SAN-сертификат сразу на оба варианта, либо явно проверить у панели или удостоверяющего центра, что оба домена включены в запрос. Файл .csr дальше вставляется в форму заказа у удостоверяющего центра или реселлера, ключ .key остаётся на сервере до момента установки готового сертификата.
Три способа проверить владение доменом
После отправки CSR удостоверяющий центр должен убедиться, что заявитель действительно управляет доменом. Есть три метода, и выбор чаще всего диктуется тем, есть ли доступ к серверу и к DNS-записям домена.
| Способ | Как работает | Время | Когда подходит |
|---|---|---|---|
| HTTP-файл | На сервер выкладывается файл с уникальным кодом по указанному пути | обычно проверяется в течение нескольких минут после загрузки | Есть доступ к файловой системе сайта; не подходит для wildcard |
| DNS-запись (TXT/CNAME) | В зону домена добавляется временная запись с кодом от центра сертификации | от нескольких минут до 24 часов — зависит от TTL и скорости обновления зоны у регистратора | Единственный способ для wildcard-сертификатов; нужен доступ к DNS, не обязательно к серверу |
| Письмо с кодом подтверждения отправляется на служебный адрес вида admin@example.ru или из данных WHOIS | зависит от скорости проверки почты, обычно минуты | Нет доступа ни к серверу, ни к DNS, но есть доступ к почте на домене |
DNS-способ — самый универсальный и единственный вариант для wildcard-сертификата (*.example.ru), потому что HTTP-файл физически нельзя разместить сразу на всех возможных поддоменах. Обратная сторона DNS-метода — зависимость от TTL записи и скорости, с которой регистратор домена применяет изменения в зоне: если TTL стоит на 24 часа, проверка может ждать этот срок, даже если запись добавлена мгновенно.
Let’s Encrypt: та же логика, но бесплатно и автоматически
Let’s Encrypt работает по протоколу ACME — по сути, это автоматизация всех шагов выше: клиент (обычно certbot) сам генерирует ключ и CSR, сам проходит HTTP- или DNS-валидацию и сам получает готовый сертификат, без ручного копирования файлов в форму заказа. На сервере с SSH-доступом и правами администратора команда для сайта на Nginx выглядит так:
certbot --nginx -d example.ru -d www.example.ru
Certbot сам поднимает временный HTTP-файл для валидации, получает сертификат и прописывает его в конфигурацию сервера — весь цикл занимает 1-3 минуты. Для wildcard-сертификата через Let’s Encrypt нужен только DNS-01 метод — потребуется плагин под конкретного DNS-провайдера или ручное добавление TXT-записи, если провайдер не поддерживается автоматикой. Срок действия сертификата от Let’s Encrypt — 90 дней, но certbot по умолчанию ставит задачу автопродления, которая пытается обновить сертификат за 30 дней до истечения — вручную возвращаться к этому процессу не нужно, если автопродление не сломалось (например, из-за смены IP или блокировки порта 80).
Типичные причины провала валидации
Валидация домена — самое частое место, где процесс стопорится, и почти всегда причина одна из четырёх. Сайт стоит за Cloudflare или другим прокси с включённым проксированием — тогда HTTP-файл, положенный на исходный сервер, может быть недоступен по внешнему IP, который видит удостоверяющий центр; решение — либо временно выключить проксирование (перевести запись в DNS-only), либо использовать DNS-валидацию. Порт 80 закрыт файрволом — certbot и большинство HTTP-методов используют именно его для проверки, если он заблокирован, проверка не пройдёт даже при полностью рабочем сайте на 443. TTL DNS-записи слишком высокий — при DNS-валидации центр сертификации может не увидеть свежую запись, если старое значение ещё живёт в кэше по старому TTL. И последнее — домен указывает не на тот сервер, где выполняется валидация: типичная ситуация при миграции сайта на новый хостинг, когда DNS ещё не переключён, а CSR уже сгенерирован на новом сервере.
После выпуска: что ставить на сервер
Готовый сертификат от удостоверяющего центра — это обычно не один файл, а минимум два: сам сертификат домена и промежуточный сертификат (intermediate/chain), который подтверждает цепочку доверия до корневого центра. Если на сервер установить только сертификат домена без цепочки, часть браузеров и мобильных приложений будет показывать ошибку недоверенного сертификата, хотя в обычном браузере на десктопе всё может выглядеть нормально — эта проверка у разных клиентов настроена по-разному, и полагаться на «в браузере же работает» не стоит. На сервер вместе с сертификатом и цепочкой возвращается приватный ключ, сгенерированный на первом шаге вместе с CSR — без него связка не соберётся. У Let’s Encrypt через certbot всё это упаковывается автоматически, вручную с этим приходится разбираться только при работе с внешними удостоверяющими центрами. Если такие вещи проверять и поддерживать самостоятельно неудобно, установку и продление обычно передают в техническую поддержку сайта — там же заодно проверяют, не потерял ли сертификат актуальность после смены хостинга или переезда сайта.
FAQ
Можно ли сгенерировать CSR без доступа к серверу по SSH?
Да, если хостинг-панель поддерживает это — в разделе SSL там обычно есть форма для генерации CSR прямо в интерфейсе, без командной строки. Если панели с такой функцией нет, CSR можно сгенерировать на любом компьютере с установленным OpenSSL, а готовый сертификат потом передать администратору сервера для установки.
Что делать, если приватный ключ от CSR потерян?
Нужно сгенерировать новый CSR с новой парой ключей и заново пройти валидацию домена — привязать выпущенный сертификат к другому ключу без переоформления нельзя.
Почему DNS-валидация иногда идёт сутками, хотя запись уже добавлена?
Обычно дело в TTL — времени жизни записи в кэше DNS-серверов. Если у зоны стоит TTL 24 часа, некоторые резолверы будут отдавать старое (пустое) значение, пока не истечёт этот срок, даже если запись реально добавлена мгновенно. Перед плановой валидацией TTL стоит заранее снизить до нескольких минут.
Нужно ли заново проходить валидацию домена при каждом продлении Let’s Encrypt?
Да, формально это не «продление» в привычном смысле, а выпуск нового сертификата с новой проверкой — но certbot делает это автоматически без участия человека, если автопродление настроено и ничего не сломалось на сервере.
Сертификат выпустился, но браузер всё равно пишет «небезопасное соединение» — почему?
Чаще всего это либо смешанный контент (часть ресурсов страницы — картинки, скрипты — всё ещё грузится по http://), либо не установлена цепочка промежуточных сертификатов. Первое ищется в исходном коде страницы, второе проверяется через любой онлайн-чекер SSL, который явно покажет, что цепочка неполная — этот же момент проверяют в рамках SEO-аудита, потому что смешанный контент и битые сертификаты влияют на доверие поисковика к сайту.
Не хочется разбираться с CSR и валидацией руками
На бесплатном аудите проверим, как сейчас выпущен и настроен SSL на сайте, и возьмём на себя выпуск или переустановку сертификата.