Заблокировали сертификат? Выясняем, какие УЦ продолжают обслуживать доменную зону .ru

Сложности с TLS-сертификатом редко выглядят катастрофично изнутри. Ещё вчера ресурс работал, а сегодня браузер выдаёт ошибку, системы мониторинга сигнализируют, а пользователи жалуются в службу поддержки. В этот момент администратор неожиданно осознаёт, что домен, юридическое лицо, страна регистрации, способ оплаты и корневой центр связаны гораздо теснее, чем предполагалось. Люди, как всегда, взяли простой технический инструмент и дополнили его санкционными ограничениями, экспортным контролем, хранилищами корневых сертификатов браузеров и договорами с мелким шрифтом на английском.

Если Let’s Encrypt, DigiCert или другой удостоверяющий центр отказывает в выдаче, обновлении или продлении, проблема не всегда кроется в серверных настройках. Существует два типа отказов. Технический: ошибка проверки домена, некорректная CAA-запись, неверные настройки DNS. Юридический: санкции, особенности доменной зоны, адрес компании, совпадение с запрещённой организацией. Для обычного пользователя всё выглядит одинаково — HTTPS перестаёт работать. Однако для бизнеса разница колоссальна: техническую неполадку можно устранить за час, а санкционный отказ иногда невозможно обойти законным способом.

Причины блокировки или отказа в продлении сертификата

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

Технический отказ чаще связан с проверкой прав на домен: отсутствие DNS-записи, некорректная отдача проверочного файла веб-сервером, перенаправление IPv6 на другой узел, маскировка ответа CDN или наличие CAA-записи, разрешающей только один центр. Подобные проблемы решаются быстро. Юридический отказ означает нежелание или невозможность центра обслуживать конкретное юридическое лицо, доменную зону, страну, государственную структуру или связанную организацию. Исправление TXT-записями в этом случае бесполезно.

Эпоха «установил и забыл» подходит к концу из-за решений CA/Browser Forum

Многие годами обновляли сертификат раз в год и вспоминали о нём только после уведомления от системы мониторинга. Такой подход уходит в прошлое. CA/Browser Forum утвердил бюллетень SC-081v3, сокращающий максимальный срок действия публичных TLS-сертификатов поэтапно: 200 дней с 15 марта 2026 года, 100 дней с 15 марта 2027 года и 47 дней с 15 марта 2029 года. Одновременно сокращаются сроки повторного использования данных проверки: для информации о субъекте (данные организации в OV/EV-сертификатах) — до 398 дней с марта 2026 года, для проверки домена и IP-адреса — сроки ещё короче, с дальнейшим уменьшением. Это особенно болезненно для крупных компаний, приобретающих «солидные» сертификаты с проверкой организации.

Вывод очевиден: ручное продление превращается из рутинной задачи в производственный риск. При 47-дневном сроке замену придётся проводить каждые шесть-семь недель, около восьми раз в год для каждого сертификата. Без автоматизации это гарантированный источник сбоев.

Реальные изменения в Let’s Encrypt в 2026 году

Let’s Encrypt остаётся наиболее удобным решением для большинства обычных сайтов: бесплатно, автоматически через ACME, без переписки с менеджерами. В 2026 году вокруг сервиса стало больше шума, и важно не поддаваться панике под влиянием некорректных заголовков вроде «Let’s Encrypt заблокировал Россию».

Что произошло на самом деле: 4 июня 2026 года вышла версия 1.7 пользовательского соглашения. В раздел 3.1 добавили санкционное положение: подписчик подтверждает, что не находится, не зарегистрирован и не проживает на территориях, подпадающих под всеобъемлющие санкции США, не является запрещённой или ограниченной стороной и не действует от её имени. Здесь же ISRG оставляет за собой право отказать по любой законной причине. Это подтверждается независимыми анализами соглашения.

Отдельно о санкциях, поскольку здесь легко переборщить. США делят ограничения на всеобъемлющие (как для Кубы, Ирана, КНДР и отдельных регионов Украины) и адресные либо секторальные. Россия находится под режимом значительных, секторальных и точечных мер, а не под полным эмбарго, как Куба или КНДР. Поэтому для российского сайта риск отказа зависит не от зоны .ru, а от владельца, юридического лица, контролирующих лиц, государственного участия, банков и связей со санкционными списками. Для частного проекта или обычной компании, не включённой в списки, Let’s Encrypt чаще всего работает даже с доменом .ru. Для госструктур, банков и организаций из санкционных списков риск значительно выше, и успешный выпуск вчера не гарантирует продление завтра.

GlobalSign, DigiCert и Sectigo: кто действительно ограничивает доменные зоны

Здесь важно избегать обобщений. GlobalSign — это центр с санкционным контролем, а не «блокиратор зоны .ru». Корпоративно это японская GMO GlobalSign K.K., а связанные площадки по сертификату ISO расположены в Великобритании, Бельгии, США, Индии, Сингапуре и других странах. Компания заявляет о соблюдении применимых санкционных правил и проверке подозрительных признаков, но публичного запрета именно на зону .ru, как у американских центров, не вводила. На практике российское юридическое лицо или организация под санкциями могут не пройти проверку, но механика здесь основана на отсеивании подозрительных клиентов, а не на массовой блокировке зоны.

DigiCert формулирует ограничения прямо. В справке по странам и регионах компания приостанавливает выпуск и обновление всех типов сертификатов для России и Беларуси. В список ограниченных зон входят .ru, .рф, .su, .ru.com, .ru.net, .moscow, .москва, .рус, .tatar, .by, .бел и связанные домены, а также организации с адресом в РФ или РБ.

Sectigo прямо указывает Россию в списке стран, для лиц и организаций которых сертификаты не выпускаются из-за экспортных ограничений США. Детализацию по конкретным зонам .ru, .su, .рф, .by удобнее смотреть в сводных списках и у партнёров: официальная страница перечисляет страну, но не описывает все доменные зоны столь подробно. Через посредников результат тот же — корень всё равно проверит выпуск.

Можно ли просто выбрать другой доверенный УЦ?

Самый частый вопрос, скрывающий основное заблуждение. Доверенных центров не семь, а десятки. В корневых программах Mozilla, Microsoft, Apple и Chrome зарегистрированы десятки организаций. По одному только составу участников CA/Browser Forum виден масштаб: Actalis, Buypass, Certum, D-Trust, DigiCert, Disig, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, iTrusChina, Izenpe, JPRS, Kamu SM, Let’s Encrypt, SECOM, Sectigo, SSL.com, SwissSign, Telia и другие — и это лишь голосующие участники, а не полный перечень корней.

Ограничитель — не количество центров, а юрисдикция. Признание корня браузером и готовность центра выдать сертификат — две независимые вещи. Большинство публично доверенных центров зарегистрированы в США, ЕС, Великобритании, Канаде, Норвегии, Швейцарии и Японии — то есть там, где действуют санкции США и ЕС. Далее идёт нюанс, который часто игнорируют: санкционный режим ЕС не означает автоматического запрета на выпуск TLS для любого .ru или российского юрлица. Греция — член ЕС, Норвегия — нет, хотя и внедряет санкции ЕС через свои механизмы. На практике европейские центры работают в санкционной среде, поэтому возможны отказы после проверки клиента (KYC), ограничения по платежам и связанным лицам. Прямой запрет именно по зоне .ru нужно проверять у каждого центра, а не считать его общим правилом.

Формальные лазейки остаются у неевропейских и неамериканских центров — китайских, индийских, турецких. Под западные санкции они не подпадают напрямую. Но это не выход, а замена одного риска на другой. Во-первых, признание таких корней зависит от конкретного корня, цепочки, продукта и версии платформы, и его нужно проверять в Chrome Root Store и Mozilla CCADB перед использованием. Во-вторых, у некоторых китайских центров есть подтверждённые случаи потери доверия из-за нарушений: CNNIC лишили доверия в 2015 году после выдачи промежуточного сертификата, использованного для атаки MITM, а WoSign и StartCom потеряли доверие в 2016–2017 за бэкдейтинг сертификатов и сокрытие сделки. Браузеры регулярно отзывают доверие у центров за нарушения — Symantec в 2018 году, Entrust в 2024 году. В-третьих, перевод корпоративной инфраструктуры на такой центр фактически передаёт контроль над цепочкой доверия структуре в другой юрисдикции с собственными интересами. «Технически возможно» и «разумно внедрять» — разные вещи.

Российские сертификаты Минцифры и частная PKI

Для организаций в России основной локальный вариант — TLS-сертификаты Национального удостоверяющего центра Минцифры, выдаваемые юридическим лицам бесплатно через Госуслуги. Здесь скрыт важный нюанс, который стоит уточнить: факт выпуска сертификата и его признание интернетом — это две разные ситуации, а не синонимы.

Признание внутри страны означает, что сертификат работает там, где корень НУЦ уже установлен и принят: в российских браузерах с предустановленным корнем (Яндекс.Браузер), в корпоративных сетях с заранее разданными корнями, на устройствах с ручным добавлением доверия. Признание основными браузерами и ОС по умолчанию — совершенно другая история. Корень НУЦ Минцифры не входит ни в одну крупную корневую программу. Россия предпринимала попытки, но крупные браузеры не приняли её центр из-за требований к аудиту, прозрачности, журналам Certificate Transparency и управлению доверием.

Поэтому для банков, госуслуг или внутренних порталов с российской аудиторией такой сертификат может быть рабочим. Для сервисов с клиентами из Европы, Азии и США, мобильных приложений и устройств без предустановленного корня — зарубежные Chrome, Safari, Firefox, Android или iOS покажут предупреждение о недоверенной цепочке.

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

Сводная таблица: какие центры могут выпустить сертификат для .ru

Практическое сравнение рынка, разбитое на четыре группы. Зону .ru и российское юридическое лицо мы разделили на две колонки, поскольку это разные причины отказа: DigiCert, например, блокирует и по доменной зоне, и по адресу организации, а Let’s Encrypt заботит не зона, а санкционный статус владельца. Для каждого центра указан источник информации.

По центрам Группы 1 и российскому контуру статус подтверждён по публичным источникам. По Группам 2 и 3 публичного запрета зоны .ru, как правило, нет, поэтому стоит пометка «проверять» с основанием: «нет публичной политики», «через платформу», «нет розницы для .ru», «зависит от корня», «проверка клиента ЕС». Санкционные политики правятся, поэтому перед боевым внедрением статус нужно сверять на странице ограничений конкретного центра.

Быстрая проверка домена за 15 минут

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

1. Проверьте эмитента текущего сертификата (issuer) — кто его выпустил и до какой даты он действителен.
2. Изучите CAA-записи домена: разрешён ли там нужный центр или указан только старый.
3. Проверьте журналы Certificate Transparency для вашего домена — какие сертификаты и кем выпускались.
4. Попробуйте тестовый выпуск (test issuance) в альтернативном центре, не блокирующем вашу зону.
5. Проверьте санкционный статус юрлица, владельцев и способа оплаты — это не задача DevOps, но без неё дальнейшие действия будут гаданием.
6. Откройте сайт в разных браузерах и из разных регионов: цепочка, которая работает у вас, может быть недействительной для клиента.

Варианты выбора: кратко по сценариям

Обычная компания без санкционных рисков

Вариантов множество. Для стандартного сайта первый выбор — Let’s Encrypt: бесплатно, ACME, совместим с Nginx, Apache, Kubernetes и панелями хостинга. Если сайт за Cloudflare — используйте управляемые сертификаты Cloudflare, которые автоматически выпускаются и продлеваются через партнёрские центры (Let’s Encrypt, Google Trust Services, SSL.com, Sectigo; состав зависит от продукта и настроек). Для облачных решений — встроенные менеджеры: AWS Certificate Manager (с июня 2025 поддерживает экспортируемые сертификаты для ресурсов вне AWS), Google Cloud Certificate Manager. Не стоит переносить закрытые ключи по серверам вручную, словно время остановилось в 2007 году.

Российская компания без прямых санкций

Сначала разделите домен и юридическое лицо, а также аудиторию и инфраструктуру. Домен в нейтральной зоне (.com) плюс зарубежное юрлицо без санкционных признаков — повышает шансы на выпуск. Домен .ru/.рф плюс российская регистрация — сразу исключает DigiCert и Sectigo по зоне. Рекомендуется иметь два сценария: основной признанный сертификат и резервный сертификат Минцифры на случай отказа в продлении. Резерв не заменит признание браузерами, но сохранит доступность для части пользователей внутри страны. Обходные пути через подставные компании и номинальных владельцев обычно создают больше проблем, чем решают: центры выявляют shell-компании, подозрительные платежи, несоответствие IP заявленному местоположению и личные почты вместо корпоративных.

Организация под санкциями

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

Как минимизировать риск отказа и простоя

Инвентаризация. Найдите все публичные сертификаты, включая забытые административные интерфейсы, старые поддомены, API, почтовые шлюзы, VPN-порталы, балансировщики, входы Kubernetes и тестовые стенды. В компаниях часто падает не основной сайт, а «небольшой сервис для партнёров», через который проходит значительная часть денежных потоков. Забытая система мстит тише, но болезненнее.

Автоматизация. Используйте ACME везде, где возможно: Certbot или acme.sh для серверов, cert-manager для Kubernetes, менеджеры жизненного цикла для корпоративной среды. Автоматизация должна не только получать сертификат, но и устанавливать его, перезагружать службы, проверять цепочку и уведомлять команду в случае ошибок.

Резервный центр. Для важных доменов нельзя полагаться на единственный путь выпуска. Убедитесь, что альтернативный центр выдаст сертификат для того же домена, нет ли проблем с CAA, проходит ли проверка через DNS-01, доступны ли DNS для оперативного управления. Для России отдельно протестируйте сценарий с сертификатом Минцифры и реалистично оцените долю аудитории, которая откроет сайт без ручной установки корня.

Ошибки, нарушающие HTTPS даже без санкций

CAA с ограничением на один центр. Запись ограничивает список центров, которым разрешён выпуск для домена. Полезная мера, но если указан только прежний поставщик, новый получит отказ. При аварийной миграции поиск причины может занять часы, хотя проблема в одной строке DNS.

Ручные Wildcard без доступа к DNS. Wildcard почти всегда требует проверку DNS-01, то есть команда должна уметь оперативно добавлять TXT-записи. Если DNS управляется подрядчиком, владелец домена в отпуске, а доступы хранятся в личной почте уволившегося сотрудника — продление сертификата станет невозможным. Технологии XXI века снова проигрывают табличке с паролями у человека, который давно покинул компанию.

Путаница между CDN и origin. Пользователь видит сертификат Cloudflare, но Cloudflare соединяется с вашим сервером по другому сертификату. Если на бэкенде просроченный, самоподписанный или ненадёжный сертификат, в строгом режиме соединение прервётся. Проверяйте всю цепочку: браузер — CDN — балансировщик — приложение.

Практический план действий при блокировке

Если сертификат уже не выпускается, не меняйте всё подряд. Сначала изучите точное сообщение об ошибке в ACME-клиенте или кабинете. Ошибка проверки домена, ошибка CAA, запрет политики и санкционный отказ требуют разных решений. Лечить санкционный отказ добавлением TXT-записи бессмысленно — примерно как спорить с банкоматом о международном праве.

1. Проверьте срок действия текущего сертификата, цепочку, OCSP/CRL и предупреждения браузеров через SSL Labs или аналог.
2. Изучите CAA-записи и добавьте разрешение для нового центра, если меняете поставщика.
3. Попробуйте другой публично доверенный центр, не блокирующий вашу зону и юрлицо.