Сертификаты SSL/TLS — что действительно означают эти поля и даты истечения

В какой-то момент вы смотрели на маленький замок в браузере, нажимали «Просмотр сертификата» и сталкивались с стеной полей, которые кажутся важными, но ничего не объясняют: «Альтернативные имена подлежащего», «OCSP», «SHA-256 с шифрованием RSA». Вы закрываете диалог. Сертификат зелёный. Это достаточно.

До истечения срока. В полночь в пятницу. В производственной среде.

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

Сертификат — это просто подписанное документ.

Уберите ритуалы и сертификат TLS — это текстовый документ, содержащий некоторые факты — кто владеет этим доменом, какую открытую ключевую пару они используют, когда этот документ истекает — который был криптографически подписан сертификатным агентом (CA). Подпись CA — это то, что делает браузеры доверять ему. Всё остальное — это аннотации.

Основной формат называется X.509. Он был определён в 1988 году, несколько раз пересматривался и сейчас описан в RFC 5280. Именно поэтому диалоги с деталями сертификатов в браузерах выглядят так, будто были разработаны людьми, которые считают 1988 год недавним.

Основные поля, объяснённые

Вот аннотированный разбор полей, которые вы увидите в реальном сертификате. Ниже приведён пример сырого PEM-данных (не действующий сертификат):

Certificate:
  Data:
    Version: 3 (0x2)                          # Always v3 for modern certs
    Serial Number:                             # Unique ID issued by the CA
      04:b3:c2:...(truncated)
    Signature Algorithm: sha256WithRSAEncryption  # Hash + key algorithm used to sign
    Issuer:
      C  = US                                 # Country
      O  = Let's Encrypt                      # Organization (the CA)
      CN = R11                                # Common Name of the issuer
    Validity:
      Not Before: Apr  1 00:00:00 2026 GMT    # Cert isn't valid before this date
      Not After : Jun 30 23:59:59 2026 GMT    # Cert is invalid after this date
    Subject:
      CN = iotools.cloud                      # Domain this cert was issued for
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)                  # RSA key size
    X509v3 extensions:
      Subject Alternative Names:
        DNS:iotools.cloud                     # All domains this cert covers
        DNS:www.iotools.cloud
      Key Usage: Digital Signature, Key Encipherment
      Extended Key Usage: TLS Web Server Authentication
      Basic Constraints: CA:FALSE             # This is NOT a CA cert
      Authority Key Identifier: ...           # Fingerprint of issuer's key
      Subject Key Identifier: ...             # Fingerprint of this cert's key
      Certificate Policies: ...
        CPS: http://cps.letsencrypt.org
      OCSP: http://r11.o.lencr.org           # Where to check revocation status

Общее имя (CN)

Исходное поле для указания домена, который охватывает сертификат. Вы всё ещё увидите его заполненным — CN = example.com — но браузеры в основном перестали полагаться на него. С 2000 года поле расширения «Альтернативные имена подлежащего» стало официальным полем для сопоставления доменов. CN в настоящее время является устаревшим; если существует SAN, браузеры используют SAN.

Альтернативные имена подлежащего (SAN)

Это реальный список доменов, которые защищает сертификат. Один сертификат может охватывать десятки имен — звёздные записи (*.example.com), точные имена, даже IP-адреса. Многоименованные сертификаты (иногда называемые SAN-сертификатами или UCC-сертификатами) являются стандартной практикой. CA выдаёт сертификаты по этому списку, а браузеры сопоставляют имя хоста, которое вы посещаете, с этим списком.

Одно из ограничений звёздных записей не может сделать: охватывать под-поддомены. *.example.com охватывает app.example.com но не api.v2.example.com. Многие люди узнают об этом тяжело.

Срок действия

Две временные метки: Не до и Не после. Сертификат недействителен вне этого окна — до начала срока действия, после окончания срока. Оба в UTC.

Максимальные сроки действия сертификатов постепенно сокращаются. В 2015 году максимальный срок составлял три года. В 2018 году он сократился до двух лет. В 2020 году Apple односторонне начала отклонять сертификаты длиной более 398 дней (примерно 13 месяцев), заставляя производителей браузеров и CA следовать. К 2026 году Комитет CA/Browser утвердил дорожную карту, согласно которой этот срок сократится до 47 дней к 2027 году.

Аргумент в пользу более коротких сроков действия обоснован: если приватный ключ был украден, короткий срок действия ограничивает радиус воздействия. Операционная реальность заключается в том, что более короткие сроки увеличивают давление на корректность автоматизированного обновления. Сертификаты Let’s Encrypt на 90 дней были спорными в 2015 году по той же причине; сегодня они считаются лучшей практикой, и автоматическое обновление ожидается.

Издатель и цепочка доверия

The Эмитент поле указывает на субъект, который подписал сертификат. Для большинства публичных сайтов это промежуточный CA (например, Let’s Encrypt R11), а не корневой CA. Корневые CAs подписывают сертификаты промежуточных CA; промежуточные CAs подписывают сертификаты конечных субъектов (те, которые ваш сервер представляет). Эта цепочка существует потому, что приватные ключи корневых CA хранятся в изолированных HSM-устройствах, и вы не можете выдавать один из них для подписания миллионов доменных сертификатов в год.

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

По этой причине наиболее распространённой ошибкой настроек TLS является забывание предоставить промежуточный сертификат вместе с конечным сертификатом. Браузер может кэшировать промежуточный сертификат и казаться нормальным, в то время как другие клиенты — curl, мобильные приложения, серверы, делающие исходящие API-запросы — не справляются, потому что у них нет пути к корню.

Алгоритм подписи

Два элемента, объединённые в одно поле: хеш-функция, используемая для хэширования данных сертификата, и алгоритм ключа, используемый для подписи хэша. sha256WithRSAEncryption означает хеш SHA-256, подпись RSA. ecdsa-with-SHA256 означает хеш SHA-256, подпись ECDSA.

Сертификаты с хешем SHA-1 были отменены браузерами в 2017 году и теперь вызывают сильные ошибки. Подписи MD5 были отменены ранее и практически уничтожены. Если вы используете что-то, что выдаёт сертификаты SHA-1, обновите конфигурацию CA до того, как браузер обновится и сделает это сам.

ECDSA (обычно P-256 или P-384) создаёт более маленькие ключи и подписи, чем RSA при одинаковой безопасности. Ключ EC-256 примерно эквивалентен ключу RSA 3072 бит. Стоимость: RSA более универсально совместим с очень старыми клиентами; ECDSA быстрее и лёгче. Современные развертывания часто настраивают оба варианта и позволяют TLS-переговорам выбирать.

Использование ключа и расширенное использование ключа

Использование ключа это битовая маска, указывающая, какие действия разрешены ключу: подпись данных, шифрование данных, подпись других сертификатов (только для CA). Расширенное использование ключа уточняет это для конкретных протоколов: TLS Web Server Authentication позволяет использовать сертификат для HTTPS. TLS Web Client Authentication используется для клиентских сертификатов mTLS. Code Signing используется для сертификатов программной подписи.

Если вы пытаетесь использовать сертификат для цели, не указанной в его объявленном Использовании ключа, современные реализации TLS отклонят его. Вы не можете использовать сертификат программной подписи на веб-сервере, даже если домен совпадает.

Основные ограничения: CA:FALSE

Это поле указывает, может ли сертификат использоваться для подписи других сертификатов. CA:FALSE означает, что он не может — это сертификат конечного субъекта. CA:TRUE означает, что это сертификат CA, разрешённый подписывать другие сертификаты в цепочке.

The pathLenConstraint которое иногда появляется рядом с этим, сообщает, сколько промежуточных CA ниже этого уровня разрешено. Корневые CAs часто устанавливают это значение для ограничения глубины цепочки.

OCSP и отмена

URL OCSP (протокол онлайн-статуса сертификата) в сертификате указывает клиентам, где проверить, не была ли сертификат отозван до истечения срока. Отмена происходит, когда приватный ключ был украден или сертификат был выдан по ошибке.

На практике, проверка OCSP в браузерах имеет сложную историю. Chrome прекратил выполнять проверку OCSP много лет назад, предпочтя CRLSets (предварительно загруженный список отозванных сертификатов). Firefox всё ещё выполняет OCSP, но по умолчанию использует мягкий отказ, что означает, если сервер OCSP недоступен, сертификат считается действительным. Итог: для большинства сертификатов отмена в реальности является теоретической. Это один из аргументов в пользу коротких сроков действия сертификатов — при 47 днях отмена становится менее значимой, потому что сертификат скоро истекает.

Почему сертификаты истекают

Истечение не является бюрократической проблемой. Это механизм, ограничивающий срок действия украденного сертификата. Альтернатива — постоянные сертификаты — приводит к тому, что вы получаете сертификаты SHA-1 и ключи CA, которые находятся в производстве уже десятилетия, что было характерно для отрасли в 2010 году.

Стоимость — операционная: более короткие сроки требуют надёжной автоматизации. Если ваше обновление зависит от напоминания системного администратора, вы в конечном итоге истечете в производственной среде. Правильный ответ — автоматическое обновление через ACME (протокол Let’s Encrypt) или API вашего CA, с мониторингом, который уведомляет несколько недель до истечения, а не в момент смерти.

Как читать сертификат без командной строки

Стандартный способ проверки сертификата — openssl x509 -in cert.pem -text -noout, который создаёт вывод, отформатированный для тех, кто может легко читать RFC 5280. Если вы хотите получить ту же информацию в формате, который не требует запоминания флагов openssl, то Декодер SSL/TLS сертификатов и Парсер сертификатов X.509 на iotools.cloud оба принимают PEM-сертификат и возвращают все поля с метками и организованы — полезно при отладке проблемы цепочки в полночь, когда текст openssl не помогает.

Вам также может понравиться