SSL сертификат ru: 5 критических нюансов выпуска и продления

Поддержка получает тикеты, девопс ищет причину в цепочке, а аккаунт с certificate verify failed. Вполне рабочий сайт внезапно становится недоступен для значительной части аудитории.

В 2026 году коммерческие публичные TLS-сертификаты GlobalSign, DigiCert и Sectigo живут 199–200 дней. Бесплатный сертификат НУЦ Минцифры выдаётся на 365 дней, но его корневой сертификат встроен в ограниченный набор отечественных браузеров. У Let's Encrypt срок стандартный — 90 дней, а правила работы с российскими организациями стали строже из-за санкционных ограничений.

Пять нюансов ниже ломают привычный сценарий «выпустили один раз, забыли на год».

1. Годовая подписка больше не означает сертификат на год

С марта 2026 года CA/Browser Forum ограничивает срок действия публичных коммерческих TLS-сертификатов 199–200 днями. Годовой контракт с коммерческим удостоверяющим центром теперь реализуется выпуском двух последовательных сертификатов. Каждый покрывает свой отрезок времени. Никакого единого файла на 365 дней не будет.

Это меняет процедуру продления.

Если раньше дата expirate была далеко и мониторинг молчал, то теперь сертификат проходит через полный цикл обновления дважды за год. В одном из этих циклов обязательно вылезет ошибка DNS, истечёт API-токен, изменится реквизит аккаунта или сработает неудачный nginx -t.

Годовая подписка на коммерческий SSL в 2026 году — это два последовательных сертификата, а не один сертификат на год.

Сравнение доступных маршрутов выглядит примерно так:

К 2029 году CA/Browser Forum планирует перейти к целевому сроку в 47 дней. Инфраструктура, которая годами работала с одной ручной заменой сертификата в год, к тому моменту превратится в полноценный конвейер.

Для прод-контура это означает несколько требований:

• Продление запускается автоматически, а не по памяти девопса.
• Сертификат попадает в runtime через secret или volume, а не запекается в образ контейнера.
• После выпуска выполняется проверка цепочки, — безопасный reload без прерывания соединений.
• Мониторинг смотрит не на месяц до expirate, а на конкретное число дней.
• У сертификата, ключа, полной цепочки и регламента переключения есть резервные копии.

Отдельно про тип сертификата. DV подтверждает контроль над доменом. OV добавляет проверку организации. Зона .ru сама по себе не превращает DV в OV и не меняет правила проверки конкретного УЦ. Если закупка требует организационную верификацию, этот разговор начинается до генерации CSR.

2. Сертификат НУЦ Минцифры требует organizational и криптографический контроль

Бесплатный сертификат НУЦ Минцифры выдаётся через портал «Госуслуги» на 365 дней с момента генерации. Для заявки нужна авторизация юридического лица или ИП и применение усиленной квалифицированной электронной подписи.

Это не кнопка «получить сертификат» без подтверждений. Один сотрудник с доступом к панели не сможет оформить документ от имени компании, если его полномочия не оформлены соответствующим образом. УКЭП подтверждает заявку; проверка домена и контроль над DNS при этом остаются отдельными задачами.

Ключевой момент — private key. Он должен создаваться и храниться в контуре владельца сайта. В CSR попадает только открытый ключ и заявка на выпуск. Передавать private key в портал, Telegram, репозиторий или менеджеру хостинга никогда не нужно.

Для RSA-совместимого сценария минимальный размер ключа — 2048 бит. Практический комплект можно подготовить так:

• openssl genrsa -out private.key 2048 — генерация приватного ключа;
• openssl req -new -key private.key -out request.csr -subj "/CN=example.ru" — формирование CSR;
• chmod 600 private.key — закрытие доступа к ключу;
• openssl pkey -in private.key -check — проверка целостности ключа.

Дальше CSR и открытый ключ передаются в выпускающий центр, а готовый сертификат устанавливается на сервер. Содержимое private.key в процессе не меняется. Для wildcard, дополнительных SAN-доменов и нескольких сервисов ключевой материал организуют отдельно: один сертификат на десяток несвязанных хостов — нормальная практика, один ключ на все staging- и production-контуры — уже архитектурная пометка.

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

3. Russian Trusted Root CA не встроен в глобальные браузеры

Корневые сертификаты НУЦ Минцифры по умолчанию присутствуют в «Яндекс Браузере» и «Атоме». Chrome, Safari, Firefox и большинство мобильных операционных систем к ним по умолчанию не доверяют. Пользователь должен самостоятельно установить российский корень в системное хранилище.

Именно здесь возникает ложное ощущение, что установка прошла успешно. В одном браузере сайт работает. В другом — нет. Техподдержка проверяет панель, DNS, пинги и сертификат у себя. На сервере всё зелёное. Клиенту отправляется инструкция из пяти ссылок, после чего он закрывает вкладку.

Здесь нужно разделить три слоя доверия:

1. Leaf-сертификат связывает конкретное доменное имя с публичным ключом.

2. Промежуточные сертификаты строят путь от leaf-сертификата до корня.

3. Корневой сертификат должен находиться в trust-store операционной системы или браузера.

Nginx отвечает за первые два слоя при настройке цепочки. Задачу доверия к корню он не решает. Передача российского root-сертификата вместе с цепочкой тоже не превращает его в глобально доверенный.

Ручная установка корня на каждом компьютере и телефоне — костыль. В небольшом пилотном проекте он ещё способен прожить несколько недель. В электронной коммерции, кабинете, API или сервисе с обязательной авторизацией превращается в поток недовольства и невозможность нормально открыть продукт на новом устройстве.

Корпоративный клиент может распространить корень через GPO или MDM. Это управляемый сценарий для закрытого парка устройств. Он не создаёт доверие со стороны обычного посетителя сайта.

Типичные симптомы выглядят так:

Проверка через openssl s_client показывает цепочку, которую реально отдал сервер. Проверка через curl использует CA bundle конкретной машины. Ни один из этих тестов не эмулирует весь парк клиентских устройств. Стейдж с тестовыми машинками на разных ОС по-прежнему нужен.

4. Nginx чаще всего виноват в цепочке, а не в сроке сертификата

Ошибка certificate verify failed выглядит как проблема безопасности. На практике сертификат может быть новым, срокным и выпущенным правильным CA. Проблема лежит в конфигурации Nginx.

Классический сценарий: в конфиге указан cert.pem, хотя серверу нужен fullchain.pem. В cert.pem находится только сертификат домена. Промежуточный Russian Trusted Sub CA сервер не отправляет. Часть браузеров способна закрыть цепочку через кеш или собственный механизм доверия. Остальные получают неполную цепочку и предупреждение.

В конфигурации Nginx должны стоять полный chain и соответствующий private key:

• ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem;
• ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;

Порядок сертификатов в fullchain.pem тоже имеет значение:

1. Сначала leaf-сертификат домена.

2. Затем intermediate-сертификат или их последовательность.

3. Root-сертификат обычно не включается: доверенный корень уже находится в клиентском хранилище.

Если файлы приходят по отдельности, цепочку собирают без редактирования PEM вручную:

• cat /path/to/leaf.pem /path/to/intermediate.pem > /path/to/fullchain.pem
• openssl x509 -in /path/to/fullchain.pem -noout -subject -issuer -dates
• openssl s_client -connect example.ru:443 -servername example.ru -showcerts

Последняя команда показывает сертификаты, которые отдал сервер. Ошибки unable to get local issuer certificate или certificate verify failed здесь полезнее девяти сообщений в чате поддержки.

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

• nginx -t
• systemctl reload nginx

В контейнерной среде аналогично:

• docker exec nginx nginx -t
• docker exec nginx nginx -s reload

docker restart здесь — тяжёлый костыль. Он рвёт соединения, маскирует ошибку конфигурации и превращает обновление сертификата в мини-инцидент.

Ещё одна частая ошибка — разные пути внутри контейнера и на хосте. Хост видит /etc/letsencrypt/live/example.ru/fullchain.pem, контейнер после монтирования видит /etc/nginx/certs/example.ru/fullchain.pem. В логах Nginx путь выглядит рабочим, потому что файл существует. Внутри контейнера остаётся старый сертификат.

Проверять нужно не только дату notAfter, но и фактический notAfter того сертификата, который обслуживает нужный server_name. Их может быть несколько.

5. Let's Encrypt ограничивает не домен .ru, а владельца сертификата

Редакция пользовательского соглашения Let's Encrypt v1.7, действующая с июня 2026 года, запрещает выпуск и автоматическое продление сертификатов для организаций и ведомств, находящихся под прямыми санкциями США и OFAC. Ограничение распространяется на владельца домена и связанные с ним адреса.

Ключевой нюанс: речь не идёт о blanket-запрете для всей зоны .ru или .рф. Частные лица и независимые коммерческие проекты в зоне .ru продолжают обслуживаться благодаря телекоммуникационным изъятиям. Нельзя рисовать картину, будто Lets Encrypt отключил российские домены целиком.

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

Автоматизация добавляет отдельную проблему. Certbot или другой ACME-клиент способен годами успешно продлевать сертификат, пока владелец не попал в санкционный список. Затем renewal начинает падать на стороне CA. Доступ к аккаунту у команды есть, срок сертификата известен, а следующий выпуск уже невозможен.

Рабочий процесс здесь такой:

1. У каждого домена зафиксированы юридический владелец и связанные организации.

2. Проверка санкционного статуса выполняется до покупки коммерческого сертификата.

3. Для ACME-маршрута настроен контроль результата renewal, а не только запуск таймера.

4. При отказе CA предусмотрен переход на другого коммерческого УЦ либо на сертификат НУЦ Минцифры.

5. Для государственных и корпоративных ресурсов отдельно проверяется возможность распространения российского корня.

Полный будущий запрет для всех резидентов РФ в имеющихся данных не установлен. На текущий момент ограничения касаются конкретных санкционных случаев. Строить инфраструктуру на прогнозах о полном закрытии .ru смысла нет. Нужно проверять владельца и готовить резервный маршрут.

Если сертификат Let's Encrypt больше нельзя продлить, его нельзя заменить сертификатом НУЦ Минцифры для любого международного проекта. Возвращаемся к проблеме trust-store. Организационные и технические решения лежат в разных плоскостях.

Рабочий контур без сюрпризов

В нормальном контуре мы разделяем четыре независимых механизма. Покупка сертификата. Выпуск ключа и CSR. Продление. Доставка полной цепочки и ключа на сервер. Смешивать их в один shell-скрипт с тридцатью флагами — рецепт для автора костылей.

Первый шаг — инвентаризация доменов и владельцев. Рядом с каждым .ru должен лежать реальный держатель, выбранный CA, способ проверки домена и дата следующего продления. Домены, оставшиеся от старых проектов, тоже учитываются: forgotten subdomain с wildcard-сертификатом иногда остаётся в DNS дольше самого сервиса.

Второй шаг — выбор маршрута по аудитории:

• Международные клиенты и мобильные посетители: коммерческий публичный CA с глобальным доверием либо Let's Encrypt для допустимого владельца.
• Государственный контур и аудитория с управляемыми устройствами: НУЦ Минцифры с проверкой доверия и распространения корня.
• Санкционный риск: отдельная проверка до issuance, а не после отказа продления.

Третий шаг — автоматизация. Сертификат обновляется заранее, публикуется в secret-хранилище или на volume, после чего новый chain проверяется и только затем становится активным. Нельзя продлевать сертификат и одновременно перезаписывать файл, который читает работающий Nginx. Сначала новая версия рядом. Затем валидация. Затем переключение.

Четвёртый шаг — контроль после выпуска. Скрипт проверяет:

• openssl s_client -connect example.ru:443 -servername example.ru -showcerts
• openssl x509 -in /path/to/cert.pem -noout -subject -issuer -dates -ext subjectAltName
• openssl verify -CAfile /path/to/root.pem -untrusted /path/to/intermediate.pem /path/to/cert.pem
• nginx -t
• systemctl reload nginx
• curl --resolve example.ru:443:127.0.0.1 -Iv https://example.ru

Для ACME-инфраструктуры добавляется тестовый прогон renewal. Для контейнеров — проверка файлов внутри контейнера, поскольку volume и image часто расходятся именно в момент переключения.

Пятый шаг — мониторинг. Он должен видеть три разных события: приближение notAfter, ошибку выпуска нового сертификата и ошибку доставки цепочки на сервер. Один алерт на hostname вроде ssl_expiry слишком грубый. Истечение сертификата и неудачное продление — разные отказы с разными владельцами.

Шестой шаг — восстановление. Резервная копия включает private key, сертификаты, цепочку, конфигурацию Nginx, ACME-credentials, DNS API-токены и параметры проверки домена. Хранилище копий проверяется отдельной процедурой. Файл в архиве без возможности расшифровать его и поднять тестовый сайт — не backup.

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