# Сертификат X.509 и центры сертификации

> Цифровой сертификат X.509 связывает открытый ключ с доменом или организацией и подписан центром сертификации; цепочки доверия от корневых центров лежат в основе HTTPS и PKI.

Источник: https://llmdocs.ru/wiki/x509-certificates/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Стандарт**: 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](https://llmdocs.ru/wiki/tls.md), сервер предъявляет сертификат, и браузер проверяет подпись, срок действия и совпадение имени. Так пользователь убеждается, что разговаривает именно с `bank.example`, а не с подставным сервером.

Система центров сертификации, корневых хранилищ и правил выпуска называется **инфраструктурой открытых ключей** (PKI). Её основа — [Криптография с открытым ключом](https://llmdocs.ru/wiki/public-key-cryptography.md).

## Происхождение

Формат X.509 появился в 1988 году как часть стандартов каталогов X.500 Международного союза электросвязи.[2] Для интернета важна третья версия (1996) с расширениями, а правила её использования описывает профиль RFC 5280.[1] Хотя каталоги X.500 так и не прижились, формат сертификатов стал стандартом для HTTPS, подписи кода, электронной почты (S/MIME) и электронной подписи.

## Что внутри

```bash
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 | подпись центра сертификации |

## Цепочка доверия

Корневые центры не подписывают сертификаты сайтов напрямую — их ключи хранятся офлайн. Используется цепочка:

```text
Корневой сертификат (в хранилище браузера или ОС, самоподписан)
  └─ Промежуточный сертификат (подписан корневым)
       └─ Сертификат сайта (подписан промежуточным)
```

Сервер отправляет свой сертификат вместе с промежуточными, а браузер достраивает цепочку до одного из доверенных корней в своём хранилище (их около полутора сотен). **Самая частая ошибка настройки** — сервер не отдаёт промежуточный сертификат: часть браузеров достроит цепочку сама, а [curl](https://llmdocs.ru/wiki/curl.md), мобильные приложения и другие клиенты — нет. Поэтому серверу указывают файл с полной цепочкой (`fullchain.pem`).

## Типы проверки

| Тип | Что проверяет CA | Применение |
|---|---|---|
| DV (Domain Validation) | контроль над доменом | большинство сайтов, [Let's Encrypt](https://llmdocs.ru/wiki/lets-encrypt-acme.md) |
| 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](https://llmdocs.ru/wiki/kubernetes.md). Корневой сертификат частного CA устанавливают в хранилища доверия своих машин; самоподписанные сертификаты без CA годятся только для разработки.

## См. также

- [TLS](https://llmdocs.ru/wiki/tls.md)
- [Let's Encrypt и ACME](https://llmdocs.ru/wiki/lets-encrypt-acme.md)
- [Криптография с открытым ключом](https://llmdocs.ru/wiki/public-key-cryptography.md)
- [SNI](https://llmdocs.ru/wiki/sni.md)
- [Хеш-функция](https://llmdocs.ru/wiki/hash-function.md)

## Источники

1. [RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile](https://www.rfc-editor.org/rfc/rfc5280)
2. [ITU-T Recommendation X.509](https://www.itu.int/rec/T-REC-X.509)
3. [CA/Browser Forum — Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/documents/)
4. [RFC 6962 — Certificate Transparency](https://www.rfc-editor.org/rfc/rfc6962)
5. [Certificate Transparency — certificate.transparency.dev](https://certificate.transparency.dev/)
6. [crt.sh — поиск по журналам Certificate Transparency](https://crt.sh/)