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

И, конечно, в истории WebPKI были серьёзные инциденты безопасности, которые показали: правила доверия должны быть публичными, прозрачными и проверяемыми.

Однако один вопрос не решается автоматически: кому браузер должен доверять и на каких условиях. Каждый вендор определяет это сам. Поэтому мы открываем Yandex Browser Root Certificate Program — публичную программу добавления корневых сертификатов в хранилище Яндекс Браузера. В ней описаны требования к участникам, аудит и понятная процедура подачи заявки.

Под катом рассказываем, какие требования нужно выполнить и как в Браузере устроены WebPKI и связанные с ними контроли безопасности.

Как Яндекс Браузер решает, какому сертификату доверять

Хранилище корневых сертификатов — ключевой компонент любого браузера: оно задаёт модель доверия веб‑ресурсам и напрямую влияет на безопасность пользователей. Как и любой другой chromium‑based‑браузер, Яндекс Браузер использует собственное внутреннее хранилище. Оно не связано с хранилищем операционной системы и переиспользует текущий список доверенных сертификатов от Chromium. К тому же пару лет назад мы добавили сертификат Национального удостоверяющего центра (НУЦ). 

Механизмы проверки корректности сертификатов у нас тоже стандартные. От chromium‑based они отличаются только одним: там, где переиспользовать инфраструктуру Chromium или общую инфраструктуру экосистемы WebPKI не получается, мы реализуем и поддерживаем собственные решения.

Главное из таких решений — отдельные CT‑логи. Сейчас в рунете их три (и один из них наш). Так же как и любой другой CT‑лог, они позволяют увидеть сертификаты, которым доверяет Яндекс Браузер, и домены, для которых сертификаты были выписаны. Технически эти CT‑логи имеют такой же API и такие же возможности, как и любой лог в экосистеме WebPKI. Ниже за спойлером можно увидеть пример обращения к яндексовому CT‑логу с помощью стандартной библиотеки от Google. 

$ git clone https://github.com/google/certificate-transparency-go
$ cd certificate-transparency-go
$ go run ./client/ctclient/ get-sth --log_uri https://ct-agate.yandex.net/2026/ 
2026-08-11 00:02:05.135 +0300 MSK (timestamp 1786395725135): Got STH for V1 log (size=8464) at https://ct-agate.yandex.net/2026, hash db652655b090f6bbe792d82684f4d0fc763705e171e0085730bd1eb0f0de5b26
Signature: Hash=SHA256 Sign=ECDSA Value=3045022100cbaaba435df7fc97067052e7e12690307d09a4b8afb3c5b155cbfa493bee00f5022079fdcd0f2d3f26291f1c871ff9bea083bebb65c26e458e37211ff4838e79b5ca
$ go run ./client/ctclient/ get-entries --log_uri https://ct-agate.yandex.net/2026/ --first=0 --last=1 
Index=0 Timestamp=1735722581122 (2025-01-01 12:09:41.122 +0300 MSK) pre-certificate from issuer with keyhash 6f01ed8ce6183326e9cc1040c77fb44ae407125dc195754ca0f1aaaf39e05ad4:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 382368305283349880911553499 (0x13c49a35d27ec47d905e3db)
    Signature Algorithm: ECDSA-SHA256
        Issuer: CN=TCI ECDSA B1 13-240
        Validity:
            Not Before: 2025-01-01 09:09:12 +0000 UTC
            Not After : 2026-01-01 09:09:12 +0000 UTC
        Subject: CN=khaos.today
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
...
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web server authentication, TLS Web client authentication
            X509v3 Basic Constraints: critical
                CA:false
            X509v3 Subject Alternative Name:
                DNS:khaos.today, DNS:www.khaos.today
            X509v3 CRL Distribution Points:
                Full Name:
                    URI:http://ca.cstls.ru/ecdsa-13-240.crl
            Authority Information Access:
                CA Issuers - URI:http://ca.cstls.ru/ecdsa-13-240.cer
            RFC6962 Pre-Certificate Poison: critical
                .....
Index=1 Timestamp=1736427061888 (2025-01-09 15:51:01.888 +0300 MSK) pre-certificate from issuer with keyhash 0447aa4b18c48b9e8db16e91809286dd27efd6a50ba80d3084eb9e70ba8e1dca:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 32031425592278157235589932136097 (0x1944b1e3e0bc9c658c2958c36a1)
    Signature Algorithm: SHA256-RSA
        Issuer: C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA
        Validity:
            Not Before: 2025-01-09 12:51:00 +0000 UTC
            Not After : 2026-01-09 12:51:00 +0000 UTC
        Subject: C=RU, O=ООО Тайгерсофт, L=Санкт-Петербург, ST=Санкт-Петербург, CN=*.tigersoft.ru
       ...
            X509v3 Basic Constraints:
                CA:false
            X509v3 Subject Alternative Name:
                DNS:tigersoft.ru, DNS:www.tigersoft.ru, DNS:pop.tigersoft.ru, DNS:smtp.tigersoft.ru, DNS:imap.tigersoft.ru, DNS:mail.tigersoft.ru, DNS:*.tigersoft.ru
            X509v3 CRL Distribution Points:
                Full Name:
                    URI:http://rostelecom.ru/cdp/subca_ssl_rsa2022.crl, URI:http://company.rt.ru/cdp/subca_ssl_rsa2022.crl, URI:http://reestr-pki.ru/cdp/subca_ssl_rsa2022.crl
            Authority Information Access:
                CA Issuers - 
URI:http://rostelecom.ru/cdp/subca_ssl_rsa2022.crt, URI:http://company.rt.ru/cdp/subca_ssl_rsa2022.crt, URI:http://reestr-pki.ru/cdp/subca_ssl_rsa2022.crt
            RFC6962 Pre-Certificate Poison: critical
                .....

Контроль выпуска: без двух SCT‑меток сертификат невалиден

Концептуально процесс выпуска и проверки сертификата у нас ничем не отличается от процесса в других браузерах — он подробно описан в документации Certificate Transparency. Разница появляется на стороне удостоверяющих центров, которые не входят в список Chromium: они взаимодействуют с другими CT‑логами. Добавляя туда сертификат, центр получает Signed Certificate Timestamp (SCT) — подписанную метку времени, которая вшивается в сертификат, а браузер использует её при проверке валидности. Валидным клиент считает только сертификат с двумя SCT‑метками из разных логов.

Координаты CT‑логов, которым мы доверяем, открыты: browser‑resources.s3.yandex.net/ctlog/ctlog.json. Для работы с логами и их анализа достаточно любого OSS‑клиента для CT‑логов либо можно использовать панель Вебмастера. Также возможно просто обратиться к API CT‑лога через браузер, открыв в адресной строке ссылку вида https://ct‑agate.yandex.net/2026/ct/v1/get‑entries?start=0&end=10.

Так проверить, для каких доменов выпускались сертификаты, которым доверяет Яндекс Браузер, может любой желающий, не только мы.

Контроль отзыва: CRLSets и компонентные обновления

Как и Chromium, Яндекс Браузер использует технологию CRLSets — способ собрать информацию об отозванных сертификатах и доставить её в браузер отдельным обновлением. В мире chromium‑based‑браузеров такое обновление называется компонентным: список установленных компонентов и их версии видны на странице browser://components.

Всё, что описано выше, — контроль выпуска через CT‑логи и контроль отзыва через CRLSets — работает одинаково для любого корневого сертификата в хранилище независимо от того, кто его выпустил. Это и делает расширение хранилища управляемым: доверие к новому участнику не приходится выдавать на честное слово, оно остаётся проверяемым и отзываемым. Поэтому расширять список полезно: сертификаты отзываются, доступность конкретного центра для конкретного сайта ничем не гарантирована, и запас прочности сайту стоит иметь заранее. 

Помимо сертификатов, отозванных сторонними CA, мы также можем отозвать доверие к отдельным сертификатам или корневому сертификату, если обнаружим их нелегитимное использование.

Как удостоверяющему центру попасть в хранилище

Попасть в хранилище Яндекс Браузера до сих пор можно было только точечно: в 2022 году мы добавили сертификат Национального удостоверяющего центра, чтобы помочь пользователям сохранить доступ к популярным сайтам, но публичной процедуры, списка требований и адреса для заявки не существовало. 

С сегодняшнего дня в Яндексе начала работу публичная программа для удостоверяющих центров и других организаций, желающих добавить свои корневые сертификаты в хранилище Яндекс Браузера — Yandex Browser Root Certificate Program. 

Программа устроена по тому же принципу, по которому работают аналогичные программы в других браузерах — Google Chrome, Mozilla Firefox или Apple Safari: требования опубликованы заранее, заявка рассматривается по ним, а доверие поддерживается непрерывным аудитом и публичной отчётностью об инцидентах, а не выдаётся один раз при включении сертификата в хранилище. Ту же логику мы закладываем в свою программу.

Вот наши ключевые требования к участникам:

• выполнение и подтверждение выполнения базовых требований CA / Browser Forum;

• поставка данных о выпущенных сертификатах в два независимых CT‑лога, один из которых — CT‑лог Яндекса;

• подтверждённые результаты внешнего аудита безопасности по согласованному скоупу;

• предоставление информации об отозванных сертификатах: команда Яндекс Браузера использует эти данные, чтобы формировать и раздавать CRLSet‑обновления, то есть прекращать доверие к отозванным сертификатам;

• оперативные сообщения об инцидентах безопасности, которые повлияли или могли повлиять на выпуск сертификатов;

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

В Yandex Browser Root Certificate Program уже есть первый участник — ТЦИ. 

ТЦИ является техническим оператором национальных доменных зон верхнего уровня ‑.ru,.рф,.su, поддерживает DNS‑инфраструктуру этих зон, а также взаимодействует и обслуживает запросы доменных регистраторов в этих зонах. Команда ТЦИ ранее была активным участником наших инициатив по безопасности WebPKI: например, коллеги добровольно начали поставлять данные в наши CT‑логи ещё несколько лет назад.

Финальное решение о включении удостоверяющего центра в хранилище и об исключении из него принимает Яндекс. Здесь мы не отличаемся от Google или Mozilla, разве что у других вендоров есть этап публичного обсуждения заявки, а у нас его пока нет — вместо этого публичны сами правила и открыта подача заявок.

Что происходит, если участник нарушил правила

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

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

Процедура прекращения доверия запускается в течение одного рабочего дня. Причин для запуска процедуры четыре: нарушение правил программы, инцидент информационной безопасности, признаки недобросовестного выпуска сертификатов и запрос самого участника.

Одно из ключевых свойств экосистемы WebPKI — прозрачность. Запуская эту программу, мы хотели ещё раз подтвердить наше стремление делать апдейты Браузера, связанные с безопасностью пользователей и индустрии, прозрачными и мотивированными. 

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

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

Заявки на добавление корневых сертификатов в доверенные принимаем на browser‑cert‑store‑program@yandex‑team.ru.