bitlvl
RU

Декодер SSL-сертификатов и CSR

Вставьте один или несколько блоков PEM. Каждый сертификат декодируется как openssl x509 -text, с указанием проблем, на которые пожаловались бы браузеры. Закрытые ключи отклоняются и никогда не требуются.

Получите свой командой: openssl s_client -connect example.com:443 -showcerts </dev/null

Результаты и сообщения этого инструмента выводятся на английском языке.

Что содержится в сертификате

Сертификат X.509 связывает открытый ключ с именем и подписан издателем. Поля, которые имеют значение, когда что-то не работает:

  • Subject Alternative Name: список имён хостов (и IP), для которых сертификат действителен. Браузеры полностью игнорируют Common Name; сертификат без имени хоста в SAN завершается ошибкой NET::ERR_CERT_COMMON_NAME_INVALID независимо от того, что указано в CN.
  • Срок действия: notBefore и notAfter. Публично доверенные конечные сертификаты могут действовать не более 398 дней (с сокращением до 47 дней к 2029 году); Let’s Encrypt выпускает 90-дневные сертификаты.
  • Issuer и цепочка: сервер должен отправлять свой конечный сертификат плюс каждый промежуточный вплоть до (но не включая) корневого, которому доверяет клиент. «Unable to get local issuer certificate» почти всегда означает отсутствующий промежуточный сертификат.
  • Key usage / extended key usage: серверному сертификату нужен TLS server auth; CA нужны keyCertSign и CA:TRUE в basic constraints.
  • Authority Information Access: откуда загрузить сертификат издателя и адрес OCSP-респондера; CRL distribution points: где находятся списки отзыва.
  • Алгоритм подписи: сегодня sha256WithRSA, ecdsa-with-SHA256 или Ed25519; подписи SHA-1 отклоняются повсеместно.

Отпечатки

Отпечаток SHA-256 — это хеш всего сертификата в DER-кодировке, используемый для пиннинга и для сравнения того, что отправляет сервер, с тем, что вы ожидаете (openssl x509 -fingerprint -sha256). Он меняется при каждом обновлении, поэтому пиннинг конечных сертификатов хрупок; вместо этого пинните открытый ключ (SPKI) или промежуточный сертификат.

CSR

Запрос на подпись сертификата содержит subject, открытый ключ и запрашиваемые расширения, подписанные соответствующим закрытым ключом для доказательства владения. CA копируют SAN из запроса (или из проверенных доменов) и игнорируют почти всё остальное. Проверка CSR перед отправкой экономит лишний цикл, когда SAN неверен.

Как получить PEM

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509   # только конечный
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | sed -n '/BEGIN/,/END/p'                   # вся цепочка
openssl x509 -in cert.der -inform der -out cert.pem                                                                        # DER → PEM

Вопросы

Можно ли вставить файл .crt, .cer или .der?

Вставляйте текст PEM-файлов (.pem, .crt, .cer, если они начинаются с -----BEGIN). Бинарный DER сначала нужно сконвертировать: openssl x509 -inform der -in file -out file.pem. Сырой Base64 DER-сертификата без строк BEGIN/END тоже принимается.

Почему декодер говорит, что CN нет в SAN?

Браузеры проверяют только SAN. Сертификат с CN=example.com, но SAN=www.example.com не будет работать для example.com. Перевыпустите его с каждым именем хоста в SAN.

Что здесь означает «самоподписанный»?

Issuer и subject идентичны. Это нормально для корневого CA и сертификатов для разработки, но самоподписанный конечный сертификат будет отклонён браузерами, если он не установлен как доверенный.

Мой сертификат отправляется на сервер?

Нет. Декодирование использует парсер ASN.1, написанный на JavaScript, и выполняется в вашем браузере. Тем не менее закрытые ключи отклоняются сразу; сертификат публичен по своей природе, ключ — никогда.