Чтение — не доверие

Статья об анатомии заканчивается на пункте, который стоит повторить: декодирование сертификата говорит вам, что он утверждает, а не истинно ли утверждение. Проверка — это отдельный процесс, который клиент TLS выполняет, чтобы решить, доверять ли сертификату перед собой. Она управляется главным образом RFC 5280 и является конъюнкцией независимых проверок, каждая из которых должна пройти. Декодировщик, включая этот инструмент, показывает вам входные данные этого процесса; клиент — это то, что его применяет.

Шаг 1: построить цепочку

Листовому сертификату почти никогда не доверяют самому по себе. Клиент должен построить путь от листа вверх до корня, который он уже держит в своём хранилище доверия. Он делает это, следуя по именам издателей: Issuer листа должен совпасть с Subject некоторого промежуточного, а Issuer того промежуточного должен совпасть со следующим вверх, пока не достигнет самовыпущенного корня. Расширения Authority Key Identifier и Subject Key Identifier ускоряют это сопоставление, позволяя клиенту связать сертификат с его издателем по хешу ключа, а не только по имени. Если никакого пути к доверенному корню построить нельзя, проверка проваливается немедленно, как бы хорошо сформирован ни был лист.

Шаг 2: проверить каждую подпись

Цепочка значима лишь тогда, когда каждое звено криптографически прочно. Для каждого сертификата на пути клиент проверяет, что подпись была произведена приватным ключом издателя, сверяя её с открытым ключом издателя над байтами подлежащего-подписи тела потомка. Поскольку подпись покрывает ровно эти байты, единственный изменённый байт где угодно в теле ломает проверку. Это также почему алгоритм подписи (например, sha256WithRSAEncryption или ecdsa-with-SHA256) важен: цепочка лишь настолько прочна, насколько прочны её слабейшие подпись и хеш. О том, что хеш гарантирует здесь, см. статью о хешировании.

Шаг 3: проверить окно действия

Каждый сертификат несёт метки времени notBefore и notAfter, и клиент проверяет текущее время против окна для каждого сертификата в цепочке, не только листа. Сертификат, который истёк или ещё не действителен, проваливается. Инструмент выполняет эту же проверку против ваших локальных часов и сообщает, действителен ли сертификат сейчас, ещё не действителен или истёк, что часто самый быстрый способ диагностировать предупреждение «ваше соединение не защищено».

Шаг 4: сопоставить имя

Действительная цепочка доказывает, что сертификат подлинный, но не что он был выпущен для сайта, который вы посещаете. Клиент проверяет, что хост, к которому он подключился, появляется в расширении Subject Alternative Name сертификата. Современные клиенты полностью игнорируют Common Name для этой цели и смотрят лишь на , следуя правилам сопоставления идентичности RFC 6125. Подстановочные знаки вроде *.ronutz.com совпадают с одной меткой, так что они покрывают api.ronutz.com, но не сам ronutz.com и не a.b.ronutz.com. Сертификат, чья цепочка безупречна, но чей SAN не перечисляет имя, которое вы запросили, всё равно отклоняется.

Шаг 5: применить ограничения

Расширения v3 — не украшение; это правила, которые клиент применяет. Basic Constraints говорит, может ли сертификат действовать как , и, через длину пути, сколько промежуточных может сидеть под ним, что и останавливает использование листового сертификата для подписи других сертификатов. Key Usage и Extended Key Usage ограничивают то, что ключу позволено делать: сертификат сервера TLS должен нести EKU serverAuth, а расширение, помеченное критическим, которое клиент не понимает, вынуждает отклонение, а не пожатие плечами. Инструмент выводит эти поля на поверхность, чтобы вы могли увидеть в точности, какие ограничения установил издатель.

Шаг 6: проверить отзыв

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

Проверка — это AND, а не OR

Причина, по которой единственный подделанный или неправильно настроенный сертификат получает отклонение, в том, что все эти проверки комбинируются логическим AND. Цепочка должна построиться, каждая подпись должна проверяться, каждый сертификат должен быть в своём окне действия, имя должно быть в SAN, ограничения должны разрешать использование, и сертификат не должен быть отозван. Декодировщик излагает утверждения сертификата ясно и точно; относитесь к этому как к внимательному прочтению документа, и помните, что вердикт принадлежит клиенту, который выполняет все шесть проверок.