Сертификат X.509 и центры сертификации
| Стандарт | ITU-T X.509 (1988), версия 3 (1996) |
|---|---|
| Профиль для интернета | RFC 5280 |
| Структура доверия | корневой → промежуточный → конечный сертификат |
| Правила для публичных CA | CA/Browser Forum Baseline Requirements |
| Типы проверки | DV, OV, EV |
| Прозрачность | Certificate Transparency (RFC 6962, 2013) |
| Форматы файлов | PEM, DER, PKCS#12 (.pfx) |
Сертификат X.509 — цифровой документ, который связывает открытый ключ с владельцем: доменным именем, организацией или человеком. Сертификат подписан центром сертификации (Certificate Authority, CA) — организацией, которой доверяют браузеры и операционные системы. Когда браузер подключается к сайту по TLS, сервер предъявляет сертификат, и браузер проверяет подпись, срок действия и совпадение имени. Так пользователь убеждается, что разговаривает именно с bank.example, а не с подставным сервером.
Система центров сертификации, корневых хранилищ и правил выпуска называется инфраструктурой открытых ключей (PKI). Её основа — Криптография с открытым ключом.
Происхождение
Формат X.509 появился в 1988 году как часть стандартов каталогов X.500 Международного союза электросвязи.[2] Для интернета важна третья версия (1996) с расширениями, а правила её использования описывает профиль RFC 5280.[1] Хотя каталоги X.500 так и не прижились, формат сертификатов стал стандартом для HTTPS, подписи кода, электронной почты (S/MIME) и электронной подписи.
Что внутри
openssl x509 -in cert.pem -noout -text
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
| Поле | Значение |
|---|---|
| Subject | кому выдан (для сайтов значимы не оно, а SAN) |
| Subject Alternative Name (SAN) | доменные имена, для которых действителен сертификат, включая wildcard *.example.com |
| Issuer | кто выдал |
| Validity | даты начала и окончания действия |
| Public Key | открытый ключ владельца (RSA, ECDSA, Ed25519) |
| Key Usage, Extended Key Usage | для чего можно использовать ключ (сервер TLS, подпись кода) |
| Basic Constraints | может ли сертификат сам выпускать сертификаты |
| Signature | подпись центра сертификации |
Цепочка доверия
Корневые центры не подписывают сертификаты сайтов напрямую — их ключи хранятся офлайн. Используется цепочка:
Корневой сертификат (в хранилище браузера или ОС, самоподписан)
└─ Промежуточный сертификат (подписан корневым)
└─ Сертификат сайта (подписан промежуточным)
Сервер отправляет свой сертификат вместе с промежуточными, а браузер достраивает цепочку до одного из доверенных корней в своём хранилище (их около полутора сотен). Самая частая ошибка настройки — сервер не отдаёт промежуточный сертификат: часть браузеров достроит цепочку сама, а curl, мобильные приложения и другие клиенты — нет. Поэтому серверу указывают файл с полной цепочкой (fullchain.pem).
Типы проверки
| Тип | Что проверяет CA | Применение |
|---|---|---|
| DV (Domain Validation) | контроль над доменом | большинство сайтов, Let's Encrypt |
| OV (Organization Validation) | контроль над доменом и существование организации | корпоративные сайты |
| EV (Extended Validation) | расширенная проверка организации | раньше — «зелёная строка» в браузере |
Браузеры перестали выделять EV-сертификаты в интерфейсе, поскольку пользователи не замечали разницы, поэтому для шифрования и аутентификации домена DV-сертификатов достаточно.
Правила и прозрачность
Публичные центры сертификации подчиняются требованиям CA/Browser Forum — консорциума центров и разработчиков браузеров: как проверять заявителя, как хранить ключи, каков максимальный срок действия.[3] С 2020 года публичные сертификаты не могут действовать дольше 398 дней, и срок продолжают сокращать, подталкивая к автоматическому продлению.
Нарушения караются исключением из корневых хранилищ: после взлома нидерландского центра DigiNotar (2011), выпустившего поддельные сертификаты Google, ему перестали доверять; в 2017–2018 годах браузеры поэтапно отказались от сертификатов Symantec за систематические нарушения.
Чтобы такие инциденты обнаруживались быстро, существует Certificate Transparency: все публичные сертификаты записываются в открытые журналы только для добавления, и браузеры не принимают сертификаты без доказательства такой записи.[4][5] Владелец домена может искать в журналах все выпущенные на него сертификаты, например на crt.sh.[6]
Отзыв
Если закрытый ключ скомпрометирован, сертификат нужно отозвать. Механизмы — списки отзыва (CRL) и протокол OCSP — на практике работают ненадёжно: браузеры часто не проверяют отзыв из-за задержек. Поэтому отрасль делает ставку на короткие сроки действия: украденный сертификат быстро истечёт сам.
Частные PKI
Внутри компаний разворачивают собственные центры сертификации — для внутренних сервисов, взаимной аутентификации (mTLS) между микросервисами, VPN и устройств. Инструменты — step-ca, HashiCorp Vault, cert-manager в Kubernetes. Корневой сертификат частного CA устанавливают в хранилища доверия своих машин; самоподписанные сертификаты без CA годятся только для разработки.