Как не потерять клиентов если ваш сайт на сертификате НУЦ Минцифры

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

Обычный сценарий: что-то падает, monitoring tool алертит, devops чинит, всё работает. Но в 2026 году появился новый сценарий: сайт работает отлично, но monitoring tool говорит что он DOWN.

Это происходит когда сайт использует сертификат НУЦ Минцифры. DigiCert массово отзывает сертификаты у российских компаний, и тысячи организаций перешли на национальный удостоверяющий центр. Но большинство зарубежных monitoring tools просто не видят такие сайты.

Мы в PingZen решили эту проблему. Мы поддерживаем сайты на сертификатах НУЦ Минцифры корректно - без false positives, без компромиссов безопасности, без сложной настройки. В этой статье расскажем как мы это сделали и почему это важно для вашего бизнеса.

Почему мониторинг вообще важен

Начистоту: мониторинг - это страховка вашего бизнеса. Если сайт падает в 3 ночи, вы хотите об этом узнать до того как начнут звонить клиенты. Если DNS пропадает, вы хотите знать это сразу. Если база данных перегружена, вы хотите увидеть это в графиках.

Мы считаем, что хорошая система мониторинга должна сообщать о проблемах до того как клиенты заметят, показывать точные метрики (latency, uptime, performance), помогать быстро найти причину (database? network? app?), интегрироваться с вашими алертами (Telegram, Slack, PagerDuty).

Плохая система мониторинга показывает false positives — вы устаёте от алертов и перестаете на них реагировать. Показывает false negatives - вы не знаете о реальных проблемах. Искажает метрики - вы принимаете решения на основе неверных данных. Требует постоянного ручного вмешательства.

В 2026 году появилась новая проблема: многие monitoring tools стали плохими для российских компаний, даже если раньше они были хорошими.

Что случилось в 2026 году

До 2022 года российские организации спокойно использовали международные удостоверяющие центры - DigiCert, Let's Encrypt, GlobalSign. Их корневые сертификаты включены во все библиотеки по умолчанию. Monitoring tools (Datadog, Zabbix, Uptime Kuma) использовали эти библиотеки и всё работало.

Но в 2022 году ситуация изменилась. DigiCert начал отзывать сертификаты у банков и госкорпораций, GlobalSign прекратил выдачу новым российским клиентам, Let's Encrypt перестал валидировать некоторые .ru домены. Организации потеряли возможность выпускать доверенные TLS-сертификаты через международные УЦ.

Минцифры создали в ответ Национальный Удостоверяющий Центр - Russian Trusted Root CA. Это отдельная цепочка доверия со своим корневым сертификатом. Технически это обычный RSA-4096 сертификат, валидный до 2032 года. Но есть проблема: он не включен ни в одно международное хранилище доверия.

Когда monitoring tool пытается подключиться к сайту на сертификате НУЦ, он получает сертификат, пытается построить путь к известному корню - и не может. Криптографически всё валидно, но библиотека не доверяет этому корню. Результат: мониторинг показывает DOWN, хотя сайт работает отлично.

Что это значит для вашего бизнеса

Если ваш сайт использует сертификат НУЦ Минцифры, а ваш monitoring tool не поддерживает его, у вас проблемы. Мониторинг показывает false positives - сайт работает, но вы видите DOWN. Вы тратите время на проверки - devops/engineering бегают проверять несуществующие проблемы. Могут пропустить реальные аварии - от усталости от false alerts перестают обращать внимание на алерты. SLA breaches - если вы полагаетесь на мониторинг для SLA, но он показывает неверные данные.

Клиенты всё равно могут пользоваться вашим сайтом, но вы не знаете что происходит. И если реальная авария случится - вы узнаёте слишком поздно.

Как зарубежные monitoring tools решают эту проблему

Короткий ответ: не решают.

Datadog, New Relic, Zabbix, Uptime Kuma - все используют стандартные библиотеки (certifi, системные CA bundles) которые не включают НУЦ Минцифры. Нет настройки "включить поддержку НУЦ" в интерфейсе.

Что администраторы делают взамен - добавляют сертификат НУЦ в системное хранилище доверия на каждом сервере. Но это опасно: теперь все TLS соединения на этом сервере доверяют НУЦ - OAuth клиенты, вебхуки, сторонние API. Если кто-то получит контроль над НУЦ, возможна MITM атака.

Или ставят прокси с КриптоПро CSP между monitoring и целевым сайтом. Но это дорого ($5K+ на год лицензии), искажает метрики latency, добавляет единую точку отказа.

Или просто игнорируют проблему - рискуют пропустить реальные аварии.

Как мы решили эту проблему в PingZen

Мы выбрали наилучший из возможных подход - расширение доверия на уровне приложения. На наш взгляд, это безопаснее и предсказуемее чем другие варианты. НУЦ используется строго для изолированных health-чекеров, вообще не затрагивая другие клиенты системы. Доверие изолировано, предсказуемо, контролируется версиями.

Мы реализовали двухпроходную проверку. Сначала пробуем проверить сайт с обычными публичными корнями. Если не вышло - пробуем с расширенным набором (обычные корни + НУЦ). Но с важным ограничением: только для российских доменов.

У НУЦ Минцифры нет встроенных ограничений по именам (Name Constraints), поэтому теоретически он может выдать сертификат на любой домен в мире. Мы ограничиваем фолбэк доменами .ru, .su, .рф и их аналогами в punycode. Это соответствует мировым практикам безопасности - например, Mozilla привязывает французский ANSSI строго к зоне .fr.

Вот как это выглядит в коде (адаптированный пример):

import ssl
import httpx
import certifi
import tempfile
import os
from pathlib import Path
from urllib.parse import urlparse

EXTRA_ANCHOR_TLDS = (".ru", ".su", ".рф", ".xn--p1ai")

def build_extended_bundle(extra_ca_path: str) -> str:
    """Генерирует временный файл с certifi + НУЦ."""
    fd, bundle_path = tempfile.mkstemp(prefix="extended-ca-", suffix=".pem")
    
    with os.fdopen(fd, "w") as out:
        # Сначала стандартный certifi
        out.write(Path(certifi.where()).read_text())
        # Затем добавляем НУЦ
        out.write(Path(extra_ca_path).read_text())
    
    return bundle_path

def is_russian_tld(url: str) -> bool:
    """Проверяет TLD gate для безопасности."""
    parsed = urlparse(url)
    hostname = parsed.hostname or ""
    hostname = hostname.strip().rstrip(".").lower()
    
    # Обработка IDN (internationalized domain names)
    try:
        ascii_host = hostname.encode("idna").decode("ascii")
    except (UnicodeError, ValueError):
        ascii_host = hostname
    
    candidates = {hostname, ascii_host}
    return any(h.endswith(tld) for h in candidates for tld in EXTRA_ANCHOR_TLDS)

async def check_with_two_pass_verification(url: str, nuc_path: str):
    """Двухпроходная проверка с фолбэком на НУЦ."""
    # Пасс 1: стандартные trust anchors
    try:
        async with httpx.AsyncClient(verify=certifi.where(), timeout=5.0) as client:
            response = await client.get(url)
            return response.status_code, "public_ca"
            
    except httpx.ConnectError as e:
        # Если упали не по ошибке валидации сертификата — пробрасываем дальше
        if not isinstance(e.__cause__, ssl.SSLCertVerificationError):
            raise
            
        # Пасс 2: активируем TLD Gate
        if not is_russian_tld(url):
            raise e  # Нероссийский домен — не доверяем НУЦ
        
        # Генерируем расширенный бандл и пробуем снова
        extended_bundle = build_extended_bundle(nuc_path)
        try:
            async with httpx.AsyncClient(verify=extended_bundle, timeout=5.0) as client:
                response = await client.get(url)
                return response.status_code, "russian_nuc"
        except httpx.ConnectError as fallback_err:
            raise fallback_err
        finally:
            # Удаляем временный файл
            os.unlink(extended_bundle)

Примечание: это пример реализации, адаптированный для статьи. В реальном проекте pingzen.dev логика интегрирована в http_checker.py и checker_utils.py с дополнительными оптимизациями и обработкой граничных случаев.

Критически важно: расширенный контекст используется только для health checks. OAuth клиенты, Telegram алерты, вебхуки продолжают использовать только публичные корни. Это изоляция доверия - критический элемент безопасности.

Внутри PingZen

Внутри нашей платформы эта логика распределена между двумя ключевыми компонентами.

Генератор расширенного контекста - функция в модуле checker_utils.py собирает динамический bundle из дефолтного пакета certifi и дополнительных доверенных сертификатов, хранящихся в изолированной директории /opt/pingzen/ca/. На его основе создается чистый ssl.SSLContext. Bundle кэшируется и пересобирается только при изменении сертификатов.

Retry-логика в HTTP-чекере - при перехвате исключения CERTIFICATE_VERIFY_FAILED асинхронный воркер моментально валидирует TLD хоста. Если домен прошел проверку безопасности, инициируется второй проход с подгрузкой расширенного контекста.

При этом сохраняется жесткая изоляция доверия: все наши внутренние OAuth-клиенты, коннекторы баз данных, отправка Telegram-алертов и исходящие вебхуки продолжают использовать исключительно доверенные международные корни. НУЦ Минцифры не имеет к ним доступа ни при каких обстоятельствах.

Безопасность

Мы очень серьёзно относимся к безопасности. TLD gate - это вопрос безопасности всей системы. Как подробно обсуждается в профильных публикациях по информационной безопасности, государственные корневые сертификаты без nameConstraints создают риск MITM атак. Russian Trusted Root CA технически способен подписать rogue-сертификат для любого мирового сервиса, без жесткого ограничения злоумышленник с доступом к НУЦ мог бы устроить MITM-атаку на нашу платформу (например, перехватив трафик до API Telegram). Ограничение зоны гарантирует, что этого не произойдет.

Для редких исключений (когда российская компания вынуждена использовать НУЦ-сертификат на домене .com), оператор может отключить gate вручную на уровне конкретного монитора, подписав явное согласие.

Ещё один важный момент - мы добавляем только Root сертификат, намеренно исключая Intermediate CA certificates. Большинство корректно настроенных серверов отправляют промежуточные сертификаты сами в процессе TLS Handshake. Те, кто этого не делают, совершают ошибку конфигурации веб-сервера. Если бы мы слепо добавили промежуточные сертификаты в свой бандл, наш чекер маскировал бы эту ошибку, отдавая статус OK там, где реальный пользователь получил бы ошибку цепочки в браузере. С подходом root-only мы подсвечиваем реальный статус инфраструктуры.

Эксперты по информационной безопасности предлагают использовать nameConstraints - механизм X.509 который позволяет ограничить действие сертификата конкретными доменами. Это встроенная функция стандарта которую мы реализуем де-факто через TLD gate на уровне приложения, что даёт нам больше гибкости и прозрачности чем модификация самого сертификата.

Архитектура PingZen

PingZen - это распределённая система мониторинга. CheckWorker процессы забирают задачи из Redis, выполняют health-checks и сохраняют результаты в PostgreSQL.

Мы выделили три критически важных компонента производительности в процессе эксплуатации:

Connection Pooling - пул соединений в httpx (до 200 одновременных коннектов и 50 keep-alive соединений с expiry в 60 секунд). Это позволяет переиспользовать TLS handshake между проверками одного хоста, минимизируя сетевой оверхед.

Multi-probe aggregation - проверки выполняются параллельно из разных географических локаций (US, EU, RU). Результаты агрегируются по правилам:

• ANY_FAILS - алерт если любой пров подтверждает N подряд failures

• MAJORITY_FAILS - алерт если большинство провов fail

• ALL_FAILS - алерт только если все провы fail

Это исключает ложные срабатывания из-за локальных сетевых лагов и позволяет настроить чувствительность мониторинга под конкретные требования.

Cert Chain Inspector - изолированный сервис диагностики. Он делает live TLS handshake, извлекает цепочку сертификатов и подсвечивает проблемы: missing intermediate, expired certificates, hostname mismatch. Если на сервере пропущена промежуточная цепочка, инспектор показывает точный URL откуда её скачать.

Docker и deployment

Мы используем многоступенчатый Docker build. На этапе сборки образов сертификат Russian Trusted Root CA копируется в /opt/pingzen/ca/, а в окружении выставляется переменная PINGZEN_EXTRA_CA_DIR.

# Фрагмент деплоя воркеров
FROM python:3.11-slim-bookworm
COPY --from=certs_builder /etc/ssl/certs/russian_trusted_root.pem /opt/pingzen/ca/
ENV PINGZEN_EXTRA_CA_DIR=/opt/pingzen/ca

Бэкенд и центральный сервер управления (MCP) имеют этот траст включенным по умолчанию, однако в образах публичных чекеров он выключен. Если сторонний оператор разворачивает нашу приватную ноду (private location), он должен явно передать переменную окружения для активации поддержки НУЦ. Ни один публичный инструмент мониторинга (будь то Datadog или Grafana Probes) не должен включать локальные государственные CA по умолчанию - это железное правило хорошего тона в ИТ-безопасности.

Накладные расходы

Двухпроходная верификация добавляет latency только когда первая проверка завершается неудачей.

Для обычных сайтов (публичный CA): overhead равен нулю, проверка завершается на первом пассе.

Для сайтов на НУЦ Минцифры: добавляется вторая попытка с расширенным контекстом, что суммарно даёт микроскопические +5–10ms к общему времени проверки.

Потребление памяти стабильно: бандл certifi весит около 280 КБ, корень НУЦ - всего 2 КБ. Контексты кэшируются в рантайме FastAPI-приложения, так что overhead per-request почти нулевой. Валидация занимает менее 1ms CPU, а строковые операции для TLD gate практически бесплатны.

Операционные аспекты

Корневой сертификат НУЦ Минцифры валиден до 2032 года, поэтому в ближайшие годы плановая ротация файлов конфигурации нам не грозит. Для защиты от случайной или несанкционированной подмены файла в CI/CD пайплайнах мы жестко пингуем SHA-256 отпечаток сертификата в юнит-тестах: при попытке подменить файл сборка моментально упадет.

Все случаи использования расширенного контекста прозрачно логируются. Траблшутинг инцидентов тривиален: при возникновении ошибок мы проверяем issuer в выводе OpenSSL, валидируем доменную зону через TLD gate и проверяем переменные окружения воркера.

ГОСТ TLS - другая задача

Важно понимать: поддержка НУЦ Минцифры - это НЕ ГОСТ TLS. Это разные проблемы.

Большинство российских сайтов на сертификатах НУЦ используют стандартные шифры RSA/AES. Проблема только в доверии к удостоверяющему центру.

ГОСТ TLS - это когда сервер требует российских шифронаборов (Kuznyechik, Magma, Стрибог) вместо AES/SHA. Такие серверы рвут рукопожатие ещё до обмена сертификатами. Для поддержки ГОСТ TLS нужен gost-engine для OpenSSL 3.x и низкоуровневая настройка. Это узкая ниша (госсектор), и мы вынесли эту задачу в отдельный тип проверок.

В отличие от конкурентов

Zabbix/Uptime Kuma: НУЦ не поддерживается - нужны manual fixes Datadog/New Relic: enterprise tier only, $1000+/месяц .
PingZen: включено по умолчанию для .ru доменов, zero configuration

Заключение

Интеграция Russian Trusted Root CA в нашу систему мониторинга стоила нам глубокого погружения в PKI архитектуру. Мы устали от этого debugging, но результат того стоил.

Что это даёт:

• Сайты на сертификатах НУЦ мониторятся корректно

• Безопасность остальных TLS соединений не страдает

• Эксплуатационные затраты минимальны

• Точные метрики задержки без искажений

Если ваш сайт использует сертификат НУЦ Минцифры - зарубежные monitoring tools могут его не видеть. Datadog, Zabbix, Uptime Kuma показывают false positives. Вы тратите время на проверки несуществующих проблем, пропускаете реальные аварии.

Сейчас же PingZen решает проблему - мы поддерживаем НУЦ из коробки для .ru доменов.

Так что ждем вас на pingzen.dev, добавляйте свой .ru сайт и спите спокойно.

Будем рады обсудить в комментариях: как вы решаете проблему мониторинга сайтов на сертификатах Минцифры?