X.509 — стандарт ITU-T для инфраструктуры открытого ключа (англ. Public key infrastructure, PKI) и инфраструктуры управления привилегиями (англ. Privilege Management Infrastructure).
X.509 определяет стандартные форматы данных и процедуры распределения открытых ключей с помощью соответствующих сертификатов с цифровыми подписями. Эти сертификаты предоставляются удостоверяющими центрами (англ. Certificate Authority). Кроме того, X.509 определяет формат списка аннулированных сертификатов, формат сертификатов атрибутов и алгоритм проверки подписи путём построения пути сертификации. X.509 предполагает наличие иерархической системы удостоверяющих центров для выдачи сертификатов.
История
По мере развития телекоммуникационных технологий, в частности, сети Интернет, стала актуальной задача обеспечения безопасного доступа пользователей к информационным ресурсам, позволяющая избежать криптографической атаки «человек посередине». Одним из способов её решения является механизм сертификации участников информационного обмена. С целью обеспечения функциональной совместимости различных программно-аппаратных продуктов (средств криптографической защиты информации), использующихся в таких прикладных сервисах (WWW, электронная почта, системы аутентификации пользователей и др.) был создан стандарт, описывающий формат сертификатов, который был впервые опубликован ITU-T в 1988 году в качестве части рекомендаций X.500 (RFC 5280). Это был X.509 v1. В 1993 году в описание стандарта сертификатов добавили 2 поля, что привело к появлению X.509 v2, а ещё несколько позже появилась третья версия стандарта — X.509 v3.
Вопросами реализации стандарта в сети Интернет занимается рабочая группа IETF, сформированная в 1995 году и более известная как Public-Key Infrastructure (X.509) working group (PKIX). Результатами её работы, в частности, стали рекомендации RFC 3280 и 5280.
X.509 стал основой для построения иерархической системы удостоверяющих центров, несмотря на появление в 1991 году технологии PGP. Стандарт поддерживается в таких протоколах и механизмах как TLS / SSL, HTTPS, IPsec, SSH и других.
Описание
Согласно RFC 1422, стандарт X.509 определяет понятие «сертификат с открытом ключом» и другие базовые определения PKIX. При этом сертификат с открытым ключом представляет собой определённую структуру данных, которая содержит имя пользователя, открытую составляющую (англ. Public Component) ключа двухключевой криптосистемы этого пользователя и имя компании (далее — «издатель»), который подтверждает, что открытая составляющая привязана к имени пользователя. Эти данные через каждый временной интервал подписываются эмитентом. В сертификатах имена субъекта и издателя являются различимыми именами (англ. Distinguished Names), как определено в системном каталоге Х.500.
После подписания, сертификаты могут храниться на LDAP-серверах. Передаются сертификаты через незащищённые обменные сообщения или через любое другое средство, которое делает сертификаты легко доступными при отправке сообщений пользователям. Сертификаты используются в PEM-кодировке, чтобы обеспечить отправителя подлинной открытой составляющей каждого получателя, а также чтобы обеспечить каждого получателя подлинной открытой составляющей отправителя.
Открытый ключ в PKI привязан к конкретной личности пользователя в так называемом цифровом сертификате, которым может быть, например, сертификат X.509. Согласно RFC 347, основными компонентами эффективной PKI являются:
- Удостоверяющий центр
- Регистрационный номер
- Репозиторий сертификатов
- Архив сертификатов
- Конечные субъекты (например, браузер)
Для технологии открытых ключей необходимо, чтобы пользователь открытого ключа был уверен, что этот ключ принадлежит именно тому удалённому субъекту (пользователю или системе), который будет использовать средства шифрования или цифровой подписи. Такую уверенность дают сертификаты открытых ключей. Сертификат имеет ограниченный срок действия. Поскольку пользователь сертификата может самостоятельно проверить его подпись и срок действия, сертификаты могут распространяться через незащищённые каналы связи и серверные системы, а также храниться в кэш-памяти незащищённых пользовательских систем. В настоящее время в этой области предлагается следующий общий стандарт для всемирной сети с использованием X.509 v3:
Структура сертификата X.509
- Сертификат
- Версия
- Серийный номер
- Идентификатор алгоритма подписи
- Имя издателя
- Период действия:
- Не ранее
- Не позднее
- Имя субъекта
- Информация об открытом ключе субъекта:
- Алгоритм открытого ключа
- Открытый ключ субъекта
- Уникальный идентификатор издателя (обязательно только для v2 и v3)
- Уникальный идентификатор субъекта (обязательно только для v2 и v3)
- Дополнения (для v2 и v3)
- Возможные дополнительные детали
- Алгоритм подписи сертификата (обязательно только для v3)
- Подпись сертификата (обязательно для всех версий)
В 4 разделе RFC 2459 описана структура сертификата X.509 v3. Обновленная структура сертификата X.509 v3 описана в документе RFC 5280 в 4 разделе. Она специализирована под интернет-приложения.
Для описания внутренней структуры сертификатов X.509 используется ASN.1. Хранятся, как правило, в виде DER или PEM-файлов. Общепринятое расширение .cer или .crt. Может быть и другое расширение.
Особенности
Для выпуска сертификатов существует четко определённая иерархическая система удостоверяющих центров (далее — УЦ), согласно RFC 5280. В этом его отличие от моделей, основанных на принципе сети доверия (англ. Web of trust), подобной криптографической технологии PGP, где любой (не только УЦ) может выпускать, подписывать и проверять на соответствие сертификат. , Согласно RFC 4158, X.509 v3 обладает гибкостью для поддержки таких топологий как мосты и сетки , а также может быть использован в p2p сетях.
Добавлены расширения и особенность критичности для X.509 в 1995 году.
Существуют ограничения стандарта X.509 при использовании его для шифрования сообщений электронной почты и совместной работы приложений. X.509 предлагает неполную совместимость работы приложениями. А значит, могут возникнуть проблемы при работе с API.
Иерархическая PKI
Согласно RFC 4387, суть PKI следующая: в браузере хранятся не сертификаты сайтов, а сертификаты УЦ. Это означает, что когда ваш браузер получает сертификат сайта при установке соединения, он видит помимо адреса сайта ещё и «адрес» УЦ, а также цифровую подпись, которую сгенерировал УЦ с использованием своего секретного ключа. Дальше браузер берёт из локального хранилища цепь сертификатов УЦ, достаёт из него публичный ключ и с помощью него проверяет подпись в сертификате сайта. Если подпись правильная, соединение успешно устанавливается.
Согласно RFC 5280, цепь сертификатов представляет собой список сертификатов (начиная с лица, удостоверенного в качестве сервера), включающий один или несколько УЦ (последний подписывается самим собой), обладает следующими свойствами:
- Подпись каждого сертификата (за исключением последнего) является удостоверяющим центром-преемником.
- Все сертификаты, за исключением последнего, подписываются с помощью закрытого ключа следующего УЦ.
- Последний сертификат в цепи является сертификатом единственного пункта доверия, являющегося корневым УЦ.
Иерархические PKI способны быстро реагировать на компрометацию отдельного УЦ внутри инфраструктуры. Если УЦ скомпрометирован, вышестоящий УЦ просто аннулирует его сертификат. Как только работа УЦ восстанавливается, он выпускает новые сертификаты для всех своих пользователей. Вышестоящий УЦ выпускает для скомпрометированного УЦ новый сертификат с новым открытым ключом, что позволяет вернуть этот центр обратно в иерархию.
Общеупотребительные расширения файлов сертификатов
.CER— сертификат, или набор сертификатов, закодированных по стандарту CER..DER— сертификат, закодированный по стандарту DER..PEM— PEM-сертификат, закодированный по стандарту DER и использующий Base64 и помещенный между «—– BEGIN CERTIFICATE —–» и «—– END CERTIFICATE —–»..P7B,.P7C— PKCS #7 содержит несколько сертификатов или CRL..P12— PKCS #12 содержит блок, хранящий одновременно и закрытый ключ, и сертификат (в зашифрованном виде)..PFX— PFX, предшественник PKCS #12, также содержит блок закрытого ключа и сертификат.
Список аннулированных сертификатов (CRL)
Согласно RFC 3280, CRL подписывается удостоверяющим центром и свободно распространяется через общедоступный репозиторий сертификатов. Репозиторий сертификатов обычно размещается на сервере каталогов в соответствии с международным стандартом X.500 и его подмножеством. В списке CRL каждый аннулированный сертификат опознается по своему серийному номеру. Когда у какой-то системы возникает необходимость в использовании сертификата, эта система не только проверяет подпись сертификата и срок его действия, но и просматривает последний из доступных списков CRL, проверяя, не аннулирован ли этот сертификат.
Сертификат может стать недействительным по многим причинам, например: из-за превышения срока действия, из-за потери или компрометация закрытого ключа, связанного с сертификатом, из-за изменения, как минимум, одного поля, входящего в имя владельца сертификата и в крайних случаях из-за утраты или компрометации закрытого ключа УЦ, которым подписан сертификат.
Поэтому стандарт определяет формат списка с указанием сертификатов, которые стали недействительными для УЦ. Этот список подписывается УЦ для предотвращения изменений неуполномоченным лицом.
Он включает в себя дату выдачи, дату обновления (необязательно), и сам список в виде пар (серийный номер аннулированного сертификата; причина возможного аннулирования). Шаблон может присутствовать только в формате CRL v2, который описан в RFC 5280 в 5 разделе.
Большим недостатком является ограничение CRL, которое состоит в долгом поступлении информации об аннулировании сертификата. Чтобы ускорить, был разработан протокол OCSP для проверки сертификата. Описанный изначально в RFC 2560, а затем снова в RFC 6960, протокол OCSP дает почти ту же информацию, что и CRL. Сервер OCSP обслуживает пользователей в режиме онлайн и занимается проверкой статуса аннулирования цифрового сертификата.