Клиентские сертификаты кончились дважды — clientAuth и отзыв GlobalSign

8 июля 2026 года Let's Encrypt выключил профиль tlsclient. Это была последняя дверь, через которую можно было бесплатно получить публичный сертификат с флагом клиентской аутентификации. Дверь закрылась тихо: сайты работают, Certbot продлевает, браузеры молчат.

За месяц до этого, 13 июня в 04:07 по Москве, японский GlobalSign запустил массовый отзыв сертификатов у российских компаний. Под удаление попало, по оценкам участников рынка хостинга, 15–20 тысяч доменов второго уровня.

Два события разной природы. Первое — отраслевая стандартизация, которую готовили полтора года и обсуждали публично. Второе — исполнение санкционных режимов ЕС компанией, зарегистрированной в Бельгии и принадлежащей японской GMO Internet Group. Но для инженера в Москве, который поднял mTLS между платёжным шлюзом и процессингом на публичных сертификатах, оба приезжают одинаково: как отказ в проде.

Вывод из обоих один, и он неудобный. Вы никогда не владели своим корнем доверия. Вы его арендовали.

Часть 1. Что произошло в мировом PKI

1. Клиентская аутентификация: о чём вообще речь

В обычном вебе проверка односторонняя. Вы открываете https://mybank.ru, браузер спрашивает сервер: «Ты кто?». Сервер показывает сертификат, подписанный доверенным удостоверяющим центром. Браузер проверяет математику и цепочку, рисует замочек. Кто сидит за клавиатурой, сервер при этом не знает.

Клиент (Браузер)                 Сервер (Банк)
     |                                 |
     | ----- "Кто ты?" --------------> |
     | <---- Серверный сертификат ---- |
     |                                 |
[Проверка цепочки до корня]            |
"Ок, ты действительно банк"            |

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

Здесь включается mTLS, взаимная аутентификация.

Клиент (B2B-партнёр)             Сервер (API-шлюз)
     |                                 |
     | ----- "Кто ты?" --------------> |
     | <---- Серверный сертификат ---- |
     |                                 |
     | <---- "А ты кто?" ------------- |
     | ----- Клиентский сертификат --> |
     |                                 |
[Взаимная проверка]              [Взаимная проверка]

Сервер проверяет клиента ровно так же, как клиент проверяет сервер. Без валидного клиентского сертификата TLS-рукопожатие обрывается до того, как приложение увидит хоть один байт полезной нагрузки: соединение рвётся на уровне TLS, приложение о нём просто не узнаёт. Ни WAF, ни парсер, ни ORM в деле не участвуют. Это очень хороший фильтр. Так работают банковские API, межсервисное взаимодействие в Kubernetes, туннели OpenVPN и шлюзы IPsec.

2. EKU Client Authentication: механика

Криптографический ключ — это математика. Сам по себе он не знает, для чего создан: шифровать диск, подписывать документ или поднимать VPN.

Чтобы ограничить область применения, в стандарте X.509 придумали расширение Extended Key Usage. Внутри сертификата лежит список разрешённых ролей в виде объектных идентификаторов.

Обычный сертификат веб-сайта содержит OID 1.3.6.1.5.5.7.3.1:

X509v3 Extended Key Usage:
    TLS Web Server Authentication

Сертификат, который работает пропуском для клиента, обязан содержать 1.3.6.1.5.5.7.3.2:

X509v3 Extended Key Usage:
    TLS Web Client Authentication

Дальше начинается интересное. Когда сервер на OpenSSL проверяет клиентскую цепочку, библиотека сама подставляет цель проверки ssl_client. Логика отбраковки простая и стоит того, чтобы её запомнить: если расширение EKU в сертификате присутствует и клиентской аутентификации в нём нет — сертификат отвергается с ошибкой unsupported certificate purpose. Если расширения EKU нет вовсе — сертификат проходит.

Отсюда практическое следствие, которое ломает интуицию: самоподписанный сертификат вообще без EKU у вас заработает, а безупречный сертификат Let's Encrypt образца 2026 года — нет. Go в crypto/tls ведёт себя так же, SunJSSE в Java — так же, ASP.NET Core — так же.

3. Почему публичные УЦ вообще это выпускали

Публичные удостоверяющие центры строились вокруг одной задачи: подтвердить владение доменным именем. Протокол ACME выполняет проверку HTTP-01 или DNS-01 и устанавливает ровно один факт — вы контролируете сервер, который отвечает по имени api.company.ru, прямо сейчас.

mTLS задаёт принципиально другой вопрос: имеет ли этот конкретный процесс право подключаться к моему внутреннему API? Кто именно стучится в закрытый шлюз — микросервис платежей, антифрод, партнёр по логистике или чей-то ноутбук с утёкшим ключом?

Публичный УЦ про вашу внутреннюю иерархию не знает ничего. Он знает DNS. Годами публичные центры по инерции ставили в сертификат сразу два флага, и разработчики этим пользовались: certbot выдал файл, скормили его OpenVPN, работает. Архитектурно это была отложенная авария.

4. В чём именно ошибка

Представьте проходную. Охраннику дали инструкцию: пускать всех, у кого бейджик заламинирован в типографии «Let's Encrypt».

Проблема в том, что типография публичная. Она бесплатно и совершенно легально ламинирует бейджик любому, кто доказал, что владеет хоть каким-нибудь доменом. Злоумышленник регистрирует super-hacker-site.info, запускает Certbot, получает криптографически безупречный сертификат и стучится в ваш mTLS-порт.

Если в конфиге написано вот так:

ssl_client_certificate /etc/nginx/letsencrypt-root.pem;
ssl_verify_client on;

охранник посмотрит на подпись, кивнёт и пропустит. Сертификат настоящий. Человек чужой.

Здесь стоит остановиться, потому что в большинстве публикаций эту связь не проговаривают. Удаление clientAuth не «сломало вам mTLS». Оно закрыло ровно ту дыру, которая описана абзацем выше. Отрасль десять лет знала о ней и наконец убрала грабли из-под ног. То, что вы на них стояли, — не заслуга отрасли.

5. Точные даты: кто, что и когда убрал

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

Chrome Root Program Policy v1.8 задаёт две границы, и это разные вещи:

Первоначально Google ставил июнь 2026 и для конечных сертификатов, потом перенёс. Многие статьи до сих пор цитируют старую дату и пишут, что с 15 июня Chrome начнёт отвергать сертификаты с clientAuth. Это неверно: выпущенные раньше сертификаты доживают до истечения срока.

Отдельно по центрам:

Let's Encrypt заодно 13 мая перевёл основной профиль на новую иерархию Generation Y, промежуточные центры которой clientAuth не содержат в принципе. Это делает 8 июля не постепенным ужесточением, а обрывом.

И ещё одна дата, о которой забывают: с 15 марта 2026 максимальный срок жизни публичного TLS-сертификата — 200 дней. Дальше он поедет вниз: Let's Encrypt объявил переход на 64 дня в феврале 2027 и на 45 дней в феврале 2028. Практический смысл в том, что весь ваш парк сертификатов полностью обновится меньше чем за год. Никакого «у нас ещё три года в запасе» не существует.

6. «А давайте просто отключим проверку EKU»

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

В ASP.NET Core есть параметр CertificateAuthenticationOptions.ValidateCertificateUse. По умолчанию true, ставится в false одной строкой, и проверка клиентского EKU выключается. В Go можно передать x509.ExtKeyUsageAny в VerifyOptions или написать собственный VerifyPeerCertificate. В Java — свой X509TrustManager. В Dart такого флага нет, хотя запрос на его добавление в SDK висит с 2025 года; пока рукопожатие падает с unsupported certificate purpose до того, как сокет вернётся приложению.

В промышленных серверах — nginx, HAProxy, Envoy — кнопки выключения нет. Проверка живёт внутри OpenSSL и BoringSSL. Чтобы её обойти, придётся патчить и пересобирать криптодвижок.

Так вот: даже там, где выключатель есть, трогать его нельзя.

Отключить валидацию EKU — это вырезать замок болгаркой, потому что потеряли ключ. Вы говорите шлюзу: принимай любой математически валидный сертификат, кем бы и для чего бы он ни был выпущен. Дальше атакующий берёт совершенно легальный серверный сертификат своего сайта hacker-shop.com, предъявляет его вашему корпоративному mTLS-порту, и ваш сервер видит валидную подпись известного центра. Строгая взаимная идентификация превращается в проверку того, что у собеседника вообще есть хоть какой-то сертификат.

Правильное разделение выглядит так. Для веб-сервера, который слушает интернет, — публичный сертификат, только serverAuth. Для клиентов в mTLS — свой корпоративный УЦ, только clientAuth. Две независимые иерархии, которые никогда не пересекаются.

Часть 2. Российский контур

Всё написанное выше верно для любой юрисдикции. Дальше начинается то, чего нет в англоязычных разборах.

7. 13 июня: как это выглядело

GlobalSign — второй в мире центр сертификации по количеству действующих сертификатов, доля около 20,4% по данным W3Techs. Компания основана в Бельгии и входит в японский холдинг GMO Internet Group, поэтому обязана исполнять санкционные режимы ЕС и учитывать американские списки OFAC SDN и BIS.

После 2022 года, когда Sectigo, DigiCert, Thawte, GeoTrust и RapidSSL свернули работу с российскими доменами, а GoDaddy ушёл в конце 2023-го, GlobalSign остался фактически последним крупным коммерческим центром, работавшим с Россией. По оценке замгендиректора Astra Cloud Константина Анисимова, на него приходилось около 90% коммерческого сегмента западных сертификатов в стране.

Отзыв прошёл одним автоматическим пакетом. В опубликованном срезе на 287 записей все сертификаты отозваны 13 июня между 04:07 и 04:09 по Москве, тремя партиями за три минуты, все выпущены одним промежуточным центром линейки OV SSL CA 2018. Машинная обработка санкционного списка, не разбор по обращениям.

Состав пострадавших объясняет расхождение оценок. Минцифры говорит, что доля GlobalSign в рунете не превышала 5%, рынок говорит про 90%. Обе цифры верны, просто считают разное: 5% — по всей массе сайтов, включая мелочь на бесплатном Let's Encrypt, 90% — по платному сегменту, где сидят банки и корпоративные сервисы. В срезе видно НСПК (оператор «Мира» и СБП), «АльфаСтрахование», СОГАЗ, Россельхозбанк, НОВАТЭК, Сургутнефтегаз, АЛРОСА.

Самое интересное — куда мигрировали. Лидер замены в выборке не НУЦ Минцифры, а греческий академический центр HARICA: около 74 сертификатов. Вторым идёт Let's Encrypt, около 43. На отечественный НУЦ перешло примерно 19, в основном структуры, прямо завязанные на государство. Половина хостов на момент выгрузки вообще осталась без действующей замены.

Даже подсанкционные организации, которым западный сертификат получить сложнее всех, в большинстве выбрали европейский и американский центры. Причина простая и техническая: HARICA и Let's Encrypt работают из коробки, а сертификату НУЦ браузеры не доверяют.

8. Про версию с «новыми требованиями CA/Browser Forum»

Здесь придётся разойтись почти со всем русскоязычным освещением.

В письме гендиректора российского юрлица GlobalSign партнёрам, которое пересказал РБК, причиной отзыва названы новые требования консорциума CA/Browser Forum. Дальше эта версия разошлась по хостерам и медиа в конкретной формулировке: 4 мая 2026 года вступил в силу документ, сделавший проверку по санкционным спискам OFAC SDN и BIS обязательной, а не рекомендательной.

Я открыл полный публичный список голосований консорциума. За период с конца 2025 по июль 2026 приняты голосования по срокам жизни сертификатов (SC081v3), отказу от SHA-1 (SC097), требованиям DNSSEC (SC085, SC094v2, SC096), обработке параметров CAA (SC098), методам доменной валидации (SC088v3, SC090, SC091), планированию массового отзыва (SC089). Ни одного голосования про санкции, OFAC или BIS там нет. Свежий SC103, «Require EKUs for Cross-Certified Subordinate CAs», сейчас в стадии обсуждения и продолжает ту же линию про EKU, к санкциям отношения не имеет.

Обязанность проверять заявителя по государственным denied-листам своей юрисдикции лежит на публичных УЦ давно, и это не новость мая 2026 года. Новость в другом: GlobalSign исполняет санкционное право ЕС напрямую, как компания из ЕС и Японии. Ссылка на «жёсткие регламенты консорциума» — это перевод стрелок на отраслевые правила там, где работает национальное законодательство.

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

9. Почему сертификат НУЦ не решает задачу mTLS

Минцифры отреагировало быстро и предложило понятный выход: бесплатный TLS-сертификат Национального удостоверяющего центра через «Госуслуги», DV или OV, на алгоритмах RSA или ГОСТ. Для DV — один рабочий день, для OV — пять.

Для публичного сайта у этого решения есть известное ограничение: корневому сертификату Russian Trusted Root CA из коробки доверяют только «Яндекс.Браузер» и «Атом». В Chrome, Firefox, Safari и Edge посетитель увидит ошибку, пока вручную не установит корень в систему. Алексей Лукацкий приводит расклад по парку: около 83% машин в России под Windows, ещё 7% под macOS, на отечественные ОС приходится порядка 3%. Просить сотни тысяч посетителей вручную поставить корневой сертификат — не стратегия.

Но для нашей темы важнее другое, и об этом не пишут вообще нигде.

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

НУЦ — публичный удостоверяющий центр. Он выдаёт сертификаты по доменной валидации любому российскому юрлицу, ИП и физлицу, бесплатно, за один день. Настроив шлюз на доверие корню НУЦ, вы объявили доверенным клиентом каждое зарегистрированное в стране лицо, которое сумело подтвердить владение любым доменом. Это ровно тот же злоумышленник с super-hacker-site.info, только теперь он получает бейджик не в американской типографии, а в отечественной.

То же касается ТЦИ. «Технический центр Интернет» с 2022 года выпускает TLS-сертификаты на ECDSA и ГОСТ 34.10, его корень попал в доверенные для ОС «Аврора», выпуск автоматизирован. Хороший публичный центр, к серверной аутентификации вопросов нет. Как источник клиентских удостоверений — та же ошибка, что и Let's Encrypt.

Публичный УЦ отвечает на вопрос «кому принадлежит домен». Он никогда не отвечал и не будет отвечать на вопрос «имеет ли этот процесс право дёрнуть мой платёжный API». Смена юрисдикции публичного центра эту задачу не решает и решить не может.

10. Что говорит регулятор

Хорошая новость в том, что миграцию на собственный PKI вам, скорее всего, всё равно предписано делать, и бюджет на неё можно защищать не страшилками про GlobalSign, а нормативкой.

Приказ ФСТЭК России № 117 от 11.04.2025 вступил в силу 1 марта 2026 года и заменил приказ № 17, проживший больше десяти лет. Он распространяется на ГИС и иные системы госорганов, ГУПов и госучреждений. Идентификация и аутентификация вынесены в нём на уровень базовых мер, отдельно усилены требования к привилегированному доступу и к защите программных интерфейсов взаимодействия приложений. Приказ № 17 писался, когда системы были монолитными, а API и контейнеры роли не играли. Новый прямо адресует API, контейнерные среды и облака — то есть ровно ту поверхность, где живёт mTLS. Аттестаты, выданные до 1 марта 2026, действуют только при неизменной конфигурации системы: перестроите доверие — придётся аттестовываться заново, и лучше сразу по-новому.

Криптография. Если система требует сертифицированных СКЗИ, ваш внутренний УЦ должен строиться на ГОСТ Р 34.10-2012 и работать на решении с действующим сертификатом ФСБ. Здесь у отечественного рынка всё как раз в порядке, к этому вернёмся в разделе про миграцию.

Домены. Федеральный закон от 29.12.2025 № 569-ФЗ вводит с 1 сентября 2026 обязательную идентификацию администраторов доменов в зонах .ru, .рф и .su через ЕСИА. С той же даты планируется закрепить полномочия НУЦ в обновлённой редакции закона о связи. Направление движения читается однозначно: идентичность на каждом слое инфраструктуры переезжает под национальный контроль.

Подпись кода. Отдельный фронт, который заденет тех, у кого с TLS всё в порядке. GlobalSign выдавал не только TLS, но и сертификаты подписи кода, без которых драйвер или приложение не ставится на Windows и macOS без предупреждений. НУЦ получил право выпускать отечественные сертификаты подписи кода, параллельно тестируется ГОСТ в Linux и Android. Ограничение то же самое: пока Windows не доверяет корню, отечественный сертификат подписи ничего не меняет. Если вы поставляете софт или прошивки — считайте экспозицию отдельно от сайтов.

Часть 3. Что делать

11. Проверить сертификаты

Гадать не нужно. Найдите файлы, которые реально используются в качестве клиентских, и прогоните через OpenSSL:

openssl x509 -noout -text -in client.pem | grep -A1 "Extended Key Usage"

Рабочий вариант — явное указание на клиентскую аутентификацию:

X509v3 Extended Key Usage:
    TLS Web Client Authentication

Если там только TLS Web Server Authentication — этот сертификат в качестве клиентского не заработает. Пустой вывод, как ни странно, означает, что заработает: EKU отсутствует, отбраковывать нечего.

Дальше смотрим издателя:

openssl x509 -noout -issuer -dates -in client.pem

Let's Encrypt, ZeroSSL, DigiCert, GlobalSign, Sectigo, НУЦ Минцифры, ТЦИ в поле issuer — вы в зоне риска по обеим причинам сразу: и по EKU, и по санкциям. Дата notAfter показывает, сколько у вас осталось.

Массовую инвентаризацию удобно снять со шлюзов:

grep -rn "ssl_verify_client\|ssl_client_certificate\|verify-client\|auth-tls-verify-client" \
  /etc/nginx /etc/haproxy /etc/envoy 2>/dev/null

В Kubernetes ищите аннотации nginx.ingress.kubernetes.io/auth-tls-verify-client и объекты cert-manager с issuerRef на публичный ACME.

12. Проверить логику сервера

Даже если сертификаты пока живы, конфигурация может быть дырявой сама по себе. Опора только на проверку корня — фатальная ошибка.

Так писать нельзя:

server {
    listen 443 ssl;
    server_name api.company.ru;

    # Доверяем всем сертификатам публичного центра
    ssl_client_certificate /etc/ssl/certs/letsencrypt-root.pem;
    ssl_verify_client on;

    location / {
        proxy_pass http://backend;   # войдёт любой владелец любого домена
    }
}

Так правильно:

# Белый список конкретных субъектов вместо «любой от нашего CA»
map $ssl_client_s_dn $client_allowed {
    default                                        0;
    "~,?CN=payment-service\.prod\.internal$"        1;
    "~,?CN=fraud-detection\.prod\.internal$"        1;
}

server {
    listen 443 ssl;
    server_name api.company.ru;

    # 1. Доверяем ТОЛЬКО собственному внутреннему CA
    ssl_client_certificate /etc/ssl/certs/my-internal-ca.pem;
    ssl_verify_client on;
    ssl_verify_depth 2;

    # 2. Проверяем отзыв
    ssl_crl /etc/ssl/certs/my-internal-ca.crl;

    location / {
        # 3. Проверяем, КТО пришёл, а не только кем подписан
        if ($client_allowed = 0) { return 403; }

        # 4. Отдаём идентичность приложению для RBAC
        proxy_set_header X-Client-DN     $ssl_client_s_dn;
        proxy_set_header X-Client-Serial $ssl_client_serial;
        proxy_set_header X-Client-Verify $ssl_client_verify;
        proxy_pass http://backend;
    }
}

Два замечания по коду. map лучше цепочки if, потому что список субъектов растёт и его удобнее держать в одном месте. С версии 1.11.6 nginx отдаёт $ssl_client_s_dn в формате RFC 2253, где поля идут в обратном порядке и CN может оказаться не первым — регулярка написана с учётом этого, но проверьте на своём выводе, прежде чем катить.

И главное: если бэкенд принимает заголовок X-Client-DN от кого угодно, а не только от шлюза, вы построили аутентификацию, которую обходит curl. Заголовки от клиента на входе в шлюз надо вычищать.

13. Чем заменить: четыре сценария

Перестаньте искать бесплатную публичную замену Let's Encrypt для mTLS. Её нет и не будет — это и есть смысл всей отраслевой реформы.

Хорошая новость для России: mTLS — единственный слой, где санкции вам ничего не сделают. Для публичного сайта вы обязаны получить признание чужих корневых хранилищ, и здесь вы в заложниках. В mTLS вы владеете обоими концами соединения. Никого убеждать не нужно, ни в чей trust store попадать не надо. Свой корень, свои клиенты, свой шлюз. Это не компромисс и не импортозамещение через силу — это правильная архитектура, к которой отрасль пришла независимо.

Сценарий 1. Свой CA на открытом софте. step-ca от Smallstep — современный центр с поддержкой ACME, лицензия Apache 2.0, разворачивается локально, никаких обращений к вендору. Для простых задач хватит OpenSSL или EasyRSA, для инфраструктурных — CFSSL. Если нужен полноценный secrets engine с PKI, смотрите OpenBao: это форк Vault под управлением Linux Foundation на лицензии MPL-2.0, живущий без оглядки на HashiCorp. Плюс — полный контроль над сроками жизни, можно выписывать сертификаты хоть на десять минут. Минус — корневой ключ придётся охранять всерьёз, желательно в HSM.

Сценарий 2. Российский сертифицированный УЦ. Обязателен там, где нужны сертифицированные ФСБ СКЗИ и ГОСТ: ГИС под приказом 117, значимые объекты КИИ, отдельные классы систем с персональными данными. ПАК «КриптоПро УЦ 2.0» работает и как средство УЦ в нотации 63-ФЗ, и как центр управления сертификатами. У «ИнфоТеКС» — линейка ViPNet PKI вместе с ViPNet TLS Gateway, обратным прокси для ГОСТ TLS. Для управления жизненным циклом сертификатов и носителей сложился устойчивый рынок: Avanpost PKI и Avanpost CA, Indeed Certificate Manager от «Индид», решения «Актива» и «Аладдин Р.Д.». Всё в реестре отечественного ПО, всё с сертификатами ФСТЭК.

Сценарий 3. SPIFFE/SPIRE для Kubernetes. Стандарт де-факто для динамических сред. Проект отказывается от доменных имён в идентификации: в SAN URI пишется идентификатор нагрузки вида spiffe://cluster.local/ns/prod/sa/payment-service. Сертификаты живут час-два и ротируются незаметно для приложений, проблема долгоживущих украденных ключей исчезает как класс. Плата — агенты SPIRE в кластере и другой способ думать про сетевую безопасность.

Сценарий 4, которого у вас нет. Во всех англоязычных гайдах на этом месте стоят AWS Private CA, Google Cloud Certificate Authority Service, DigiCert ONE и HashiCorp HCP Vault. Для российской компании это мёртвые опции: HashiCorp закрыла доступ ещё в марте 2022, AWS и Microsoft отключили российские организации от облаков в марте 2024 в рамках двенадцатого пакета санкций ЕС, сайт AWS с российского адреса отдаёт 404. Если вам приносят план миграции с этими названиями — план писали не глядя.

14. План миграции

Не переключайте всё за ночь. Замена PKI — операция на работающем сердце сети.

Этап 1. Инвентаризация. Прогоните grep из раздела 11 по всем балансировщикам, VPN-концентраторам и шлюзам. Соберите базу выписанных клиентских сертификатов: издатель, дата истечения, наличие clientAuth. Отдельной колонкой — владелец. Вы должны знать, чей именно cron или DaemonSet стучится в каждый шлюз, иначе на этапе переключения найдёте это опытным путём в три часа ночи. Мобильные приложения с certificate pinning выносите в отдельный список: им нужен не новый сертификат, а релиз в сторе, а если приложение из стора удалили — доставить обновление уже нечем. Мессенджер Max в июне попал ровно в эту ловушку.

Этап 2. Модель доверия. Выберите инструмент. Зафиксируйте иерархию: корневой сертификат в защищённом хранилище на десять лет, промежуточный для ежедневной работы на год-два. Опишите политику именования — что пишется в CN и SAN: доменное имя, серийный номер устройства, SPIFFE ID. Поднимите внутренний ACME, чтобы перевыпуск был таким же скучным, каким был с Let's Encrypt. Автоматизация здесь не роскошь: при сроке жизни в 45 дней ручной перевыпуск — это отдельная штатная единица.

Этап 3. Dual-trust. Выпустите новые клиентские сертификаты от своего CA. Старый корень пока не удаляйте: соберите оба корневых сертификата в один bundle.pem и настройте шлюз доверять обоим одновременно. Переключайте клиентов партиями, смотрите на метрики успешных рукопожатий. Когда последний клиент переехал — убирайте публичный корень из доверенных и перезапускайте шлюз.

Этап 4. Проверка отзыва. Это то, что все откладывают и о чём потом жалеют. Июньская история показала, почему: Chrome и Edge давно отключили онлайн-проверку отзыва и полагаются на собственные сводные списки, Firefox проверяет в основном сертификаты с расширенной проверкой, мобильные браузеры почти не проверяют вовсе. Именно поэтому отзыв 15–20 тысяч доменов не обрушил рунет за сутки — он превратился в растянутую деградацию по мере истечения сроков. В своём PKI такой роскоши нет: CRL и OCSP должны реально работать и реально проверяться, иначе уволенный сотрудник и скомпрометированный микросервис останутся валидными до конца срока действия.

Отзыв GlobalSign и удаление clientAuth случились в одном месяце по не связанным между собой причинам. Совпадение показало то, что было верно и раньше: пока корень вашего доверия подписан кем-то другим, ваша аутентификация — это чужое решение, принятое без вас. В июне его приняли в Токио и Брюсселе, в феврале — в комитете CA/Browser Forum. В следующий раз его примут где-нибудь ещё.

Своим корнем в mTLS вы владеете полностью. Это единственный слой, где вопрос закрывается инженерным решением, а не переговорами.

Денис Батранков, 34 года в информационной безопасности, CISSP. Разборы и практика — в канале «Топ Кибербезопасности». Корпоративное обучение и консультации — @ngksiva.