Мониторинг сайтов на сертификатах НУЦ Минцифры

Иностранные удостоверяющие центры весь 2026 год отзывают сертификаты у российских компаний, и многие сайты перешли на корень Минцифры — Russian Trusted Root CA (НУЦ). Этого корня нет ни в одном из основных хранилищ доверия — Mozilla, Microsoft, Apple, Google; предустановлен он только в Яндекс.Браузере и Atom. Поэтому монитор на таком хосте раньше падал на проверке: HTTPS уходил в жёсткий DOWN, SSL — в DEGRADED, а продукт ещё и советовал отключить проверку сертификата.

Теперь PingZen распознаёт этот корень в своих проверках. Если ваш .ru-сайт отдаёт сертификат Минцифры, его монитор снова зелёный — без единой настройки.

Как вообще работает доверие к сертификату

Вся история ниже держится на одной мысли: сертификат сам по себе не доказывает ничего. Доказывает список корней, который лежит у клиента. Ниже — шесть шагов этой механики; если она знакома, переходите сразу к тому, что изменилось.

Сертификат — это утверждение, заверенное подписью

Сертификат сервера говорит одну вещь: «вот этот открытый ключ принадлежит example.ru». Выписать такую бумагу может кто угодно на своём ноутбуке за секунду — это и есть самоподписанный сертификат. Вес ей даёт только подпись удостоверяющего центра: УЦ подписывает содержимое своим закрытым ключом, а клиент проверяет подпись открытым ключом этого же УЦ.

Цепочка: лист, промежуточный, корень

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

Хранилище доверия — это просто список

Корень подписан сам собой, поэтому его подпись ничего не говорит о том, можно ли ему верить. Весь его вес — в том, что он лежит в хранилище доверия клиента: списке корней, который приезжает с операционной системой или браузером. Проверка сводится к вопросу «достраивается ли цепочка до корня из моего списка». Нет корня в списке — нет доверия, каким бы корректным ни был сертификат и как бы ни сходились подписи.

Подпись — не единственная проверка

Даже когда цепочка собралась, клиент сверяет ещё несколько вещей: имя хоста должно быть в списке SAN, сегодняшняя дата — между notBefore и notAfter, промежуточному должно быть разрешено подписывать (basicConstraints), сертификат не должен быть отозван (CRL или OCSP). Chrome, Safari и Firefox вдобавок требуют, чтобы сертификат был опубликован в журналах Certificate Transparency. Любой из этих пунктов может не сойтись при идеально валидной цепочке — и наоборот.

Как корень попадает в этот список

Не «договориться с браузером». УЦ выполняет Baseline Requirements CA/Browser Forum, проходит независимый аудит (WebTrust или ETSI) и подаётся в корневые программы. Программ несколько — Mozilla, Microsoft, Apple, Google, — каждая ведёт свой список и решает сама, а дальше новый корень едет к пользователю обычным обновлением системы или браузера. Путь занимает годы. Обратная дорога короче: у DigiNotar в 2011 году угнали инфраструктуру и выписали поддельный сертификат на google.com — центр вылетел из всех хранилищ и закрылся.

Корень может быть ограничен по именам

В корень можно зашить ограничение (nameConstraints): подписывать только перечисленные домены. Такой корень, даже попав в хранилище, бесполезен для чужого имени: сертификат за пределами разрешённого списка клиент отвергнет, даже если УЦ его подписал. У корней общего назначения этого ограничения нет, поэтому любой публичный УЦ технически способен выписать сертификат на любой домен мира. Именно из-за этой дыры появились CAA-записи (владелец домена указывает, какому УЦ можно) и Certificate Transparency — публичный журнал всего выписанного.

Отсюда и вся история дальше. Сертификат НУЦ Минцифры криптографически ничем не хуже любого другого: цепочка собрана правильно, подписи сходятся, имя хоста на месте. Не сходится ровно один пункт — его корня нет ни в одном из основных списков. И ограничений по именам у этого корня тоже нет: первое ломает проверку на полностью рабочем сайте, второе объясняет, почему доверие к нему пришлось ограничивать руками.

Что именно изменилось

Проверка идёт в два прохода. Сначала — против обычного публичного хранилища доверия, ровно как раньше. И только если он не прошёл, идёт повтор против корня Минцифры. Монитор, который проходил раньше, проходит так же; в проверке по публичным УЦ ничего не поменялось.

Восстановленные мониторы логируются как проверенные через добавленный якорь — видно, какая проверка доверилась непубличному корню, а не публичному УЦ.

Ограничено намеренно

Доверять госкорню везде — это слишком, поэтому он загнан в рамки:

Использует его только сама проверка. Всё остальное — вход в аккаунт, доставка алертов, вебхуки — по-прежнему проверяется только по публичным корням. Сертификат Минцифры, выписанный, скажем, на эндпоинт Google или Telegram, по-прежнему отвергается.
Российские домены по умолчанию. У корня нет ограничений по именам, поэтому фолбэк работает только для хостов .ru, .su и .рф. Сертификат Минцифры на домене .com не позеленит монитор молча.

Когда хост российский, а домен — нет

Некоторые российские компании отдают сертификат Минцифры на нероссийском домене. Для такого хоста гейт можно снять на уровне одного монитора — по умолчанию выключено и настраивается по каждой цели, так что вы ослабляете доверие для одного выбранного хоста, а не везде. Если у вас такой хост и его монитор остаётся красным — напишите нам, включим для этого монитора.

Чего это не делает

Это не ГОСТ TLS. Серверы на ГОСТ-шифронаборах рвут рукопожатие ещё до обмена сертификатом, и там никакой корень не помогает — это отдельная задача. И хост, который отдаёт сертификат вообще без цепочки, остаётся DEGRADED: чинится это на стороне сервера (отдавать полную цепочку), а не в хранилище доверия.