• Большинство проблем с SSL-сертификатами возникают не при настройке TLS, а на этапе создания CSR — неверные SAN, забытые поддомены, неправильные ожидания от wildcard.

  • Wildcard *.example.com покрывает только один уровень поддоменов и по стандарту не включает корневой домен — крупные публичные CA добавляют его в SAN сами, частные CA могут не добавлять.

  • С марта 2026 максимальный срок действия SSL-сертификатов начнёт сокращаться (до 47 дней к 2029), поэтому ручное обновление сертификатов для production перестаёт быть жизнеспособным.

  • OpenSSL остаётся базовым инструментом, но для multi-domain/wildcard конфигураций безопаснее использовать ACME-автоматизацию или CSR-генератор с локальной генерацией ключа.

CSR (Certificate Signing Request) — это закодированный текстовый файл с заявкой на выпуск SSL-сертификата. Он содержит публичный ключ, домены, для которых нужен сертификат, и информацию об организации. CSR подписывается приватным ключом владельца и отправляется в удостоверяющий центр (CA), который после проверки выпускает сертификат.

Для кого эта статья и почему она будет полезна

Статья рассчитана на разработчиков, DevOps-инженеров и системных администраторов, которые работают с HTTPS-инфраструктурой. Будет полезна тем, кто уже выпускал SSL-сертификаты, но хочет лучше понимать устройство CSR, нюансы SAN/wildcard-сертификатов и риски, связанные с генерацией приватных ключей.

SSL-сертификат воспринимается как что-то простое, но на практике проблемы нередко начинаются уже на этапе генерации CSR. Ошибки незаметны, пока инфраструктура мала. Они дают о себе знать в production, когда валидация сертификата падает и его приходится перевыпускать. Проблема обычно не в самом сертификате, а в том, как был создан CSR. Ручная сборка через OpenSSL превращается в источник мелких, но болезненных ошибок. Разберёмся, как устроен CSR, почему современные SSL-конфигурации стали сложнее и зачем команды всё чаще используют CSR-генераторы.

Как связаны SSL/TLS, ключевая пара и CSR

SSL/TLS — это протокол шифрования. CSR — это файл-заявка на выпуск SSL-сертификата. Чтобы получить SSL-сертификат для протокола TLS, вы создаёте CSR и отправляете его в удостоверяющий центр.

Важно: сам приватный ключ в CSR не передаётся. Он должен оставаться у владельца сертификата — на сервере, локальной машине, в защищённом хранилище или внутри инфраструктурного пайплайна. Если приватный ключ потерян или скомпрометирован, сертификат придётся перевыпускать.

Внутри CSR содержатся:

  • публичный ключ;

  • информация о домене;

  • данные об организации;

  • параметры запроса.

Сначала генерируется приватный ключ — большое случайное число. Публичный ключ выводится из него односторонней математической функцией (для RSA — на основе разложения произведения двух больших простых чисел; для ECC — на основе операций над точками эллиптической кривой). Восстановить приватный ключ из публичного невозможно за разумное время на современном оборудовании — на этом построена вся PKI.

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

Почему "сложные" SSL-сертификаты становятся источником ошибок

На простых конфигурациях OpenSSL обычно не вызывает проблем. Однако чем сложнее структура сертификата, тем выше вероятность ошибки.

С технической точки зрения любой SSL-сертификат — это набор полей, подписанных удостоверяющим центром (CA):

  • Subject (Common Name): содержит основной домен;

  • Subject Alternative Name (SAN): содержит список всех доменов и поддоменов, для которых работает сертификат;

  • Issuer: кто выпустил сертификат;

  • Validity: дата начала и окончания действия;

  • Public Key: публичный ключ, связанный с приватным.

Проблема не в том, что полей много. Проблема в том, что их нужно правильно заполнить на этапе создания CSR.

На практике сложность заполнения зависит от того, как и где сертификат используется. Чаще всего к сложным относят сертификаты, которые:

  • используются в распределенной инфраструктуре;

  • обслуживают большое количество доменов и поддоменов;

  • объединяют разные зоны ответственности (внутренние и внешние сервисы);

  • применяются в динамически изменяемых средах.

SAN сертификаты: человеческий фактор в списках доменов

Один сертификат может содержать сразу несколько доменов через механизм Subject Alternative Name (SAN):

На уровне CA это стандартный сценарий, но на уровне эксплуатации появляются ограничения:

  • легко ошибиться при добавлении доменов;

  • сложно поддерживать актуальность списка;

  • изменения требуют перевыпуска сертификата;

  • увеличивается риск человеческой ошибки в CSR.

Wildcard сертификаты: ограничения одного уровня вложенности

Wildcard сертификат покрывает все поддомены одного уровня:

ВАЖНО: по стандарту RFC 6125 wildcard НЕ покрывает корневой домен example.com. На практике все крупные публичные CA (Let's Encrypt, DigiCert, Sectigo, GoDaddy) при выпуске wildcard автоматически добавляют корневой домен в SAN — это сложившаяся индустриальная практика. Для частных и enterprise CA правило может не работать — всегда проверяйте Subject и SAN готового сертификата командой:

openssl x509 -in cert.crt -noout -text | grep -A1 "Subject Alternative"

Риски работы с wildcard особенно актуальны в инфраструктурах, где:

  • сервисы автоматически создают вложенные поддомены;

  • используется service discovery;

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

  • ingress собирается из нескольких namespace.

Типичный сценарий: команда выпускает *.example.com и считает, что покрыты все сервисы. Через месяц mobile-команда раскатывает api.v2.staging.example.com — клиенты получают NET::ERR_CERT_COMMON_NAME_INVALID. Wildcard покрывает только staging.example.com (один уровень), но не v2.staging.example.com (два уровня).

Решения: выпустить второй wildcard *.staging.example.com, или использовать SAN-сертификат с явным списком, или — если поддомены создаются динамически — переходить на ACME с DNS-01 challenge.

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

Наиболее сложный вариант — комбинация wildcard и SAN в одном сертификате:

Такие конфигурации часто появляются в реальных системах:

  • после роста проекта;

  • при объединении нескольких сервисов;

  • при миграции инфраструктуры;

  • в enterprise-окружениях с разными зонами ответственности.

Именно в таких случаях возрастает вероятность ошибок при формировании CSR:

  • пропущенные домены;

  • некорректный wildcard;

  • лишние или устаревшие записи;

  • несоответствие реальной инфраструктуре.

Почему OpenSSL не всегда удобен в 2026 году

OpenSSL остаётся стандартным инструментом и для большинства задач его достаточно. Один домен, разовый выпуск, разработчик знает CLI — openssl req делает своё дело за одну команду.

RSA — современная рекомендация (3072 бит):

openssl req -new -newkey rsa:3072 \
-keyout domain.key \
-out domain.csr

Альтернатива — ECC (быстрее, меньше):

openssl req -new -newkey ec \
-pkeyopt ec_paramgen_curve:prime256v1 \
-keyout domain.key \
-out domain.csr

Зачастую сложности появляются в трёх сценариях:

  • Для Multi-domain SAN сертификатов с десятками доменов и поддоменов. Конфиг разрастается, синхронизировать его между окружениями руками — путь к опечаткам.

  • Когда команда состоит из нескольких человек. Когда у каждого свой openssl.cnf, со временем рассыпаются стандарты — у кого-то RSA 2048, у кого-то 4096, у кого-то нет SHA-256.

  • Когда необходим регулярный перевыпуск. С учётом сокращения сроков действия сертификатов до 47 дней к 2029 году ручной CSR перестаёт быть жизнеспособной моделью для production.

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

В этих случаях команды переходят либо на ACME-автоматизацию (если CA поддерживает), либо на CSR-генераторы. Генератор не заменяет OpenSSL — он валидирует поля до выпуска: проверяет, что SAN корректен, что wildcard написан без опечаток, что CN указан, что длина ключа соответствует политике.

Критерий

OpenSSL CLI

Онлайн CSR-генератор

ACME-клиент (certbot и др.)

Сложность

❌ Высокая (CLI, конфиг-файлы)

✅ Низкая (форма в браузере)

Средняя (один раз настроить)

Безопасность ключа

✅ Полная (ключ локально)

Зависит от генератора

✅ Полная (ключ на сервере)

Поддержка SAN

✅ Да, через openssl.cnf

✅ Да, через UI

✅ Да, флагом -d

Wildcard

✅ Да

✅ Да

✅ Да (DNS-01 challenge)

Автоматизация

Скриптом — да, штатно — нет

❌ Нет (ручная процедура)

✅ Полная (renew по cron)

Выбор безопасного CSR-генератора

Существует множество бесплатных CSR-генераторов: DigiCert CSR Tool, CSR Generator HB.BY, SSLShopper CSR Generator, Namecheap CSR Decoder/Generator. У каждого свои нюансы интерфейса и набор поддерживаемых полей. Ориентируйтесь на универсальный чек-лист безопасности ниже.

Как проверить, что CSR-генератор безопасен:

  • HTTPS на странице генератора (без HTTPS — пройдите мимо).

  • Открыть DevTools → Network перед нажатием «Сгенерировать». После генерации не должно быть исходящих запросов с private key или CSR в payload.

  • В политике конфиденциальности нет упоминания о хранении или восстановлении приватных ключей.

  • Желательно — открытый исходный код или независимый аудит.

  • Сразу после генерации сохранить ключ локально, обновить страницу — ключ не должен восстанавливаться.

Если хотя бы один пункт не выполняется — генератор не подходит для production, и стоит вернуться к openssl на локальной машине.

Почему команды переходят на CSR-генераторы

В апреле 2025 года CA/B Forum (организация, объединяющая удостоверяющие центры и производителей браузеров) утвердил поэтапное сокращение максимального срока действия публичных SSL-сертификатов:

  • 200 дней — с 15 марта 2026

  • 100 дней — с 15 марта 2027

  • 47 дней — с 15 марта 2029

Что это значит на практике: ручной перевыпуск 7–8 раз в год становится невозможен. К 2029 году единственная жизнеспособная модель — автоматизация. Команды либо переходят на ACME-протокол (Let's Encrypt, ZeroSSL, Sectigo ACME), либо встраивают CSR-генерацию в инфраструктурный pipeline.

Для большинства публичных сертификатов под автоматизацию CSR создаёт сам ACME-клиент: certbot, acme.sh, traefik, cert-manager. Ручная генерация CSR актуальна для: коммерческих сертификатов с расширенной валидацией (OV/EV), сертификатов на внутренние CA, мульти-доменных конфигураций под одну заявку, ситуаций, когда CA не поддерживает ACME (например, GlobalSign для корпоративных PKI).

Те, кто планирует выпуск коммерческих сертификатов с OV/EV-валидацией и не может использовать ACME, всё больше полагаются на CSR-генераторы с шаблонами и валидацией SAN.

Безопасность при работе с CSR-генератором

Самый ценный и уязвимый элемент цепочки — private key. Именно он используется для подписи CSR и подтверждает владение сертификатом. Если приватный ключ скомпрометирован, сертификат необходимо перевыпускать.

Некоторые провайдеры предлагают выпустить сертификат, сгенерировав ключ и CSR на своей стороне — обычно это панель reseller-а или хостинг-провайдера. CSR при этом всё равно создаётся, но генерация ключа происходит не у вас. Это удобно для нетехнических пользователей, но имеет существенный минус: приватный ключ передаётся вам после выпуска и теоретически может быть сохранён в логах провайдера.

При использовании качественного генератора приватный ключ никогда не покидает вашу доверенную среду. CA получает только CSR (публичный ключ + домены). Всё остаётся под вашим контролем.

Если OpenSSL пугает консолью и параметрами, то CSR-генератор выглядит как обычная форма:

Большинство безопасных CSR-генераторов работают по одной схеме:

  1. Ввести домен (CN)

  2. Заполнить данные компании (если нужно)

  3. Добавить SAN-домены (если нужно)

  4. Выбрать размер ключа Нажать «Сгенерировать»

  5. Скопировать CSR и private key

  6. CSR отправить в CA, а ключ при использовании генератора остается только у вас

Полезные ресурсы

Частые вопросы

Вопрос

Ответ

Что такое CSR простыми словами?

CSR — это заявка на выпуск SSL-сертификата. Текстовый файл с публичным ключом и информацией о доменах, которую вы отправляете в удостоверяющий центр. CA подписывает её и выдаёт сертификат.

Чем отличается CSR от SSL-сертификата?

CSR — это запрос на сертификат, который создаёт владелец домена. SSL-сертификат — это уже подписанный CA документ, который ставится на сервер. CSR существует короткое время — от генерации до выпуска сертификата.

Можно ли использовать один CSR для нескольких сертификатов?

Технически — да, CSR можно отправить в несколько CA или использовать повторно при перевыпуске. Но при замене приватного ключа (key rollover) CSR должен быть создан заново — публичный ключ внутри CSR должен соответствовать новому приватному ключу.

В чём разница между SAN и wildcard?

SAN — это явный список доменов внутри сертификата (DNS.1 = a.com, DNS.2 = b.com). Wildcard — это маска *.example.com, покрывающая все поддомены одного уровня. Они комбинируются: один сертификат может иметь и SAN со списком доменов, и wildcard-записи в этом же SAN.

Что делать, если потерял приватный ключ?

Сертификат становится бесполезным — без приватного ключа сервер не сможет завершить TLS-handshake. Нужен полный перевыпуск: новый приватный ключ → новый CSR → отзыв старого сертификата → выпуск нового. Если ключ был скомпрометирован, отзыв обязателен.

Итог

Работа с SSL-сертификатами редко вызывает сложности на уровне базовой настройки. Основные проблемы появляются позже — когда инфраструктура растет, увеличивается количество доменов, окружений и сервисов.

В таких условиях ошибки чаще всего возникают не на уровне криптографии, а на этапе подготовки CSR: неверно указанные SAN, пропущенные домены или несогласованные конфигурации между системами.

Именно поэтому процесс генерации CSR постепенно перестаёт быть ручной операцией и становится частью инфраструктурного workflow.

Инструменты, которые помогают структурировать и валидировать CSR на этапе создания, позволяют снизить количество ошибок до момента выпуска сертификата — до того, как они попадают в production. В случае SSL ошибки дешевле предотвращать на этапе CSR, чем устранять их в production.