Что браузер проверяет в TLS-сертификате
Название «SSL-сертификат» пережило сам протокол SSL. Современный браузер устанавливает соединение по TLS, а сервер подтверждает свою личность сертификатом X.509. Сертификат не делает сайт честным и не шифрует весь трафик в одиночку: во время TLS-рукопожатия он помогает связать имя сервера с открытым ключом, после чего стороны договариваются о сеансовых ключах для быстрой симметричной защиты данных.
Чтобы понять содержимое сертификата, полезно рассматривать его не как набор загадочных полей, а как часть системы. В ней протокол TLS отвечает за защищённый канал, X.509 описывает форму удостоверения, центры сертификации связывают удостоверения в цепочку, а браузер решает, каким корням доверять и совпадает ли имя сайта с именами в сертификате.
От SSL Netscape к TLS
Netscape опубликовала SSL 2.0 в 1995 году, пытаясь защитить данные между браузером и веб-сервером от чтения и подмены по пути. У протокола обнаружились серьёзные недостатки, поэтому уже в 1996 году появился SSL 3.0 с существенно переработанным рукопожатием и криптографической схемой.
Следующий шаг сделала IETF. В январе 1999 года организация выпустила TLS 1.0 в RFC 2246, взяв SSL 3.0 за основу, но изменив его настолько, что два протокола не были совместимы напрямую. Позднее появились TLS 1.1, TLS 1.2 и TLS 1.3. Одновременно старые варианты последовательно выводили из обращения: SSL 2.0 запретили в 2011 году, SSL 3.0 в 2015-м, а TLS 1.0 и 1.1 официально признали устаревшими в 2021-м.
В актуальном TLS 1.3 сервер всегда проходит аутентификацию, а клиент может проходить её при необходимости. Рукопожатие выбирает криптографические параметры, проверяет удостоверение сервера и создаёт общий секрет; прикладные данные затем защищаются ключами, полученными из этого секрета. Поэтому сертификат важен для доверия к ключу и имени сервера, но сводить к нему всю работу TLS было бы неверно.
Как X.509 связал ключ, имя и издателя
Первая редакция X.509 появилась в 1988 году как часть Authentication Framework для каталога X.500, задолго до массового веба. В интернете этот формат получил более узкий профиль PKI, описанный сегодня в RFC 5280. Сертификат хранит серийный номер, сведения о субъекте и издателе, срок действия, открытый ключ, алгоритм подписи и расширения, среди которых находится Subject Alternative Name.
Отпечатки SHA-256 и SHA-1 не являются отдельными полями сертификата. Программа вычисляет их как хэш точного бинарного представления DER, чтобы один и тот же сертификат было удобно узнавать и сравнивать. Наличие SHA-1-отпечатка в декодере также не означает, что сертификат подписан SHA-1 или что этот алгоритм рекомендуется для новых криптографических задач: алгоритм подписи указан в другом поле.
Файл PEM тоже не является особым видом сертификата. Это текстовая оболочка с метками BEGIN CERTIFICATE и END CERTIFICATE, внутри которой находится закодированное в Base64 бинарное представление DER. Такая запись удобна для конфигурационных файлов и копирования, но сама по себе ничего не шифрует. Публичный сертификат можно передавать другим людям, тогда как закрытый ключ публиковать и вставлять в посторонние сервисы нельзя.
Доверие строится как путь, а не как одно поле
Серверный сертификат, который также называют конечным или leaf-сертификатом, обычно подписывает промежуточный центр сертификации. Его сертификат, в свою очередь, ведёт к корневому центру. Сервер передаёт клиенту конечный сертификат и необходимые промежуточные, а браузер пытается построить путь до корня, который уже находится в доверенном хранилище браузера или операционной системы.
Корню доверяют не потому, что он подписал сам себя, а потому, что его заранее включили в локальную программу доверия. При валидации клиент проверяет подписи и ограничения сертификатов по пути, сроки действия и правила применения ключей. Отдельно он сопоставляет имя открытого сайта с идентификаторами в SAN конечного сертификата. Успешное чтение PEM-файла подтверждает лишь то, что структура разобрана; оно ещё не говорит, что такая проверка цепочки завершилась успешно.
Почему имя сервера находится в SAN
Common Name не создавался специально для веб-доменов: это один из атрибутов составного имени субъекта X.509. Ранние HTTPS-клиенты использовали его для имени сервера, однако уже RFC 2818 от 2000 года требовал выбирать dNSName из SAN, если расширение присутствует, и называл возврат к Common Name устаревшей практикой.
Изменение закреплялось постепенно. Вступившие в силу 1 июля 2012 года Baseline Requirements CA/Browser Forum обязали публичные центры сертификации включать SAN в серверные сертификаты. RFC 9525, опубликованный в 2023 году, формулирует современное правило ещё прямее: личность TLS-сервера должна определяться идентификатором из SAN, а Common Name больше не считается подходящей заменой.
В SAN может находиться одно имя, несколько имён, IP-адреса или ограниченный wildcard вроде *.example.com. Само присутствие записи тоже недостаточно, поскольку клиент должен корректно сопоставить её с тем адресом, который открыл пользователь. Например, такой wildcard покрывает www.example.com, но не произвольное количество уровней вложенности.
Let’s Encrypt автоматизировал жизненный цикл сертификата
Internet Security Research Group зарегистрировали в мае 2013 года, Let’s Encrypt публично анонсировали в ноябре 2014-го, а первые сертификаты сервис начал выдавать в 2015-м. Проект создавали не только ради нулевой цены. Его принципиальной целью был автоматический выпуск и продление, чтобы оператору сайта не приходилось вручную заказывать сертификат, подтверждать домен и повторять процедуру перед каждым окончанием срока.
Для этого появился ACME. Клиент создаёт учётную запись и заказ, центр сертификации предлагает проверку контроля над доменом, а клиент отвечает на неё через HTTP или DNS. После успешной проверки он отправляет запрос с открытым ключом, получает сертификат и может заранее повторить тот же цикл для продления. В 2019 году ACME стандартизировали как RFC 8555, поэтому протокол используют не только Let’s Encrypt и не только для одного конкретного клиента.
Цена сертификата действительно перестала быть барьером, однако долговременное влияние Let’s Encrypt шире: короткоживущий сертификат стал частью автоматизированной эксплуатации сервера, а не документом, который администратор вспоминает обновить раз в год.
Что показывает SSL Decoder
SSL & X.509 Decoder работает локально в браузере и разбирает вставленный PEM-сертификат. Он показывает версию X.509, серийный номер, Subject и Issuer, даты начала и окончания действия, алгоритм подписи, сведения об открытом ключе и найденные записи SAN, а также вычисляет SHA-256- и SHA-1-отпечатки бинарного DER.
Инструмент полезен, когда нужно быстро прочитать сертификат из конфигурации, проверить список имён или сравнить отпечаток с опубликованным значением. Для этого достаточно вставить блок от BEGIN CERTIFICATE до END CERTIFICATE; данные никуда не отправляются.
При этом декодер читает только первый сертификат из вставленного блока и не является средством проверки соединения. Он не строит путь до доверенного корня, не проверяет криптографические подписи, отзыв сертификата, правила wildcard, назначение ключа или соответствие SAN конкретному адресу. Индикатор срока ориентируется на дату окончания и не заменяет полную проверку периода действия. Иными словами, инструмент помогает увидеть, что записано внутри сертификата, а окончательный ответ о доверии должен давать TLS-клиент в контексте реального соединения.
Похожие инструменты
Частые вопросы
Чем SSL отличается от TLS?
SSL был ранним протоколом Netscape для защиты соединения. TLS 1.0, опубликованный IETF в 1999 году, опирался на SSL 3.0, но не был с ним полностью совместим. Сегодня защищённые веб-соединения используют TLS, хотя выражения «SSL-сертификат» и «SSL Decoder» по-прежнему встречаются в интерфейсах и документации.
Что такое X.509 и цепочка сертификатов?
X.509 задаёт структуру сертификата, который связывает открытый ключ с именем и издателем. Сертификат сайта обычно подписан промежуточным центром сертификации, тот связан с корневым сертификатом, а корню браузер или операционная система доверяет через локальное хранилище. Проверка подписей и ограничений по этому пути называется валидацией цепочки.
Почему домен указывают в SAN, а не в Common Name?
Common Name является общим атрибутом имени субъекта и когда-то использовался браузерами как запасное место для имени сервера. RFC 2818 ещё в 2000 году предписывал отдавать приоритет dNSName в SAN и называл переход к Common Name устаревшим. В 2012 году требования CA/Browser Forum сделали SAN обязательным для публично доверенных сертификатов, а современный RFC 9525 больше не считает Common Name допустимым идентификатором сервера.
Что изменили Let’s Encrypt и ACME?
Let’s Encrypt сделал общедоступные сертификаты бесплатными, но не менее важной была автоматизация. ACME-клиент может создать заказ, подтвердить контроль над доменом, передать запрос на сертификат, получить его и регулярно повторять процесс для продления. Благодаря этому сертификат перестал быть покупкой и ручной ежегодной процедурой.
Может ли SSL Decoder подтвердить, что сертификату можно доверять?
Нет. Декодер показывает содержимое первого вставленного сертификата и вычисляет его отпечатки, но не строит цепочку до доверенного корня, не проверяет подписи, отзыв, назначение ключа и соответствие SAN запрошенному домену. Даже отметка о сроке основана только на дате окончания действия, поэтому инструмент нужно воспринимать как инспектор структуры, а не как полноценный валидатор TLS-соединения.
Автор
Alex RelFullstack Engineer
В коммерческой разработке с 2011 года — больше 15 лет. Автор двух SaaS-продуктов: TeleGo.io и LingvoHabit.com. Статьи здесь выросли из реальной клиентской и продуктовой работы.
