Дисклеймер: статья про техническую сторону вопроса. Без политической агитации и прогнозов в жанре «всё пропало». Задача — разложить реальные события июня 2026 года по фактам, объяснить механику TLS-сертификатов и показать, где заканчивается инженерия и начинается паника. Все факты привязаны к источникам в конце материала; детали в этой области меняются быстро, поэтому проверяйте по актуальным данным.

1. Введение: что произошло в июне 2026

В первые недели июня 2026 года по новостным лентам и Telegram-каналам прокатилась волна заголовков: «У MAX отозвали сертификат», «Браузеры блокируют веб-версию мессенджера», «GlobalSign массово лишает российские сайты сертификатов — Рунет ломается». Сопровождалось всё это привычными скриншотами красных экранов и выводами, что российский интернет вот-вот «отрежут».

Если убрать эмоции, фактическая канва выглядит так (по сообщениям СМИ со ссылками на РБК, TAdviser и данные публичных CRL):

• 3 июня — Apple удалила мессенджер MAX из App Store и отключила для него push-уведомления, сославшись на санкции против структур VK.

• 4 июня — некоммерческий удостоверяющий центр Let’s Encrypt обновил пользовательское соглашение, добавив в раздел 3.1 запрет на выдачу сертификатов лицам и организациям под санкциями США (списки OFAC).

• 6 июня, около 00:37 — у домена *.max.ru сертификат, выданный центром GlobalSign (срок действия 12 января 2026 — 13 февраля 2027), получил статус Revoked с причиной «отзыв привилегии». Веб-версию MAX браузеры начали помечать как небезопасную. В тот же день команда перевела сервис на бесплатный сертификат Let’s Encrypt, но LE сразу обозначил, что не будет продлевать его после 4 сентября.

• 13 июня — по данным РБК (со ссылкой на письмо гендиректора российского юрлица GlobalSign), центр запустил поэтапный принудительный отзыв сертификатов у российских организаций. По оценкам участников рынка хостинга — порядка 15–20 тысяч доменов второго уровня, а с учётом поддоменов речь о сотнях тысяч сертификатов.

Причина, которую называют источники, — не «политический жест отдельной компании», а изменение отраслевых правил: с 4 мая 2026 вступили в силу обновлённые требования CA/Browser Forum, сделавшие проверку клиентов по санкционным спискам (OFAC SDN, BIS и их аналогам) обязательной, а не рекомендательной. GlobalSign (операционный центр в Бельгии, владелец — японская GMO Group) проводит аудит портфеля и отзывает сертификаты несоответствующих клиентов.

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

---

2. Что такое TLS/SSL-сертификаты

Зачем они нужны

Когда вы открываете https://example.com, между браузером и сервером устанавливается зашифрованное соединение по протоколу TLS (Transport Layer Security; SSL — устаревший предшественник, но название «SSL-сертификат» прижилось). TLS решает три задачи:

1. Шифрование — данные между вами и сайтом нельзя прочитать по дороге.

2. Целостность — данные нельзя незаметно подменить.

3. Аутентификация — вы общаетесь именно с тем сайтом, за который он себя выдаёт.

Третий пункт — ключевой для нашей темы. Шифровать трафик можно с кем угодно, но смысл появляется, только если вы уверены, что на другом конце именно max.ru, а не подставной сервер. За эту уверенность отвечает сертификат — электронный «паспорт» сайта, в котором указаны доменное имя, открытый ключ, срок действия и подпись того, кто этот паспорт выдал.

Удостоверяющий центр (CA) и цепочка доверия

«Паспорт» выдаёт удостоверяющий центр — Certificate Authority, CA. Это организация, которой браузеры и операционные системы согласились доверять: Let’s Encrypt, DigiCert, GlobalSign, Sectigo и другие. Доверие устроено иерархически:

graph TD
    Root["Корневой сертификат CA<br/>(Root CA)<br/>зашит в браузере/ОС"]
    Intermediate["Промежуточный сертификат<br/>(Intermediate CA)"]
    Leaf["Сертификат сайта<br/>(end-entity / leaf)<br/>max.ru"]

    Root -->|подписывает| Intermediate
    Intermediate -->|подписывает| Leaf

    style Root fill:#2d6a4f,color:#fff
    style Intermediate fill:#40916c,color:#fff
    style Leaf fill:#52b788,color:#fff

• Корневой сертификат (Root CA) — вершина доверия. Его закрытый ключ хранится в строжайшем секрете. Сами корни заранее зашиты в хранилище доверенных корней браузера или ОС.

• Промежуточный сертификат (Intermediate CA) — рабочая прослойка: корень подписывает промежуточный, а тот выдаёт сертификаты сайтам.

• Сертификат сайта (leaf) — собственно паспорт max.ru, подписанный промежуточным CA.

При подключении браузер проверяет всю цепочку:

sequenceDiagram
    participant B as Браузер
    participant S as Сервер (max.ru)
    participant Store as Хранилище корней

    B->>S: ClientHello (начало TLS)
    S->>B: Сертификат сайта + промежуточные
    B->>B: Проверка подписи leaf промежуточным
    B->>B: Проверка подписи промежуточного корнем
    B->>Store: Корень есть в списке доверенных?
    Store-->>B: Да, доверенный
    B->>B: Проверка срока действия и домена
    B->>S: Всё ок — устанавливаем сессию
    Note over B,S: Зелёный замок, HTTPS работает

Почему одним сертификатам доверяют, а другим — нет

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

Эти списки (root store) формируют сами вендоры — Mozilla, Microsoft, Apple, Google (у Chrome теперь свой Chrome Root Store). Чтобы CA туда попал, он проходит аудит на соответствие требованиям CA/Browser Forum. Это и есть «членский билет» в клуб доверия.

Отсюда два следствия, к которым мы будем возвращаться весь материал:

1. Доверие — это решение конкретного вендора браузера/ОС. Нет корня в хранилище — сертификаты на его основе считаются недоверенными, даже если технически безупречны.

2. Правила клуба пишет CA/Browser Forum. И именно изменение этих правил (обязательная санкционная проверка с 4 мая 2026) — первопричина июньских событий, а не «злая воля отдельного браузера».

---

3. Что означает отзыв сертификата

Здесь — главная терминологическая путаница, на которой держатся кликбейтные заголовки. Разберём по полочкам, потому что слово «отзыв» в новостях часто значит совсем не то, что в технике.

Три разных события, которые путают

Случай MAX — это первая строка: сертификат *.max.ru отозвал сам GlobalSign, то есть тот самый центр, который его и выдал. Это важная техническая деталь, опровергающая популярный миф: «отозвать чужой сертификат» извне нельзя — отзыв всегда исходит от выдавшего CA или владельца ключа. GlobalSign сделал это, исполняя новые обязательные правила санкционной проверки.

Как технически устроен отзыв

Отзыв (revocation) — это объявление ранее выданного сертификата недействительным до истечения срока. Информацию об отзыве CA публикует двумя классическими способами:

• CRL (Certificate Revocation List) — список отозванных сертификатов. Именно в CRL GlobalSign появилась запись об отзыве *.max.ru.

• OCSP (Online Certificate Status Protocol) — запрос статуса конкретного сертификата в реальном времени, с оптимизацией OCSP stapling.

graph LR
    A["Сертификат сайта"] --> B{"Проверка статуса"}
    B -->|CRL| C["Список отозванных<br/>от CA"]
    B -->|OCSP| D["Онлайн-запрос<br/>к CA"]
    C --> E{"Отозван?"}
    D --> E
    E -->|Да| F["Предупреждение<br/>ERR_CERT_REVOKED"]
    E -->|Нет| G["Соединение<br/>разрешено"]

    style F fill:#d00000,color:#fff
    style G fill:#52b788,color:#fff

Важнейшая поправка: браузеры проверяют отзыв далеко не всегда

А вот это СМИ почти всегда упускают, и зря — потому что именно здесь спрятана половина «сенсации». Расхожий тезис «браузер при каждом подключении сверяется со списком отозванных» технически неверен для современных браузеров:

• Chrome и Edge много версий назад отключили «живую» онлайн-проверку отзыва (OCSP) для обычных сертификатов. Вместо неё используется собственный агрегированный механизм — CRLSets, который скачивается с обновлениями и покрывает в основном «высокоприоритетные» отзывы.

• Firefox полагается на свой агрегированный механизм CRLite и делает онлайн-проверку в основном для EV-сертификатов.

• Мобильные браузеры исторически проверяют отзыв слабо или почти не проверяют.

Практический вывод парадоксален: сам по себе отзыв в браузере «срабатывает» не так жёстко и не так мгновенно, как пишут. Куда более жёсткий эффект даёт истечение срока и непродление — вот тогда сайт гарантированно начнёт выдавать ошибку у всех. Именно поэтому в кейсе MAX по-настоящему критична не дата отзыва (6 июня), а дата 4 сентября — момент, после которого Let’s Encrypt отказывается продлевать замену.

Когда браузер показывает предупреждение и почему это ≠ взлом

Браузер выдаёт ошибку сертификата, если он просрочен, не соответствует домену, цепочка не доходит до доверенного корня, сертификат отозван либо нарушены требования к криптографии. Вот реальные тексты (формулировки в разных версиях отличаются):

Google Chrome — нет доверенного корня:

Your connection is not private
Attackers might be trying to steal your information from
max.ru (for example, passwords, messages or credit cards).

NET::ERR_CERT_AUTHORITY_INVALID

Mozilla Firefox — неизвестный издатель:

Warning: Potential Security Risk Ahead
Firefox detected a potential security threat and did not continue.
The certificate is not trusted because the issuer certificate is unknown.

Error code: SEC_ERROR_UNKNOWN_ISSUER

Chrome — сертификат отозван / просрочен:

NET::ERR_CERT_REVOKED
NET::ERR_CERT_DATE_INVALID

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

---

4. Что происходит с российскими сервисами

Кейс MAX — по фактам

Собираем подтверждаемую хронологию в одну картину:

timeline
    title Хронология вокруг сертификата MAX (июнь 2026)
    3 июня : Apple удаляет MAX из App Store, отключает push
    4 июня : Let's Encrypt запрещает выдачу подсанкционным (OFAC) — п. 3.1
    6 июня : GlobalSign отзывает *.max.ru (Revoked) ; MAX в тот же день переходит на Let's Encrypt
    13 июня : GlobalSign начинает поэтапный массовый отзыв у росорганизаций
    4 сентября : дедлайн — Let's Encrypt не продлевает сертификат MAX

Что из этого факт, а что — интерпретация:

• Факт: сертификат *.max.ru от GlobalSign отозван, запись есть в публичном CRL; статус Revoked отражается в основных системах (Mozilla, Apple, Android, Java, Windows).

• Факт: MAX оперативно (в тот же день) перешёл на Let’s Encrypt и веб-версия продолжила работать.

• Факт: Let’s Encrypt обозначил отказ от продления после 4 сентября.

• Интерпретация/спекуляция: «MAX перестанет работать в сентябре». На деле к сентябрю у команды есть очевидный запасной путь — сертификаты национального УЦ (раздел 5), плюс возможность искать другие доступные CA. «Перестанет работать» подменяет «придётся сменить поставщика доверия».

Кейс VK и «массовость»

MAX принадлежит экосистеме VK, и удаление из App Store официально объяснялось санкциями против структур VK. При этом важно держать дисциплину: «отзыв у MAX» и «отзыв у всех доменов VK одномоментно» — разные утверждения. Крупная экосистема — это сотни доменов и поддоменов, часть которых обслуживается разными CA. У больших платформ есть ресурсы мониторить сроки, держать запасные сертификаты и переключаться. Поэтому корректная формулировка на момент написания: отзыв затронул конкретный сервис (MAX) и запущен поэтапный массовый процесс у GlobalSign, под который попадает широкий список российских доменов, — но это не мгновенное «выключение» всех сервисов VK.

Что реально видит пользователь

Когда сайт остаётся с отозванным или просроченным сертификатом, либо переходит на сертификат, корня которого нет в хранилище браузера:

• браузер показывает ERR_CERT_REVOKED, ERR_CERT_DATE_INVALID или ERR_CERT_AUTHORITY_INVALID;

• но сайт физически доступен (кроме случаев HSTS — о них ниже): можно пройти через предупреждение, соединение даже остаётся зашифрованным;

• в Яндекс Браузере и российских сборках, где предустановлен корень национального УЦ, сайты на национальных сертификатах открываются с обычным замком.

Где заканчиваются факты и начинается спекуляция

Факты: отзыв *.max.ru GlobalSign’ом состоялся; запущен поэтапный массовый отзыв; первопричина — обязательная санкционная проверка по правилам CA/Browser Forum с 4 мая 2026; Let’s Encrypt ограничил выдачу подсанкционным; существует национальный УЦ как запасной путь.

Спекуляции: «сайты перестают работать» (предупреждение ≠ недоступность); «Запад одним решением отозвал всё у Рунета» (отзыв исполняет выдавший CA по отраслевым правилам, поэтапно); «это происходит мгновенно и повсеместно» (процесс растянут и неоднороден); «отзыв сразу бьёт по всем браузерам» (Chrome/Edge онлайн-проверку отзыва не делают — см. раздел 3).

---

5. Есть ли у России собственная инфраструктура сертификатов

Да — и это центральный технический факт всей истории, превращающий «катастрофу» в «смену поставщика».

Национальный удостоверяющий центр

В России работает национальный удостоверяющий центр под эгидой Минцифры, бесплатно выдающий TLS-сертификаты российским сайтам. Технологически это обычный CA: те же стандарты X.509, те же цепочки «корень → промежуточный → сайт», тот же TLS. Разница не в криптографии, а в том, чей корень подписывает сертификаты и где этот корень признан доверенным.

graph TD
    subgraph "Международные хранилища"
        M1["Chrome Root Store"]
        M2["Mozilla Root Store"]
        M3["Apple / Microsoft"]
    end

    subgraph "Российская инфраструктура"
        RU["Корень национального УЦ"]
        RUInt["Промежуточный УЦ"]
        Site["Сайт российского сервиса"]
        RU --> RUInt --> Site
    end

    YB["Яндекс Браузер /<br/>российские сборки"]
    OS["Система с установленным<br/>национальным корнем"]

    RU -. "присутствует" .-> YB
    RU -. "присутствует" .-> OS
    RU -. "отсутствует" .-> M1
    RU -. "отсутствует" .-> M2
    RU -. "отсутствует" .-> M3

    style RU fill:#2d6a4f,color:#fff
    style M1 fill:#6c757d,color:#fff
    style M2 fill:#6c757d,color:#fff
    style M3 fill:#6c757d,color:#fff

Картинка резюмирует всю драму: национальные сертификаты технически валидны, но признаются доверенными только там, где есть соответствующий корень.

Распространение корня и поддержка в браузерах

Чтобы национальные сертификаты работали без «красных экранов», корень нужно доставить в хранилище доверия пользователя:

• предустановка в российских браузерах (прежде всего Яндекс Браузер) и сборках на базе Chromium;

• ручная установка корня в систему по официальным инструкциям (его можно скачать с портала Госуслуг и внести в доверенную зону ОС — для Windows, Android, iOS, Linux);

• штатное наличие в средах, где корень уже добавлен (госпорталы).

Отдельная техническая боль, которую честно стоит назвать: мобильные приложения с Certificate Pinning. Если приложение «прибито» к конкретному сертификату/CA, его смена требует обновления приложения. А если приложение уже удалено из App Store (как MAX), доставить патч пользователям iOS крайне сложно. Это реальная, а не выдуманная уязвимость — но она про мобильные приложения, а не про «весь Рунет в браузере».

Аргументы сторонников и критиков

Тема острая — приведём обе стороны нейтрально, как набор инженерных доводов.

За национальную инфраструктуру:

• Устойчивость и суверенитет. Возможность выпускать сертификаты не зависит от готовности иностранного CA обслуживать клиента — именно этот риск и реализовался в июне.

• Бесплатность и доступность для российских организаций.

• Мировая практика. Национальные/государственные CA есть во многих странах.

• Технически корректно — стандартный X.509, никакого «слома» криптографии.

Критики указывают на:

• Концентрацию доверия. Любой CA, чей корень у вас установлен, технически способен выпустить сертификат на любой домен — потенциальный вектор MITM. Это верно для всех CA, поэтому к ним и предъявляют жёсткие требования прозрачности.

• Отсутствие в международных хранилищах — пока корня нет в Mozilla/Chrome/Apple, без действий пользователя будет предупреждение.

• Прозрачность и аудит. Международные CA проходят публичный аудит и логируются в Certificate Transparency; критики подчёркивают важность таких же механизмов для любого CA.

• Принуждение к установке корня часть пользователей воспринимает как избыточное доверие к одному эмитенту.

Объективно это классический спор «контроль и устойчивость» против «распределённого доверия и независимого аудита». Оба набора доводов технически осмысленны.

---

6. Что будет, если ограничения станут массовыми

Массовый поэтапный отзыв GlobalSign уже идёт, так что это не гипотеза, а сценарий, который частично разворачивается. Смоделируем последствия для разных групп.

Пользователи Chrome, Firefox, Safari (без российского корня)

• На сайте с национальным сертификатом — ERR_CERT_AUTHORITY_INVALID / SEC_ERROR_UNKNOWN_ISSUER.

• Сайт доступен: «Дополнительно → Перейти на сайт». Соединение остаётся зашифрованным — теряется гарантия аутентификации средствами браузера, а не сам доступ.

• Исключение — сайты с HSTS (HTTP Strict Transport Security): для них браузер запрещает «кликнуть и пройти», и без установки корня доступ через этот браузер закрыт.

• На отозванный (но ещё не истёкший) сертификат многие десктопные и мобильные браузеры могут вообще не среагировать онлайн-проверкой — см. раздел 3.

Важно: это не сетевая блокировка. Запрос уходит, сервер отвечает. Вопрос — в индикации доверия конкретного браузера.

Пользователи Яндекс Браузера и российских сборок

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

Обходные механизмы (штатные и легальные)

graph TD
    P["Предупреждение<br/>о сертификате"] --> O1["Установить национальный<br/>корень в систему"]
    P --> O2["Использовать Яндекс Браузер<br/>(корень предустановлен)"]
    P --> O3["Пройти 'Перейти (небезопасно)'<br/>— кроме HSTS"]
    O1 --> R["Сайт открывается<br/>с нормальным замком"]
    O2 --> R
    style R fill:#52b788,color:#fff

• Установка национального корня — разовое действие, после которого все такие сайты открываются нормально в любом браузере, использующем системное хранилище.

• Браузер с предустановленным корнем.

• Проход через предупреждение (для сайтов без HSTS) — рабочий, но неудобный на каждый день.

Что делают крупные компании

• Быстрое переключение CA. Кейс MAX это уже продемонстрировал: отзыв утром — переход на Let’s Encrypt в тот же день. Доступность веба восстанавливается часами, а не неделями.

• Запасные сертификаты и мультидоменные стратегии: держать запасной CA там, где основной недоступен.

• Мониторинг сроков: автоматизация продления и алерты — чтобы не ловить ERR_CERT_DATE_INVALID на ровном месте. С учётом тренда на сокращение срока жизни сертификатов это становится критично для всех.

• Переход на национальный УЦ как финальный запасной путь, с онбордингом пользователей (инструкция по установке корня / совместимый браузер).

• Особое внимание мобильным приложениям с pinning — заблаговременная смена пиннинга и доставка обновлений.

---

7. Почему «всё пропало» — преувеличение

Технические причины

1. Предупреждение ≠ отключение. Ошибка сертификата не делает сайт недоступным на уровне сети. Это сигнал о невозможности проверки доверия, а не блокировка контента.

2. Отзыв в браузерах «бьёт» слабее, чем пишут. Chrome/Edge не делают онлайн-OCSP, мобильные браузеры почти не проверяют отзыв. Реальный жёсткий эффект даёт истечение и непродление — а это управляемые сроки.

3. Криптография не сломана. Национальные сертификаты — те же стандарты. Проблема в распространении корня, а это организационная, а не математическая задача.

4. Отзыв — адресная процедура выдавшего CA. Никто не «выключает кнопкой» чужие сертификаты у целой страны; даже массовый отзыв GlobalSign идёт поэтапно.

5. Доверие управляемо. Корень можно установить, браузер — выбрать. Это не билет в один конец.

Экономические причины

• Затронутые сервисы — это бизнес и инфраструктура с десятками миллионов пользователей. Поддержание доступности — прямой интерес, ресурсы и мотивация против «красных экранов» есть.

• Кейс MAX показал скорость реакции: замена сертификата в день отзыва. Это про работающие операционные процессы, а не про беспомощность.

Практический опыт

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

---

Мифы и заблуждения, которые гуляют по сети

Миф 1: «Сертификат отозвали — значит, сайт взломали». Нет. Ошибка сертификата означает, что браузер не смог проверить доверие (отозван, истёк, нет корня, ошибка конфигурации). Это не свидетельство взлома.

Миф 2: «Запад одним решением отозвал сертификаты у всего Рунета». Отозвать сертификат может только выдавший его CA или владелец ключа. У MAX это сделал сам GlobalSign, исполняя обязательные с 4 мая правила CA/Browser Forum по санкционной проверке. Массовый процесс идёт поэтапно, а не «одной кнопкой».

Миф 3: «Сайт с предупреждением недоступен». Доступен (кроме сайтов с HSTS), соединение даже остаётся зашифрованным. Теряется гарантия аутентификации средствами браузера, а не сам доступ.

Миф 4: «Браузер при каждом заходе проверяет список отозванных». Технически неверно для современных браузеров. Chrome и Edge отключили онлайн-проверку отзыва, Firefox делает её в основном для EV, мобильные — почти нет. Сильнее бьёт истечение/непродление, а не сам факт отзыва.

Миф 5: «Национальный сертификат — слабая/ненастоящая криптография». Нет, это стандартный X.509/TLS. Вопрос только в том, признан ли корень доверенным в вашем браузере.

Миф 6: «Установка российского корня = слежка за вами по умолчанию». Установка корня даёт его эмитенту техническую возможность выпускать сертификаты на любые домены — это верно для любого доверенного CA, включая международные. Сам факт установки не равен слежке; риски концентрации доверия — отдельный законный предмет дискуссии.

Миф 7: «MAX перестанет работать 4 сентября». 4 сентября — дедлайн непродления текущего сертификата Let’s Encrypt, а не «выключение». К этой дате есть запасной путь — национальный УЦ и/или другой доступный CA.

Миф 8: «Чтобы зайти на любой сайт, нужен спецбраузер». Для сайтов на национальных сертификатах достаточно один раз установить корень в систему — дальше подойдёт любой браузер, использующий системное хранилище.

---

8. Заключение

Если убрать заголовки, картина инженерная и приземлённая.

• Что реально произошло: у веб-версии MAX GlobalSign отозвал TLS-сертификат (6 июня), исполняя обязательные с 4 мая 2026 правила CA/Browser Forum по санкционной проверке; запущен поэтапный массовый отзыв у российских организаций; Let’s Encrypt ограничил выдачу подсанкционным и не продлит замену MAX после 4 сентября.

• Что это НЕ значит: не взлом, не сетевая блокировка, не «выключение» сервисов и не «конец Рунета». MAX в день отзыва переключился на другой CA и продолжил работать; у российских сервисов есть запасной путь — национальный УЦ; криптография стандартна, а проблема доверия решается установкой корня или выбором браузера.

• Что реально на кону: удобство и фрагментация доверия между браузерами, рост зависимости от того, чей корень установлен, и отдельная техническая боль мобильных приложений с Certificate Pinning (особенно на iOS после удаления из App Store).

Что стоит отслеживать по-настоящему:

• темп и охват поэтапного отзыва GlobalSign и реакцию других международных CA;

• появятся ли у национального УЦ механизмы прозрачности и независимого аудита (аналоги Certificate Transparency);

• судьбу мобильных приложений с pinning — это самое узкое место;

• общий тренд на сокращение срока жизни сертификатов: он повышает цену любой ошибки с продлением у всех, не только в России.

И главный вывод. Каждый раз, когда вы видите красный экран на скриншоте в Telegram с подписью «всё, отключают», полезно задать четыре технических вопроса:

1. Это истечение срока, отзыв или недоверие к корню? (Три разные истории.)

2. Сайт недоступен или просто показывает предупреждение?

3. В каком браузере скриншот и что в его хранилище (и проверяет ли этот браузер отзыв вообще)?

4. Это отзыв уже выданного сертификата или отказ в продлении?

Ответы почти всегда превращают «сенсацию» обратно в рутинную инженерную задачу. А умение их задавать — лучшая прививка и от паники, и от кликбейта.

---

Источники и материалы для дальнейшего изучения

Ссылки — ориентиры для самостоятельной проверки. Формулировки и сроки в этой области меняются быстро; сверяйте с актуальными версиями документов и первоисточниками (РБК, TAdviser, публичные CRL GlobalSign/Let’s Encrypt).

Освещение событий июня 2026 (вторичные источники, требуют критической оценки):

• РБК — сообщение о начале принудительного отзыва сертификатов GlobalSign у российских организаций (письмо гендиректора российского юрлица GlobalSign).

• iXBT — «Санкции могут оставить Max без зарубежного TLS-сертификата»

• Проект «Рыбарь» — «GlobalSign отзывает сертификаты у российских сайтов: что происходит и насколько это серьёзно»

• Freedom Checker (ateo.digital) — «У мессенджера MAX отозвали TLS-сертификат — что это значит для пользователей»

• SecurityLab — про статус домена MAX.RU в Cloudflare

• FirstVDS — «Международные удостоверяющие центры изменили правила работы с SSL-сертификатами»

• BFM — «Смогут ли российские сайты работать в случае отзыва международных TLS-сертификатов?»

Стандарты и базовая теория:

• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3.

• RFC 5280 — Internet X.509 PKI Certificate and CRL Profile.

• RFC 6960 — Online Certificate Status Protocol (OCSP).

• RFC 6066 — TLS Extensions (в т. ч. OCSP stapling).

• RFC 6797 — HTTP Strict Transport Security (HSTS).

• RFC 6962 — Certificate Transparency.

Политики доверия браузеров и CA:

• Mozilla CA Certificate Program и Mozilla Root Store Policy.

• Chrome Root Program Policy и Chrome Root Store; механизм CRLSets.

• Mozilla CRLite.

• Apple Root Certificate Program; Microsoft Trusted Root Program.

• CA/Browser Forum — Baseline Requirements (в том числе изменения, вступившие в силу в 2026 году).

Инструменты для самостоятельной проверки:

• SSL Labs Server Test (Qualys) — анализ цепочки и конфигурации TLS.

• crt.sh — поиск по логам Certificate Transparency.

• Просмотр сертификата в браузере (замок → «Сертификат») и вкладка Security в DevTools.

• openssl s_client -connect host:443 -showcerts — диагностика из консоли.

По национальной инфраструктуре сертификатов:

• Официальные материалы Минцифры РФ о национальном удостоверяющем центре и инструкции по установке корневого сертификата (Госуслуги; Windows, Android, iOS, Linux).

• Справка Яндекс Браузера о поддержке национальных сертификатов.

---

Если статья помогла отличить технический факт от заголовка — цель достигнута. Веб сложнее, чем «работает / не работает», и почти всегда интереснее, когда смотришь на него через схему цепочки доверия, а не через красный треугольник на чужом скриншоте.