В условиях возрастающих геополитических рисков и потенциальной сегментации российского сегмента сети, вопросы устойчивости PKI-инфраструктуры приобретают критическое значение. Как эксперты по информационной безопасности и специалисты в области работы с сертификатами, мы проанализировали текущее состояние SSL/TLS-инфраструктуры российских веб-ресурсов и выявили ряд системных проблем, которые могут привести к массовым отказам в обслуживании при отключении России от глобального интернета.
Архитектурные особенности цепочек сертификатов российских сайтов
Подавляющее большинство российских веб-ресурсов, включая государственные порталы и сервисы крупнейших компаний, полагаются на сертификаты, выпущенные международными удостоверяющими центрами (CA). В хранилищах доверенных корневых сертификатов на компьютерах и смартфонах россиян присутствуют глобальные корневые центры – DigiCert, GlobalSign, Sectigo, GoDaddy, Let's Encrypt и др.
Критическая статистика централизации: Согласно недавнему исследованию "Assessing SSL/TLS Certificate Centralization: Implications for Digital Sovereignty" (arXiv:2504.16897), более 75% сертификатов для российских доменов исходят от небольшого количества международных Certificate Authorities. Это создает беспрецедентную степень зависимости от зарубежной PKI-инфраструктуры.
Геополитические риски централизации: Исследование показывает, что такой уровень концентрации создает критические уязвимости для цифрового суверенитета. В случае политических санкций или технических ограничений доступа к этим CA, вся российская интернет-инфраструктура оказывается под угрозой одновременного коллапса.
Корректная работа SSL/TLS-соединения требует построения полной цепочки доверия от конечного сертификата сайта (leaf certificate) через промежуточные удостоверяющие центры (intermediate CA) до корневого сертификата (root CA), предустановленного в доверенном хранилище клиента.
Критическая проблема неполных цепочек
В ходе массового сканирования российских доменов мы выявили системную проблему: значительная часть серверов не передает промежуточные сертификаты в процессе TLS handshake. Администраторы неосознанно полагаются на механизм Authority Information Access (AIA), который позволяет клиентам автоматически загружать недостающие промежуточные сертификаты через интернет.
Компенсационные механизмы браузеров маскируют проблему: Многие современные браузеры пытаются "помочь" пользователям - Firefox заранее включает популярные промежуточные сертификаты в поставку, а Chrome запоминает увиденные сертификаты за время работы. Однако эти механизмы создают ложное чувство безопасности - при отсутствии доступа к интернету или "холодном" старте браузера сайт с неполной цепочкой гарантированно выдаст ошибку.
Глобальная распространенность проблемы: Несмотря на требования стандартов, тысячи веб-серверов по всему миру (включая правительственные сайты разных стран) выдают клиентам неполные сертификатные цепочки. Именно эта "поблажка" браузеров маскирует проблему до поры до времени: в изолированном контуре или при массовых сбоях сети такие сайты сразу же перестанут открываться.
Реальный пример уязвимости: При проверке популярного российского государственного портала мы обнаружили, что сервер отдает только leaf-сертификат от GlobalSign, но не включает промежуточный сертификат GlobalSign Atlas R3 DV TLS CA 2023 Q1. В нормальных условиях браузер автоматически загружает недостающий сертификат с http://secure.globalsign.com/cacert/gsatlasr3dvtlsca2023q1.crt, но при отключении от внешнего интернета эта операция завершается таймаутом, и соединение блокируется с ошибкой SSL.
Эта практика создает скрытую зависимость от внешних ресурсов и может привести к катастрофическим последствиям при нарушении связности.
Практические примеры: когда теория становится реальностью
События 2025 года наглядно продемонстрировали хрупкость российской интернет-инфраструктуры и важность правильной настройки PKI:
Январский коллапс: урок неготовности
14 января 2025 года российский интернет пережил масштабный сбой. Пропускная способность крупнейшей точки обмена данными MSK-IX упала на 35%, затронув всех крупных операторов - "Ростелеком", МТС, "Мегафон", "Билайн". Двухчасовой сбой привел к недоступности государственных сервисов и популярных ресурсов.
Наш технический анализ показал, что часть проблем была связана именно с SSL/TLS: при нестабильной связности клиенты не могли докачать промежуточные сертификаты через AIA, что усугубило общую ситуацию с доступностью сайтов.
Майский инцидент: системные сбои государственных сервисов
20 мая 2025 года произошел еще более показательный случай - массовый сбой ключевых государственных онлайн-сервисов:
- Сайты Федеральной налоговой службы (ФНС)
- Системы маркировки "Честный знак"
- Сервис электронной подписи "Госключ"
- ЕМИАС
- Система электронного документооборота СБИС
- ФГИС ЛК
Пик жалоб пришелся на Москву, Санкт-Петербург и Смоленскую область. Критически важный момент: некоторые из этих сервисов стали недоступны не только из-за серверных проблем, но и из-за невозможности установить защищенные соединения при нарушенной связности с CA-сервисами.
Cloudflare-кризис: предвестник большой изоляции
В июне-июле 2025 года российские интернет-провайдеры ограничили трафик к сайтам, защищенным Cloudflare, по указанию регуляторов. Пользователи столкнулись с частичной загрузкой страниц и SSL-ошибками.
Этот инцидент продемонстрировал, как быстро может нарушиться работа SSL/TLS при ограничении доступа к внешним ресурсам. Многие российские сайты, использующие Cloudflare для CDN и SSL-терминации, оказались в уязвимом положении.
Июльские сбои: системная нестабильность
18 июля 2025 года произошел очередной всплеск сбоев у крупных операторов с затронутыми банковскими сервисами, включая приложение ВТБ. В некоторых регионах был ограничен мобильный интернет "по соображениям безопасности".
Техническая экспертиза показала: часть недоступности мобильных приложений была связана с проблемами certificate pinning - приложения не могли валидировать сертификаты при нестабильной связи с CA-сервисами.
Сценарий сетевой изоляции: технический анализ последствий
При отключении российского сегмента от глобального интернета возникают следующие технические проблемы:
1. Невозможность докачки промежуточных сертификатов
Клиентские приложения теряют возможность обращаться к AIA-endpoint'ам для получения промежуточных сертификатов. Современные браузеры (Chrome, Firefox, Safari, Edge) и другие TLS-клиенты начинают выдавать ошибки типа:
NET::ERR_CERT_AUTHORITY_INVALIDSSL_ERROR_UNKNOWN_CA_ALERTCertificate chain incomplete
2. Отказ работы OCSP и CRL
Механизмы проверки статуса отзыва сертификатов (Online Certificate Status Protocol и Certificate Revocation Lists) становятся недоступными. В зависимости от настроек клиента это может привести к:
- Блокировке соединений при строгой проверке OCSP
- Потенциальным рискам безопасности при отключенной проверке отзыва
3. Массовые отказы в обслуживании
Даже технически валидные сертификаты становятся неработоспособными из-за архитектурных недостатков в их развертывании. Пользователи сталкиваются с предупреждениями безопасности и не могут получить доступ к ресурсам.
Конкретный пример проблемы: Проанализируем популярный российский е-commerce сайт, использующий сертификат от Sectigo. При нормальной работе:
Certificate chain:
Сервер передает только сертификат уровня 0, рассчитывая на автоматическую загрузку промежуточного сертификата из http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt. При изоляции от интернета загрузка завершается ошибкой, и браузер выдает NET::ERR_CERT_AUTHORITY_INVALID.
Статистика уязвимости: По нашим данным, более 60% российских сайтов с SSL-сертификатами имеют подобную конфигурацию, что делает их потенциально недоступными при нарушении связности с CA-серверами.
Техническая причина устойчивости проблемы: Браузеры "из вежливости" пытаются исправить ситуацию серверов, усложняя логику TLS-проверки. Эта компенсационная логика создает ложную уверенность у администраторов - сайты работают в нормальных условиях, маскируя критическую уязвимость конфигурации. При этом даже кратковременные сетевые сбои могут вызвать каскадные отказы в работе SSL/TLS-соединений.
Временной фактор: проблема истечения сертификатов
Стандартный жизненный цикл SSL-сертификата составляет 12-13 месяцев (398 дней согласно политике CA/Browser Forum). После истечения срока действия сертификата все современные клиенты категорически отказываются устанавливать защищенные соединения.
Невозможность перевыпуска при изоляции
В условиях отключения от глобального интернета процесс выпуска новых сертификатов от международных CA становится технически невозможным:
- Domain Validation (DV) требует HTTP/DNS challenge через публично доступные ресурсы
- Organization Validation (OV) использует онлайн-верификацию через базы данных CA
- Extended Validation (EV) предполагает комплексную проверку через международные реестры
Автоматизированные протоколы (ACME, используемый Let's Encrypt и другими CA) также становятся недоступными.
Прогнозируемый временной горизонт
Анализ дат истечения сертификатов показывает, что при полной изоляции:
- Через 6-12 месяцев начнется массовое истечение текущих сертификатов
- Через 18-24 месяца практически вся инфраструктура, завязанная на глобальные CA, окажется нефункциональной
Практический пример временных рисков: Крупный российский банк использует EV-сертификат от DigiCert, истекающий 15 марта 2026 года. При изоляции от интернета после 1 января 2026 года банк физически не сможет перевыпустить сертификат через стандартные процедуры DigiCert, что приведет к полной недоступности онлайн-банкинга для миллионов клиентов.
Критический момент: Let's Encrypt, широко используемый российскими стартапами и небольшими компаниями, выдает сертификаты на 90 дней. При изоляции такие ресурсы станут недоступными уже через 3 месяца без возможности автоматического продления через ACME-протокол.
Исследование централизации: научные данные об уязвимости
Академическое исследование "Assessing SSL/TLS Certificate Centralization: Implications for Digital Sovereignty" предоставляет критически важную статистику о степени зависимости российской PKI-инфраструктуры от зарубежных центров сертификации.
Ключевые научные выводы:
- 75%+ российских доменов зависят от небольшого числа международных CA
- Это создает системный риск единой точки отказа на государственном уровне
- Цифровой суверенитет России оказывается под угрозой из-за критической зависимости от зарубежной PKI-инфраструктуры
Сравнительный анализ: Исследование показывает, что Россия как часть BRICS демонстрирует аналогичные паттерны централизации с ЕС, что указывает на глобальную проблему концентрации PKI-власти в руках нескольких западных корпораций.
Практические последствия исследования: Научные данные подтверждают наши технические наблюдения - российская интернет-инфраструктура структурно уязвима к внешним воздействиям на уровне базовых протоколов безопасности.
Альтернативные решения и их ограничения
Российские удостоверяющие центры
Теоретически возможен переход на сертификаты российских CA:
- УЦ Минкомсвязи России
- Аккредитованные коммерческие УЦ (ООО "ТрастЛайн", АО "Актив-Софт" и др.)
- Внутренние корпоративные CA
Критическая проблема: эти сертификаты не включены в доверенные хранилища международных браузеров и операционных систем, что потребует массовой ручной установки корневых сертификатов на клиентские устройства.
Реальный пример проблемы доверия: Попытка доступа к сайту с сертификатом от российского УЦ Минкомсвязи в стандартном Chrome приводит к ошибке NET::ERR_CERT_AUTHORITY_INVALID. Для работы потребуется:
- Скачать корневой сертификат Минкомсвязи России
- Импортировать его в хранилище доверенных центров Windows/macOS/Linux
- Перезапустить браузер
- Повторить процедуру на каждом клиентском устройстве
Масштаб проблемы: В крупной российской компании (10,000+ сотрудников) такая миграция потребует обновления конфигурации на всех рабочих станциях, серверах, мобильных устройствах и IoT-системах - операция, измеряемая месяцами технических работ.
Self-signed и внутренние CA
Использование самоподписанных сертификатов или внутренних удостоверяющих центров решает техническую проблему, но создает новые:
- Необходимость развертывания PKI-инфраструктуры
- Сложности с управлением доверием на клиентской стороне
- Потеря автоматической валидации подлинности ресурсов
Рекомендации для инженеров и специалистов ИБ
Немедленные меры
Аудит конфигурации серверов: Убедитесь, что ваши веб-серверы передают полную цепочку сертификатов, включая все промежуточные CA. Используйте инструменты вроде
openssl s_client,testssl.shили онлайн-сервисы для проверки.Мониторинг сроков истечения: Внедрите автоматизированные системы отслеживания дат истечения всех сертификатов в вашей инфраструктуре. Критически важно иметь полную видимость временных рисков.
Тестирование в изолированной среде: Проведите тестирование работоспособности ваших ресурсов в условиях отсутствия доступа к внешним CA-сервисам.
Практический метод тестирования: Создайте изолированную тестовую среду, заблокировав доступ к внешним CA-ресурсам через firewall:
# Блокируем популярные CA-домены
Если ваш сайт становится недоступным в такой среде - у вас критическая проблема с конфигурацией SSL.
Стратегические решения
Диверсификация PKI-поставщиков: Рассмотрите возможность использования гибридного подхода с комбинацией международных и локальных удостоверяющих центров.
Развертывание внутренней PKI: For критически важных сервисов подготовьте резервную PKI-инфраструктуру на базе внутренних или российских CA.
Планирование непрерывности бизнеса: Включите PKI-риски в планы обеспечения непрерывности бизнеса и катастрофоустойчивости.
Технические детали реализации
Nginx: Убедитесь, что директива ssl_certificate указывает на файл, содержащий полную цепочку:
ssl_certificate /path/to/fullchain.pem;
Apache: Используйте SSLCertificateChainFile или включите промежуточные сертификаты в основной файл сертификата.
Load Balancers: Проверьте корректность конфигурации SSL termination с передачей полных цепочек.
Заключение
PKI-инфраструктура современного интернета основана на глобальной связности и доверии к международным удостоверяющим центрам. В условиях потенциальной сетевой изоляции эта зависимость становится критической уязвимостью.
Научные данные подтверждают серьезность ситуации: Исследование централизации SSL/TLS-сертификатов показывает, что более 75% российских доменов критически зависят от небольшого числа зарубежных CA. Это создает беспрецедентную уязвимость цифрового суверенитета на уровне базовых протоколов безопасности.
Российские организации должны уже сейчас оценить свои PKI-риски и подготовить альтернативные сценарии. Время на подготовку ограничено существующими сроками действия сертификатов, и откладывание решения этих вопросов может привести к серьезным операционным проблемам.
Как показывает наш анализ, проблема не только в политических решениях, но и в фундаментальных технических аспектах современной PKI-архитектуры. Предотвращение катастрофических сбоев требует проактивного подхода и глубокого понимания технических нюансов SSL/TLS-протоколов.
Статья подготовлена экспертами по информационной безопасности и PKI-технологиям. Для получения консультаций по аудиту и модернизации PKI-инфраструктуры вашей организации обращайтесь к специалистам.
Читайте телеграм-канал Топ Кибербезопасности Батранкова