В 2011 году взлом голландского центра сертификации DigiNotar наглядно показал странную особенность HTTPS. Защита Google могла зависеть от компании, которую Google не выбирал и с которой вообще не работал. DigiNotar подтвердил выпуск более 200 неправомерных сертификатов для более чем 20 доменов, а поддельный сертификат Google использовали для перехвата трафика пользователей в Иране. Mozilla в итоге полностью убрала DigiNotar из доверенных корней.
За следующие пятнадцать лет индустрия не придумала способ полностью избавиться от доверия к центрам сертификации. Вместо этого WebPKI стала делать доверие наблюдаемым и отзывным. Появились общие требования к выпуску сертификатов, публичные политики браузеров, Certificate Transparency, CCADB, CAA, обязательные отчеты об инцидентах и многоточечная проверка владения доменом. На мой взгляд, именно переход от «центр есть в списке, значит верим» к «центр постоянно доказывает право оставаться в списке» стал главным изменением WebPKI.
Корневой сертификат давал слишком много власти
Сначала полезно вспомнить, где вообще возникает доверие. Сервер с HTTPS отправляет браузеру свой TLS-сертификат и обычно промежуточные сертификаты. Браузер строит цепочку до доверенного корневого сертификата. Корень заранее находится в хранилище браузера или операционной системы либо добавлен администратором.
В классической публичной WebPKI центр сертификации, которому доверяет браузер, потенциально способен выпускать сертификаты для огромного пространства доменных имен, если выполнит предусмотренную правилами проверку. Пользователь при посещении сайта не выбирает такой центр. Владелец сайта тоже не определяет весь набор центров, которым доверяет браузер пользователя.
Отсюда рождается системная проблема. Без дополнительных ограничений безопасность условного example.com зависит не только от владельца сайта и выбранного им центра сертификации, но и от множества других доверенных УЦ. Ошибка, компрометация или недобросовестность одного участника способна затронуть чужие домены.
После громких инцидентов отрасль начала переводить ожидания в формальные требования. С 2012 года действует общий набор Baseline Requirements CA/Browser Forum. Сейчас документ регулирует проверку доменов, выпуск и отзыв сертификатов, криптографию, аудит, CAA, многоточечную проверку и множество операционных процедур. Актуальную редакцию имеет смысл проверять непосредственно в Baseline Requirements, поскольку правила меняются довольно быстро.
Здесь легко ошибиться в устройстве отрасли. CA/Browser Forum не является государственным или наднациональным регулятором и сам по себе никому не приказывает доверять сертификатам. Google, Mozilla, Apple и Microsoft ведут собственные программы доверенных корней и могут устанавливать требования строже общего отраслевого минимума. Корень может успешно пройти аудит и все равно лишиться доверия конкретного браузера.
Проверить цепочку своего сайта можно без специализированного сканера.
openssl s_client -connect example.com:443 -servername example.com -showcertsЕсли нужен только конечный сертификат с основными полями, удобнее сократить вывод.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -serial -fingerprint -sha256CAA для домена можно посмотреть через DNS.
dig CAA example.com +shortВ Windows ту же проверку можно выполнить из PowerShell.
Resolve-DnsName example.com -Type CAAДисклеймер. Команды предназначены для диагностики собственной инфраструктуры и анализа публичных данных. При тестировании чужих систем нужно соблюдать законодательство своей страны, включая требования России, правила сервисов и явно разрешенные границы работ. Проверка сертификатов не дает разрешения на перехват трафика, несанкционированный доступ или вмешательство в чужую инфраструктуру.
Certificate Transparency изменила не сертификаты, а видимость
Одной публикации правил оказалось мало. Центр мог нарушить правила, а владелец домена иногда узнавал о сертификате только после атаки. Certificate Transparency поменяла модель наблюдения.
Идея CT появилась в стандартизованном виде в RFC 6962 в 2013 году. Центры начали отправлять сведения о сертификатах в публичные журналы. Журнал построен как структура только для добавления записей и использует дерево Меркла. Благодаря хешам можно доказать, что конкретная запись действительно входит в журнал, а новое состояние журнала продолжает старое без незаметного удаления прежних данных.
При типичном выпуске центр сначала формирует предварительный сертификат, отправляет его в журналы CT и получает подписанные временные метки SCT. Браузер затем проверяет наличие достаточных доказательств публикации по собственной политике. Детали доставки SCT зависят от схемы выпуска и клиента.
С техническими стандартами есть любопытный нюанс. RFC 9162 заменил исходный RFC 6962 и описывает Certificate Transparency версии 2, однако реальная браузерная экосистема не переключилась одномоментно на новый протокол. Значительная часть развернутых механизмов и политик выросла из CT v1. Поэтому фраза «современные браузеры работают по RFC 9162» была бы слишком грубым упрощением.
Пользу CT лучше всего показывает история Symantec. В 2015 году Google обнаружил в журнале CT выпущенный инфраструктурой Symantec EV-precertificate для google.com, который компания Google не заказывала. Похожие тестовые сертификаты нашли и для других организаций, включая Opera. Важно не смешивать два события. Полное прекращение доверия Chrome к старой PKI Symantec произошло не из-за одного сертификата Google. Отдельное расследование 2017 года выявило более широкий набор проблем с выпуском и контролем, после чего Chrome постепенно отказался от старой инфраструктуры Symantec.
Другой показательный случай произошел с WoSign и StartCom. Расследование Mozilla и Google установило, что WoSign выпускала сертификаты с измененными датами, обходя ограничения на новые SHA-1-сертификаты, а также не раскрыла получение контроля над StartCom. Здесь проблема лежала уже не в криптографии. Под вопросом оказались процедуры, раскрытие информации и способность руководства выполнять правила программы доверия. Новые сертификаты обеих компаний браузеры перестали принимать.
CT постепенно превратилась из инструмента исследователей в условие нормальной работы публичного HTTPS. Chrome требует соответствия своей политике CT для новых публичных TLS-сертификатов с 2018 года. Firefox на настольных системах ввел обязательную проверку Certificate Transparency для сертификатов из Mozilla Root CA Program начиная с Firefox 135. У Apple действует собственная политика CT.
Но CT не блокирует неправильный выпуск сама по себе. Если злоумышленник сумел пройти проверку центра и получил действительный сертификат, запись в журнале не уничтожит сертификат магическим образом. CT позволяет быстро увидеть выпуск и расследовать причину. Поэтому мониторинг журналов для собственных доменов полезнее периодической ручной проверки раз в несколько месяцев.
У прозрачности есть побочный эффект. Имя, попавшее в публично доверенный сертификат, следует считать публичным. Если администратор выпустил сертификат для secret-project.example.com, сторонний наблюдатель может обнаружить такое имя через данные CT. Публичный сертификат плохо подходит для попытки скрыть существование внутреннего сервиса.
Следующий этап WebPKI защищает уже саму проверку домена
Certificate Transparency хорошо отвечает на вопрос «что выпустили», но слабее отвечает на вопрос «почему центр решил, что заявитель владеет доменом». Именно здесь появился следующий класс атак.
В августе 2022 года атакующий перехватил маршрутизацию к части инфраструктуры Celer Bridge через BGP hijacking. Перенаправленного сетевого трафика хватило не только для подмены сервиса. Злоумышленник получил действительный TLS-сертификат для целевого поддомена. Браузер видел нормальную криптографическую цепочку и не обязан был показывать предупреждение о сертификате. Атака продолжалась около трех часов и затронула пользователей криптовалютного моста.
Случай особенно интересен тем, что злоумышленник не ломал алгоритм подписи и не крал корневой ключ УЦ. Атакующий вмешался в сетевую картину, которую видел центр во время проверки владения доменом. Если проверять домен из одной точки Интернета, временный перехват маршрута способен превратить ложь в правдоподобный ответ.
Отсюда выросла Multi-Perspective Issuance Corroboration, или MPIC. Центр должен подтверждать результат проверки из нескольких удаленных сетевых точек. С 15 июня 2026 года Baseline Requirements требуют как минимум четыре удаленные сетевые перспективы, а подтверждающие точки должны охватывать регионы как минимум двух разных региональных интернет-регистраторов. Если кворум не выполняется, центр не должен выпускать сертификат. С 15 декабря 2026 года минимум вырастет до пяти удаленных перспектив.
Другими словами, одного успешного ответа из одной сети больше недостаточно. Чтобы обмануть современную процедуру, атакующему приходится влиять на наблюдение сразу из нескольких географически и сетево разнесенных точек. MPIC не делает BGP безопасным, но сильно уменьшает полезность локального перехвата маршрута при выпуске сертификата.
Одновременно ужесточилась работа с DNS. С 15 марта 2026 года основная точка проверки центра должна выполнять DNSSEC-валидацию до корневого якоря IANA для DNS-запросов, связанных с подтверждением контроля над доменом. Аналогичное требование действует для CAA-проверок, а ошибка DNSSEC не может трактоваться как разрешение выпустить сертификат.
CAA закрывает еще одну часть модели. Владелец домена может через DNS указать, каким центрам разрешено выпускать сертификаты для домена. Перед выпуском публичного сертификата центр обязан обработать CAA.
Но браузер не использует CAA как обычную часть проверки уже полученного сертификата. Запись предназначена прежде всего для процедуры выдачи. CAA также не защищает от ошибки центра, которому владелец сам разрешил выпуск. Поэтому CAA, CT и MPIC решают разные задачи и не заменяют друг друга.
Публичность оказалась полезнее обещания «просто доверяйте нам»
Еще один слой современной WebPKI почти не заметен обычному пользователю. В 2017 году появилась общая база CCADB, которую совместно используют операторы публичных корневых хранилищ. Текущая политика CCADB требует от владельцев УЦ раскрывать сведения о корневых и промежуточных сертификатах, публиковать документы CP/CPS, поддерживать данные об аудитах и сообщать об инцидентах. Оператор root-программы при этом вправе установить дополнительные требования или вообще убрать проблемный корень.
Публичный разбор инцидентов превратился в реальный механизм санкций. История не закончилась на DigiNotar, Symantec и WoSign. В 2024 году Chrome объявил о прекращении доверия к новым TLS-сертификатам Entrust из затронутых корневых иерархий после многолетней серии проблем с соблюдением требований и реакцией на инциденты. Подобные решения показывают, что аудит и известный бренд не дают центру пожизненного места в браузере.
Параллельно индустрия сокращает время, в течение которого ошибка может жить незамеченной. Для публичных TLS-сертификатов, выпущенных с 15 марта 2026 года, Baseline Requirements ограничивают максимальный срок действия 200 днями. С 15 марта 2027 года предел снизится до 100 дней, а с 15 марта 2029 года до 47 дней. Максимальный срок повторного использования результатов проверки домена сократится еще сильнее, с нынешних 200 дней до 100, а затем до 10 дней.
Конкретный УЦ вправе выпускать сертификаты еще короче установленного максимума. Практический смысл тенденции очевиден. Ручная схема «раз в год вспомнить про сертификат и продлить его» уходит окончательно. ACME и другая автоматизация жизненного цикла TLS становятся не удобством, а нормальным способом эксплуатации.
Для собственного сайта я бы проверил пять вещей. Кто фактически выпускает сертификаты, какие корни видят основные браузеры, что разрешает CAA, появляются ли неожиданные записи в CT и умеет ли инфраструктура полностью автоматически перевыпустить и установить сертификат. Отдельная проблема возникает у российских доменов и организаций, где техническое доверие браузера, политика конкретного УЦ и возможность заказать сертификат представляют три разных вопроса. Такой сценарий подробно разобран в материале SecurityLab.
При этом публичная WebPKI не стала децентрализованной системой без хозяев. Google, Mozilla, Apple и Microsoft по-прежнему обладают огромной властью, поскольку решают, каким корням доверяют их продукты. Изменилась подотчетность. Правила опубликованы, нарушения обсуждаются публично, выпуск сертификатов виден наблюдателям, а решение браузера можно связать с конкретной историей инцидентов.
Не охватывает публичная модель и все частные PKI. Компания может установить свой корневой сертификат на управляемые устройства и строить внутренние цепочки доверия. Такой локально доверенный корень живет по политике организации и не обязан превращать внутренние сертификаты в участников публичной WebPKI. По той же причине корпоративный шлюз с административно установленным корнем способен выпускать локально доверенные сертификаты для контролируемых устройств.
Наконец, HTTPS по-прежнему не означает «сайту можно верить». Сертификат подтверждает криптографическую связь с именем, прошедшим предусмотренную процедуру проверки, а не честность магазина, безопасность программы или добросовестность владельца ресурса.
Поэтому я бы не называл историю WebPKI победой криптографии над проблемой доверия. Криптография здесь давно была сильной стороной. Слабым местом оставались люди, центры сертификации, процессы проверки, маршрутизация и непрозрачные решения. Индустрия ответила не одним новым алгоритмом, а системой взаимного контроля. Certificate Transparency показывает, что выпустили. CAA ограничивает, кто вправе выпускать. MPIC усложняет обман проверки домена. CCADB и публичные root-программы позволяют следить за теми, кому браузеры дали огромные полномочия.
WebPKI все еще требует доверия. Теперь доверие гораздо труднее получить навсегда, гораздо проще проверить со стороны и, если правила нарушены, можно отозвать публично. Именно такой сдвиг оказался важнее любого значка замка в адресной строке.
