Сертификаты удостоверяющих центров TLS

Автор статьи: Александр Венедюхин, ведущий аналитик ТЦИ

Когда в контексте TLS говорят о сертификатах Удостоверяющего Центра (УЦ), то обычно можно услышать слово «корневые», несколько реже - слово «промежуточные». И корневые, и промежуточные сертификаты УЦ важны, но они играют разные роли, особенно в практике TLS, ведь из-за наличия различных ролей, как административных, так и технических, подобное разделение и возникло.

TLS-сертификат – это электронный документ (проще говоря, файл особого формата), который позволяет привязать криптографический ключ к некоторому имени. TLS-сертификаты используются при аутентификации узлов. Обычно – для аутентификации сервера клиентом. Сертификаты удостоверяющих центров связаны с ключами, которые используются при подписывании других сертификатов, — в этом их основная особенность, которая в самом сертификате закрепляется значением специальных флагов. То есть сертификаты УЦ и «обычные» сертификаты, — например, сертификаты TLS-узлов, — отличаются значением нескольких полей данных, а в остальном устроены одинаково.

Кстати, сейчас удостоверяющие центры TLS нередко называют Центрами Сертификации (ЦС). Это обозначение в чём-то точнее, — например, соответствующая роль как раз сводится к выдаче сертификатов после успешной проверки, то есть к сертификации, — а в чём-то расходится с традиционным для русскоязычной специальной литературы обозначением. Тем не менее на сами сертификаты терминология никак не влияет. С технической точки зрения термины являются синонимами, а отличия возникают из административных и юридических аспектов. В этой статье будем использовать более привычное обозначение – УЦ.

Вернёмся к самим сертификатам. Почему один и тот же УЦ использует разные сертификаты, которые ещё и образуют иерархию? Это связано с практикой управления ключами и принципами современной инфраструктуры TLS. Сертификат привязывает имя к ключу. Внутри сертификата это «привязывание» осуществляется с использованием электронной подписи. То есть сертификат содержит имя (чаще – несколько имён), значение криптографического ключа (это открытый, публичный ключ) и значение электронной подписи. Это, конечно, кроме набора других разнообразных полей данных, среди которых и поля с именами, соответствующими ключам. Важное, для практики УЦ, замечание: подпись на сертификате может быть получена как от того же ключа, открытая часть которого указана в данном сертификате (самоподписанный сертификат), так и от другого ключа. В корректном самоподписанном сертификате должны совпадать и имена в полях, которые обозначают сторону, поставившую подпись (Issuer), и сторону, обладающую соответствующим секретным ключом (Subject). При этом случай, когда подпись вычисляется от другого ключа, составляет основную часть деятельности УЦ по выпуску сертификатов.

Вообще термин «самоподписанный» часто трактуют как «выпущенный самостоятельно», тем более, что подобные самоподписанные сертификаты иногда генерируются автоматически в разных ситуациях, связанных с установкой серверных программных пакетов. Такой самоподписанный сертификат принято считать образцом «неправильного», «ненадёжного» сертификата. Как ни странно, но самоподписанные сертификаты имеют первоочередное значение для доверия УЦ. Тут всё дело в ключе: корневой сертификат УЦ обязательно является самоподписанным. Корневой ключ – он на то и корневой, что находится на вершине иерархии доверия, поэтому никаких других ключей, подписывающих сертификат с корневым ключом, быть не может по определению (да, бывают конфигурации с так называемой «кросс-подписью», но там корневым становится другой ключ.).

То есть корневой сертификат УЦ – это самоподписанный сертификат, который содержит основной ключ УЦ. Фактически, это контейнер с корневым ключом. Именно он встраивается в дистрибутивы программного обеспечения, например, в браузеры, но только как носитель корневого ключа. При этом алгоритмы валидации цепочек сертификатов (в тех же браузерах и в случае корневых ключей) «доверяют» именно ключу, а не сертификату с этим ключом: для браузера, при встраивании в список доверенных корней, важно именно значение ключа, а не другие параметры сертификата, так что к подписям в корневых сертификатах отношение не самое строгое. Например, когда некоторое время назад хеш-функцию SHA-1 признали нестойкой, это не привело к моментальному отказу от корневых сертификатов, использующих данную хеш-функцию в составе криптосистемы электронной подписи. Причина как раз в том, что в корневом сертификате браузер доверяет не подписи, а открытому ключу в паре с именем удостоверяющего центра, которое указано в сертификате, так что использованием SHA-1 в корневом сертификате можно пренебречь, оно никак не влияет на уровень доверия.

Параметр или флаг, делающий сертификат сертификатом УЦ, позволяет этому сертификату входить в цепочку валидации, то есть предоставлять исходные данные для проверки подписи на других сертификатах, находящихся уровнем ниже. Типичный сценарий для веба, для HTTPS/TLS: на одном конце цепочки находится так называемый оконечный сертификат, то есть сертификат сервера, подпись на котором вычислена от ключа, указанного в соответствующем сертификате УЦ. Однако данный сертификат УЦ не является корневым — он называется «промежуточным». При этом строгое соответствие сертификатов устанавливается не только по ключам (через подпись), но и по именам, которые указаны в каждом сертификате цепочки. Так, оконечный сертификат содержит в поле Subject имя домена, под которым доступен сервер, а поле Issuer указывает на имя УЦ, подписавшего данный сертификат. В вышестоящем сертификате УЦ совпадающее имя уже должно быть в поле Subject. Если это сертификат промежуточного УЦ, то поле Issuer в нём будет указывать на следующий УЦ в цепочке. Промежуточных сертификатов может быть несколько. Валидная цепочка приводит к корневому сертификату УЦ.

Когда-то давно УЦ в TLS (тогда ещё SSL) выпускали оконечные сертификаты непосредственно от корневого ключа. Сейчас практика другая: от корневого ключа выпускаются несколько промежуточных сертификатов УЦ, которые уже используются при выпуске оконечных. Эти промежуточные сертификаты не являются самоподписанными, но содержат набор флагов, придающих статус сертификата удостоверяющего центра. Это, прежде всего, позволяет снизить частоту использования секретного корневого ключа. Фактически корневой ключ нужен лишь при выпуске промежуточных сертификатов и при их отзыве, то есть ключ может находиться в офлайн-режиме. Чем меньше используется секретный ключ, тем лучше с точки зрения безопасности, так как минимизируется количество операций доступа к секретному ключу и количество вычисленных подписей. При этом промежуточные сертификаты могут быть выпущены на относительно короткий срок, что, опять же, снижает риски. Типичные показатели: срок действия десять лет для корневого ключа и два-три года для промежуточного. Современная тенденция – уменьшение срока валидности сертификатов УЦ.

В TLS промежуточные сертификаты должны передаваться вместе с оконечными, однако на тот случай, когда этого не происходит, выработано несколько полезных вспомогательных инструментов. В основном это инструменты для веба. Так, браузеры кешируют валидные промежуточные сертификаты, которые встретили во время доступа к сайтам. Это означает, что если сервер не прислал нужный для построения цепочки промежуточный сертификат, то браузер использует ранее сохранённый в кеше подходящий сертификат – в противном случае произошла бы ошибка валидации. Это одна из причин того, что процесс валидации конкретного сертификата может в деталях отличаться для разных экземпляров одного и того же браузера. Список некоторых промежуточных сертификатов может быть включен в дистрибутив браузера (наравне с корневыми), но это никак не отменяет того, что другие промежуточные сертификаты могут поступать с серверов. С промежуточными сертификатами в TLS для веба связана и весьма распространённая ошибка настройки сервера: администратор забывает включить промежуточный сертификат в цепочку, возвращаемую сервером. Получается, что в каких-то браузерах веб-сайт доступен, а в других — выдаётся предупреждение системы безопасности.

Посмотреть корневые и промежуточные сертификаты удостоверяющего центра можно на примере Центра сертификации ТЦИ – там они выложены в личном кабинете пользователя в разделе «Сертификаты ЦС» и на странице TLS-сертификата, выпустить который можно также через личный кабинет. Помимо этого, корневые сертификаты доступны по следующим ссылкам: ECDSA, ГОСТ.