X.509-сертификат

17 июля 2026 · ~14 мин чтения

X.509-сертификат

X.509-сертификат — это цифровой документ, который связывает публичный ключ (открытую половину криптографической пары) с именем владельца и подписан удостоверяющим центром, которому доверяют заранее. Проще говоря, это «паспорт» для сервера, устройства или человека в мире шифрованных соединений: он не сам шифрует, а удостоверяет, кто с тобой разговаривает.

История

Стандарт X.509 родился не в интернете, а в мире телекомов. В конце 1980-х международный союз ITU-T (Международный союз электросвязи, подразделение по стандартизации) работал над серией X.500 — амбициозным проектом единого глобального каталога всех людей и организаций планеты, с иерархией имён вроде «страна → организация → отдел → человек». Задумка была примерно как единая телефонная книга Земли. Чтобы записи в этом каталоге можно было доверять, нужен был способ подписать их криптографически — так в 1988 году появился документ X.509 версия 1: он описывал формат сертификата, привязывающего имя из каталога X.500 к публичному ключу.

Сам X.500 как единый мировой каталог провалился — интернет пошёл другой дорогой, через DNS и веб. А вот X.509 неожиданно выжил и стал стандартом де-факто там, где никакой X.500 никогда и не был нужен: в вебе, почте, VPN, корпоративных сетях.

Основные вехи:

• 1988 — X.509 v1, самая базовая структура: имя, ключ, срок, подпись.
• 1993 — v2, добавили серийные номера издателя и субъекта. Практически нигде не прижилась.
• 1996 — v3, ключевой прорыв: расширения (extensions). Именно они позволили упаковать в сертификат список доменных имён, назначение ключа, ссылки на списки отзыва и десятки других вещей. Без v3 современного HTTPS бы не существовало.
• RFC 5280 (2008) — профиль PKIX, то есть «как правильно готовить X.509 для интернета». Именно этот документ до сих пор является настольной книгой всех, кто пишет TLS-библиотеки и удостоверяющие центры.
• RFC 6962 (2013) — Certificate Transparency, публичные логи всех выданных сертификатов. Ответ индустрии на серию скандалов с недобросовестными CA.
• 2015, конец года — запуск Let's Encrypt, бесплатного автоматизированного удостоверяющего центра. Это событие изменило веб больше, чем любая правка стандарта: HTTPS из премиум-фичи стал нормой.

Сегодня X.509 — старый, критикуемый, местами неуклюжий стандарт, у которого куча наследия из 1980-х (упоминание X.500-имён, странности кодирования). Но он повсеместен и никуда не уходит: на нём построен весь TLS в вебе, значительная часть VPN, подписи кода в Windows и macOS, корпоративный Wi-Fi по WPA2/3-Enterprise.

Что это такое

Если очень коротко, X.509-сертификат — это подписанная структурированная запись из нескольких обязательных полей: кому выдан (Subject), кем выдан (Issuer), какой публичный ключ внутри, с какого и по какое число валиден (notBefore / notAfter), плюс подпись издателя, покрывающая всё вышеперечисленное.

Хранится это добро в формате ASN.1 DER (двоичное представление) — это компактные байты, которые не откроешь в блокноте. Для передачи по почте и вставки в конфиги те же самые байты оборачивают в PEM: Base64 плюс маркеры -----BEGIN CERTIFICATE----- и -----END CERTIFICATE-----. PEM — это буквально «DER, переведённый в текст», содержимое то же.

Несколько пар «X vs Y», которые важно не путать:

• Сертификат vs ключ. Ключ — это математический объект (для RSA это два больших числа, для ECDSA — точка на эллиптической кривой). Сертификат — это ключ плюс подтверждающая обёртка. У тебя всегда есть приватный ключ (секрет, не выходит с сервера) и сертификат с публичным ключом (можно раздавать всем). Сертификат без приватного ключа бесполезен для сервера, а приватный ключ без сертификата бесполезен для клиента.
• X.509 vs TLS. X.509 — это формат документа. TLS — это протокол разговора двух сторон, который использует X.509 как способ узнать, кто на другом конце провода. Можно представить X.509 как удостоверение личности, а TLS — как процедуру проверки этого удостоверения на входе.
• Self-signed vs CA-signed. Self-signed («самоподписанный») — сертификат, где Issuer совпадает с Subject: подписал сам себя. Он валиден математически, но никто в мире по умолчанию ему не доверяет. CA-signed — сертификат, подписанный удостоверяющим центром, чей корневой сертификат уже лежит в доверенном хранилище всех браузеров и ОС.
• DV vs OV vs EV. Три уровня проверки перед выдачей: DV (Domain Validation) — доказал контроль над доменом (положил файл, ответил на DNS-запись), быстро и бесплатно; OV (Organization Validation) — плюс проверка юрлица; EV (Extended Validation) — плюс углублённая проверка организации по регламенту. Технически сертификат от этого не «сильнее», отличается только уровень доверия к процедуре выдачи.

Аналогии из жизни

Загранпаспорт с фото и подписью МВД. В паспорте есть твоё имя, срок действия, фото — и всё это защищено печатью и подписью выдавшего органа. На границе пограничник не звонит тебе домой, чтобы «проверить, точно ли это ты» — он доверяет паспорту, потому что доверяет МВД, а МВД доверяет международным договорам. Ровно та же логика в X.509: браузер не звонит владельцу сайта, а верит подписи CA, потому что корень этого CA лежит в его доверенном списке. Где ломается: паспорт можно подделать, если скомпрометирован сам орган выдачи (например, коррумпированный чиновник напечатал настоящий паспорт с чужим лицом). В мире X.509 это ровно история DigiNotar 2011: подлинный CA выдал подлинные с точки зрения криптографии сертификаты на *.google.com не тому. Криптография была цела — сломалось доверие к выдающей стороне.

Нотариально заверенная доверенность. Ты подписываешь бумагу «доверяю Иванову получить посылку», нотариус ставит печать. Курьер не знает лично ни тебя, ни Иванова, но верит печати нотариуса, чью подпись он умеет проверять. Иерархия: клиент → нотариус → нотариальная палата → государство. В X.509 такая же цепочка: leaf-сертификат сервера подписан промежуточным CA, тот подписан корневым CA, а корень уже лежит в хранилище браузера. Где ломается: если у доверенности истёк срок, курьер её не примет, даже если печать целая. С сертификатом та же беда: notAfter прошёл — соединение красное. И, как с бумагой, доверенность можно отозвать до истечения срока (нотариус ведёт реестр). У X.509 есть аналоги: CRL и OCSP, но на практике они работают криво (см. дальше).

Бейдж сотрудника на конференции. У бейджа есть срок (даты конференции), имя, фото, лого выдавшего оргкомитета, штрихкод для проверки. Охранник на входе сверяет твой бейдж со списком организаторов, а не звонит тебе с уточнением. Где ломается: если ты потерял бейдж и его нашёл посторонний — до конца конференции он может ходить как ты. Ровно так же утёкший приватный ключ + действующий сертификат = злоумышленник может выдавать себя за твой сервер, пока сертификат не истечёт или пока его не отзовут. Поэтому истории про «слитый ключ» — это всегда срочная замена сертификата, а не «ну и ладно».

Как это работает

Заглянем внутрь. Если открыть сертификат командой openssl x509 -in cert.pem -text -noout, увидим примерно такую структуру (пересказываю по-человечески):

• Version — обычно 3.
• Serial Number — уникальный номер в рамках одного издателя.
• Signature Algorithm — чем подписано (например, sha256WithRSAEncryption или ecdsa-with-SHA384).
• Issuer — кто подписал, в виде набора полей: страна C, организация O, общее имя CN.
• Validity — Not Before и Not After, две даты.
• Subject — кому выдано. Для сайтов раньше сюда писали доменное имя в CN, теперь это устаревшая практика — используется расширение SAN (см. ниже).
• Subject Public Key Info — сам публичный ключ и алгоритм (RSA-2048, ECDSA P-256 и т. п.).
• Extensions (v3): Subject Alternative Name (SAN) — список доменов, для которых валиден сертификат (www.example.com, example.com, *.api.example.com); Key Usage и Extended Key Usage — для чего этот ключ можно применять (шифрование, подпись, TLS-сервер, TLS-клиент, подпись кода); Basic Constraints — «этот сертификат сам является CA или нет?»; CRL Distribution Points и Authority Information Access — куда ходить проверять отзыв; SCT — доказательства попадания в Certificate Transparency-логи.
• Signature Value — собственно подпись издателя над всем вышеперечисленным.

Теперь цепочка доверия. В браузере и операционной системе живёт root store — список корневых сертификатов, которым эта система доверяет по умолчанию. Их не больше пары сотен: Apple, Microsoft, Mozilla, Google ведут свои списки. Корни хранятся в железе доверия десятилетиями и подписывают сами себя.

Схематично:

[Root CA]                  ← лежит в браузере, подписал сам себя
    │  подписывает
    ▼
[Intermediate CA]          ← промежуточный, живёт у CA, срок 5–10 лет
    │  подписывает
    ▼
[Leaf-сертификат сервера]  ← твой example.com, срок 3–13 месяцев

Когда браузер приходит на сайт, сервер присылает ему свой leaf плюс промежуточные (root сервер отдавать не должен и не обязан — он и так лежит у клиента). Браузер:

1. Берёт leaf, находит поле Issuer.
2. Ищет сертификат с таким Subject среди присланных промежуточных.
3. Проверяет подпись leaf публичным ключом из промежуточного.
4. Повторяет для промежуточного — ищет его Issuer.
5. В конце цепочки находит корень в своём локальном хранилище. Если нашёл и все подписи сошлись — доверие установлено.
6. Дополнительно сверяет: не истёк ли какой сертификат в цепочке, есть ли нужный домен в SAN у leaf, не отозван ли сертификат (по OCSP или CRL, если доступно), есть ли достаточно SCT в CT-логах.

Только после этого запускается собственно TLS-рукопожатие: стороны договариваются об алгоритмах, обмениваются данными для порождения общего сеансового ключа (в TLS 1.3 это ECDHE — эфемерный обмен ключами Диффи-Хеллмана на эллиптических кривых), сервер подписывает свою часть обмена приватным ключом, соответствующим публичному из сертификата. Это доказывает клиенту: сервер не просто прислал чей-то сертификат, а реально владеет приватным ключом к нему. С этого момента канал зашифрован сеансовым ключом, а X.509 своё дело сделал.

Полезная практика: проверить, что приватный ключ подходит к сертификату. Обе стороны пары должны иметь одинаковый modulus (модуль ключа, большое общее число у RSA). Быстрая проверка:

openssl x509 -in cert.pem -modulus -noout | openssl md5
openssl rsa  -in key.pem  -modulus -noout | openssl md5

Совпали два хеша — пара валидна. Не совпали — сертификат и ключ от разных пар, TLS не встанет.

Где встречается в обычной жизни

• Замочек в браузере. Каждый раз, когда открываешь сайт по HTTPS, твой браузер незаметно провёл всю проверку цепочки. Клик по замочку показывает leaf-сертификат сайта.
• Мобильный банк и Госуслуги. То же самое, но с дополнительными мерами: приложение часто зашивает свой ожидаемый сертификат прямо внутрь (certificate pinning) — чтобы даже подмена CA не помогла злоумышленнику встроиться в середину.
• Wi-Fi на работе (WPA2/3-Enterprise). Корпоративная сеть с логином через доменные учётные записи защищена именно X.509: у сети есть сертификат, устройства его проверяют, чтобы не подключаться к поддельной точке доступа с тем же именем.
• Обновления операционной системы. Пакеты обновлений подписаны сертификатами Apple, Microsoft, разработчиков дистрибутивов Linux. Операционка проверяет подпись перед установкой — иначе злонамеренное «обновление» могло бы прилететь откуда угодно.
• Мессенджеры и почта. Telegram, WhatsApp, Signal ходят к своим серверам по TLS, значит по X.509. Почтовые клиенты используют TLS до серверов IMAP/SMTP; часть корпоративной почты дополнительно подписывает и шифрует сами письма по стандарту S/MIME — а это тоже X.509.

Где встречается в IT и бизнесе

• HTTPS/TLS для сайтов и API. Самое очевидное применение и по объёму — самое массовое.
• VPN. OpenVPN, IKEv2/IPsec, часть коммерческих корпоративных VPN — вся аутентификация клиентов и серверов ведётся сертификатами. Клиенту выдают персональный сертификат, сервер его проверяет вместо (или вместе с) пароля.
• mTLS (mutual TLS) между микросервисами. В современных распределённых системах сервисы внутри дата-центра часто аутентифицируют друг друга сертификатами: у каждого сервиса свой X.509 с его идентичностью, и любой входящий запрос проверяется по цепочке. Это фундамент service mesh (Istio, Linkerd) и SPIFFE.
• Подпись кода (code signing). Драйверы Windows, приложения macOS, JAR-файлы Java, npm-пакеты в некоторых политиках — всё это подписано сертификатами специальной категории «Code Signing». ОС отказывается ставить неподписанное или подписанное отозванным сертификатом.
• S/MIME для корпоративной почты. Юристы и госкорпорации любят стандарт, где письмо криптографически подписывается отправителем и, по желанию, шифруется для получателя — обе операции опираются на X.509-сертификаты у обеих сторон.
• Электронная подпись документов. В России, ЕС и США существует юридически значимая электронная подпись, техническая база у неё — X.509 или его производные форматы (CAdES, PAdES для PDF, XAdES для XML).

Кто пользуется

• Let's Encrypt (некоммерческая организация ISRG, запущен в конце 2015) — крупнейший по числу выданных сертификатов CA в мире, бесплатный, полностью автоматизированный по протоколу ACME. По разным оценкам, обслуживает сотни миллионов активных сертификатов и обеспечил повсеместное распространение HTTPS.
• Крупные коммерческие CA: DigiCert (поглотивший часть бизнеса Symantec), Sectigo (бывший Comodo CA), GlobalSign, GoDaddy, Entrust. Они живут за счёт OV/EV-сертификатов, гарантий и корпоративных клиентов, которым нужен человеческий саппорт.
• Владельцы root store: Apple (входит в iOS/macOS), Microsoft (Windows), Mozilla (Firefox, а через неё — многие Linux-дистрибутивы), Google (Chrome, Android). Именно они решают, какому CA доверяют миллиарды устройств. Их программы root store — тихая, но огромная власть над всей PKI.
• Государственные PKI. У многих стран есть свой корневой CA для внутренних задач: подписи документов, налоговой отчётности, паспортов нового образца. В России это, в частности, инфраструктура «Госуслуги» и цепочки от Минцифры.
• Внутренние корпоративные CA. Крупные компании поднимают свой внутренний CA (часто на Microsoft Active Directory Certificate Services) и раздают сертификаты сотрудникам, устройствам и внутренним сервисам. Это X.509 без выхода в публичный интернет.

Альтернативы и конкуренты

• SSH-ключи с моделью TOFU (Trust On First Use — «доверяем при первом подключении»). Плюсы: никакого CA, никакой бюрократии, ключи вечные. Минусы: не масштабируется — каждый клиент должен один раз доверчиво принять ключ сервера; при подмене «в первый раз» никто ничего не заметит.
• PGP / GPG с web of trust. Люди подписывают ключи друг друга на «keysigning-вечеринках», доверие растёт горизонтально, без центральных CA. Плюс: устойчивость к монополии. Минус: почти не взлетел массово, слишком сложно для обычного пользователя; корпоративно им никто не пользуется.
• WireGuard. Современный VPN без всякой PKI: две стороны просто заранее знают публичные ключи друг друга. Плюсы: невероятная простота, отличная производительность, короткие ключи. Минусы: раздавать и ротировать ключи в компании из тысячи сотрудников — уже задача, у X.509 для этого есть готовая инфраструктура.
• SPIFFE/SPIRE и SVID. Современная надстройка поверх X.509 (или JWT) для микросервисов: даёт каждому сервису короткоживущую идентичность в формате spiffe://trust-domain/workload. Плюсы: автоматическая ротация, идентичности живут минуты, а не годы; отлично встраивается в Kubernetes. Минусы: сам по себе не заменяет X.509 — во многих режимах он его и выдаёт, просто автоматизированно.

Когда НЕ стоит использовать

• Симметричные секреты между двумя своими сервисами в одном датацентре. Если ты контролируешь обе стороны и они рядом, часто проще положить один общий секрет (например, HMAC-ключ) в vault и подписывать им запросы. Городить mTLS с внутренним CA имеет смысл, когда сервисов десятки и они действительно должны различать друг друга по идентичности, а не по одному общему паролю.
• Одноразовое доказательство личности человека в чате. Для «привет, это правда я» между двумя людьми X.509 избыточен: слишком много инфраструктуры на очень бытовую задачу. Здесь лучше работают Signal-подобные протоколы с обменом отпечатками ключей.
• Внутри embedded-устройства без часов и сети. X.509 сильно завязан на понятие «текущее время» (проверка notBefore/notAfter) и на возможность сходить в OCSP/CRL. Если устройство не знает точное время и не имеет связи, проверка сертификатов превращается в «всегда валидно» или «всегда невалидно» — оба варианта плохи. В таких случаях чаще берут заранее прошитые публичные ключи и подписанные ими прошивки, без сертификатов вокруг.

Связанные понятия

• PKI (Public Key Infrastructure) — вся экосистема вокруг X.509: центры сертификации, регламенты, хранилища ключей, процессы отзыва. Сертификат — один документ, PKI — весь бюрократический аппарат вокруг.
• CA (Certificate Authority) — удостоверяющий центр: организация, которая выпускает сертификаты и своей подписью ручается за связку «имя ↔ ключ».
• CSR (Certificate Signing Request) — «заявка» на сертификат: содержит публичный ключ и желаемое имя субъекта, подписана заявителем. CA берёт CSR и, если проверка пройдена, выпускает готовый сертификат.
• TLS (Transport Layer Security) — протокол защищённого канала между двумя сторонами. Использует X.509 для аутентификации; актуальная версия TLS 1.3 (RFC 8446, 2018).
• Certificate Transparency (CT) — публичные append-only логи всех выданных браузерами-доверенных сертификатов. Любой может искать, кто что выпустил на его домен, и вовремя ловить самозванцев.
• OCSP и CRL — два механизма проверки отзыва сертификата: OCSP спрашивает у CA «этот сертификат ещё живой?» в реальном времени, CRL — это скачиваемый список отозванных серийников. Оба на практике работают криво (медленно, приватно неудобно), поэтому индустрия движется к очень коротким срокам жизни сертификатов вместо надёжного отзыва.

Литература и источники

• RFC 5280 «Internet X.509 Public Key Infrastructure Certificate and CRL Profile» — базовый документ по X.509 для интернета, ietf.org.
• RFC 6962 «Certificate Transparency» — стандарт публичных логов сертификатов, ietf.org.
• RFC 8446 «The Transport Layer Security (TLS) Protocol Version 1.3» — актуальный TLS, ietf.org.
• Wikipedia: статьи «X.509», «Public key infrastructure», «Certificate authority» (доступны на русском и английском, en-версии обычно свежее).
• Bulletproof SSL and TLS, Ivan Ristić — практический учебник по TLS и X.509, регулярно обновляется автором.
• Документация Let's Encrypt (letsencrypt.org) и документация OpenSSL (openssl.org) — «руки» для всего вышесказанного: как выпустить, как посмотреть, как проверить.

Где встретилось у меня

Вчера в задаче автоматизации истёк клиентский X.509-сертификат VPN-доступа: агент внезапно перестал ходить к внешней CRM, всё лежало. Новый сертификат я проверял стандартной парой команд openssl x509 -text (посмотреть срок notAfter и SAN) и сравнением modulus ключа и сертификата через openssl x509 -modulus и openssl rsa -modulus — чтобы убедиться, что мне выдали пару, а не два разных куска от разных заявок. После установки VPN сразу поднялся, доступ вернулся.

Краткое резюме

• X.509 — это «паспорт» для сервера или устройства: связка «имя + публичный ключ», подписанная удостоверяющим центром.
• Доверие строится цепочкой: leaf → intermediate → root; root уже лежит в браузере и ОС, поэтому проверка не требует звонков наружу.
• Ключевые поля: Subject, Issuer, notBefore/notAfter, Subject Alternative Name, публичный ключ, подпись. Формат — ASN.1 DER, в текстовом виде — PEM.
• Модель ломается по людям, а не по математике: истории DigiNotar (2011) и потери доверия к Symantec (2017–2018) — про сбой процедур CA, а не про взлом криптографии. Certificate Transparency (RFC 6962, 2013) появился как ответ на это.
• На практике важно: следить за notAfter, автоматизировать перевыпуск (Let's Encrypt/ACME), уметь быстро проверить пару ключ/сертификат через openssl … -modulus, помнить, что сертификат удостоверяет, а не шифрует.