Х.509

Х.509

Информационные технологии - Взаимосвязь открытых систем - Справочник: Структуры сертификатов открытых ключей и атрибутов
Статус	В силе (рекомендация)
Впервые опубликовано	1.0 от 25 ноября 1988 г ( 1988-11-25 )
Последняя версия	9.1 14 октября 2021 г ( 14.10.2021 )
Организация	ЭТО Т
комитет	17-я Исследовательская комиссия МСЭ-Т
Ряд	Х
Базовые стандарты	АСН.1
Сопутствующие стандарты	ИСО/МЭК 9594-8:2020, Х.500
Домен	Криптография
Веб-сайт	www .Что .int /запись /T-REC-X .509

В криптографии (ITU) , X.509 — это стандарт Международного союза электросвязи определяющий формат сертификатов открытых ключей . Сертификаты X.509 используются во многих интернет-протоколах, включая TLS/SSL , который является основой HTTPS . безопасный протокол для просмотра веб-страниц . Они также используются в автономных приложениях, таких как электронные подписи .

Сертификат X.509 связывает личность с открытым ключом с помощью цифровой подписи. Сертификат содержит удостоверение (имя хоста, организацию или физическое лицо) и открытый ключ ( RSA , DSA , ECDSA , ed25519 и т. д.) и либо подписан центром сертификации, либо является самоподписанным. Когда сертификат подписан доверенным центром сертификации или подтвержден другими способами, лицо, владеющее этим сертификатом, может использовать содержащийся в нем открытый ключ для установления безопасной связи с другой стороной или для проверки документов, подписанных цифровой подписью соответствующим закрытым ключом .

X.509 также определяет списки отзыва сертификатов , которые являются средством распространения информации о сертификатах, которые были признаны недействительными подписывающим органом, а также алгоритм проверки пути сертификации , который позволяет подписывать сертификаты промежуточными сертификатами CA, что в свою очередь подписываются другими сертификатами и в конечном итоге достигают якоря доверия .

X.509 определен «Сектором стандартизации» ITU ( ITU-T SG17 ) в 17-й Исследовательской комиссии ITU-T и основан на абстрактной синтаксической нотации One (ASN.1), другом стандарте ITU-T.

История и использование

X.509 был первоначально выпущен 3 июля 1988 года и начался в связи со стандартом X.500 . Первыми ее задачами было предоставление пользователям безопасного доступа к информационным ресурсам и предотвращение криптографической атаки «человек посередине» . Он предполагает строгую иерархическую систему центров сертификации (ЦС) для выдачи сертификатов. Это контрастирует с сети доверия моделями , такими как PGP , где любой (а не только специальные центры сертификации) может подписывать и, таким образом, подтверждать действительность сертификатов ключей других.

Версия 3 X.509 включает гибкую поддержку других топологий, таких как мосты и ячеистые сети . Его можно использовать в одноранговой OpenPGP . сети доверия, подобной но с 2004 года использовался таким образом редко . Система X.500 внедрена только суверенными государствами. для целей выполнения договора о совместном использовании идентификационной информации штата, а рабочая группа IETF по инфраструктуре открытых ключей (X.509) (PKIX) адаптировала стандарт для более гибкой организации Интернета. Фактически, термин «сертификат X.509» обычно относится к сертификату PKIX IETF и профилю CRL стандарта сертификата X.509 v3, как указано в RFC   5280 , обычно называемый PKIX для инфраструктуры открытых ключей (X.509) .

Одной из первых проблем с инфраструктурой открытых ключей (PKI) и сертификатами X.509 была хорошо известная проблема «какого каталога». Проблема в том, что клиент не знает, где взять недостающие промежуточные сертификаты, поскольку глобальный каталог X.500 так и не появился. Проблема была устранена за счет включения в запрос всех промежуточных сертификатов. Например, ранние веб-серверы отправляли клиенту только сертификат веб-сервера. Клиентам, у которых не было промежуточного сертификата ЦС или места его обнаружения, не удалось создать действительный путь от ЦС к сертификату сервера. Чтобы обойти эту проблему, веб-серверы теперь отправляют все промежуточные сертификаты вместе с сертификатом веб-сервера.

Хотя PKIX относится к стандарту PKI IETF или Интернета, существует множество других PKI с другой политикой. Например, правительство США имеет собственную PKI со своей собственной политикой, а CA/Browser Forum имеет собственную PKI со своей собственной политикой. PKI правительства США представляет собой огромную книгу объемом более 2500 страниц. Если PKI организации слишком сильно отличается от IETF или CA/Browser Forum, то организация рискует потерять совместимость с распространенными инструментами, такими как веб-браузеры , cURL и Wget . Например, если PKI имеет политику выдачи сертификатов только в понедельник, то обычные инструменты, такие как cURL и Wget, не будут применять эту политику и разрешать выдачу сертификата во вторник.

Сертификаты

Сертификат Х.509

Тип интернет-СМИ	приложение/pkix-сертификат
Единый идентификатор типа (UTI)	public.x509-сертификат

Сертификаты X.509 связывают личность с открытым ключом с помощью цифровой подписи. В системе X.509 существует два типа сертификатов. Первый — это сертификат CA. Второй — сертификат конечного объекта. Сертификат CA может выдавать другие сертификаты. Самозаверяющий сертификат ЦС верхнего уровня иногда называют корневым сертификатом ЦС. Другие сертификаты ЦС называются промежуточными или подчиненными сертификатами ЦС. Сертификат конечного объекта идентифицирует пользователя, например человека, организацию или предприятие. Сертификат конечного объекта не может выдавать другие сертификаты. Сертификат конечного объекта иногда называют листовым сертификатом, поскольку под ним не могут быть выданы никакие другие сертификаты.

Организация, которой нужен подписанный сертификат, запрашивает его у центра сертификации, используя такой протокол, как запрос на подпись сертификата (CSR) , простой протокол регистрации сертификатов (SCEP) или протокол управления сертификатами (CMP) . Организация сначала генерирует пару ключей , сохраняя закрытый ключ в секрете и используя его для подписи CSR. заявителя CSR содержит информацию, идентифицирующую заявителя, а также открытый ключ , который используется для проверки подписи CSR, а также отличительное имя (DN), уникальное для человека, организации или бизнеса. CSR может сопровождаться другими учетными данными или доказательствами личности, требуемыми центром сертификации.

CSR будет проверен с использованием центра регистрации (RA), а затем центр сертификации выдаст сертификат, привязывающий открытый ключ к определенному отличительному имени . Роли регистрационного органа и центра сертификации обычно представляют собой отдельные бизнес-единицы с разделением обязанностей, чтобы снизить риск мошенничества.

организации Доверенные корневые сертификаты можно распространить среди всех сотрудников, чтобы они могли использовать систему PKI компании. Такие браузеры, как Internet Explorer , Firefox , Opera , Safari и Chrome, поставляются с заранее установленным набором корневых сертификатов, поэтому сертификаты SSL от основных центров сертификации будут работать мгновенно; по сути, разработчики браузеров определяют, какие центры сертификации являются доверенными третьими лицами для пользователей браузеров. Например, Firefox предоставляет файл CSV и/или HTML, содержащий список включенных центров сертификации.

Х.509 и RFC   5280 также включает стандарты для реализации списка отзыва сертификатов (CRL). Еще одним одобренным IETF способом проверки действительности сертификата является протокол онлайн-статуса сертификата (OCSP). Firefox 3.0 включил проверку OCSP по умолчанию, как и версии Windows, начиная с Vista и выше.

Структура сертификата

Структура, предусмотренная стандартами, выражается на формальном языке, абстрактной синтаксической нотации один (ASN.1).

Структура цифрового сертификата X.509 v3 следующая:

• Сертификат
  • Номер версии
  • Серийный номер
  • Идентификатор алгоритма подписи
  • Имя эмитента
  • Срок действия
    • Не раньше
    • Не после
  • Имя субъекта
  • Информация об открытом ключе субъекта
    • Алгоритм открытого ключа
    • Открытый ключ субъекта
  • Уникальный идентификатор эмитента (необязательно)
  • Уникальный идентификатор субъекта (необязательно)
  • Расширения (необязательно)
    • ...
• Алгоритм подписи сертификата
• Подпись сертификата

Поле «Расширения», если оно присутствует, представляет собой последовательность одного или нескольких расширений сертификата. Каждое расширение имеет свой собственный уникальный идентификатор, выраженный как идентификатор объекта (OID) , который представляет собой набор значений вместе с указанием критического или некритического значения. Система, использующая сертификат, должна отклонить сертификат, если она встретит критическое расширение, которое она не распознает, или критическое расширение, содержащее информацию, которую она не может обработать. Некритическое расширение может быть проигнорировано, если оно не распознано, но должно быть обработано, если оно распознано.

Структура версии 1 приведена в РФК   1422 .

Внутренний формат уникальных идентификаторов эмитента и субъекта, указанный в рекомендации X.520 «Справочник: выбранные типы атрибутов» .

МСЭ-Т ввел уникальные идентификаторы эмитента и субъекта в версии 2, чтобы разрешить повторное использование имени эмитента или субъекта через некоторое время. Примером повторного использования может служить случай, когда ЦС обанкротится и его название будет удалено из общедоступного списка страны. Через некоторое время может зарегистрироваться другой центр сертификации с таким же именем, даже если он не связан с первым. Однако IETF не рекомендует повторно использовать имена издателя и субъекта. Поэтому версия 2 не получила широкого распространения в Интернете.

Расширения были представлены в версии 3. Центр сертификации может использовать расширения для выдачи сертификата только для определенной цели (например, только для подписи цифровых объектов ).

Во всех версиях серийный номер должен быть уникальным для каждого сертификата, выданного конкретным центром сертификации (как указано в RFC   5280 ).

Расширения, информирующие о конкретном использовании сертификата

RFC   5280 (и его предшественники) определяет ряд расширений сертификата, которые указывают, как следует использовать сертификат. Большинство из них представляют собой дуги от joint-iso-ccitt(2) ds(5) id-ce(29) ОИД. Некоторые из наиболее распространенных, определенных в разделе 4.2.1, включают:

• Основные ограничения, { id-ce 19 }, используются для указания того, является ли сертификат сертификатом CA и может ли он сертифицировать или выдавать другие сертификаты. Ограничение можно пометить как критическое. Если ограничение помечено как критическое, то агент должен не обработать сертификат, если агент не понимает ограничение. Агент может продолжать обрабатывать некритическое ограничение, которое он не понимает.
• Ключевое использование, { id-ce 15 }, предоставляет растровое изображение, определяющее криптографические операции, которые могут быть выполнены с использованием открытого ключа, содержащегося в сертификате; например, это может указывать на то, что ключ следует использовать для подписей, а не для шифрования.
• Расширенное использование ключей, { id-ce 37 }, используется, как правило, в конечном сертификате, чтобы указать назначение открытого ключа, содержащегося в сертификате. Он содержит список OID, каждый из которых указывает разрешенное использование. Например, { id-pkix 3 1 } указывает, что ключ может использоваться на стороне сервера соединения TLS или SSL; { id-pkix 3 4 } указывает, что ключ может использоваться для защиты электронной почты.

В целом при использовании RFC   5280 , если сертификат имеет несколько расширений, ограничивающих его использование, все ограничения должны быть соблюдены, чтобы данное использование было подходящим. В RFC приводится конкретный пример сертификата, содержащего как keyUsage, так и ExtendedKeyUsage: в этом случае оба расширения должны быть обработаны, а сертификат можно использовать только в том случае, если оба расширения согласованы в определении использования сертификата. Например, NSS использует оба расширения для указания использования сертификата.

Сертификаты расширенной проверки

Центры сертификации, работающие в рамках PKI CA/Browser Forum, выдают сертификаты с различными уровнями проверки. Различные проверки обеспечивают разные уровни уверенности в том, что сертификат представляет то, что он должен. Например, веб-сервер может быть проверен на самом низком уровне гарантий с помощью электронного письма под названием «Проверка домена» (DV) . Или веб-сервер можно проверить на более высоком уровне гарантий, используя более подробные методы, называемые расширенной проверкой (EV) .

На практике сертификат DV означает, что сертификат был выдан для такого домена, как example.com после того, как кто-то ответил на электронное письмо, отправленное на адрес [email protected]. Сертификат EV означает, что сертификат был выдан для такого домена, как example.com, а владельцем домена является такая компания, как example, LLC, и владелец был подтвержден Уставом корпорации .

Расширенная проверка не добавляет никаких дополнительных элементов управления безопасностью, поэтому настройка безопасного канала с использованием сертификата EV не является «более надежной», чем настройка канала с использованием другого уровня проверки, например DV.

Расширенная проверка обозначается в сертификате с использованием расширения X.509 v3. Каждый центр сертификации использует свой идентификатор объекта (OID) для подтверждения расширенной проверки. Не существует единого OID для обозначения расширенной проверки, что усложняет программирование пользовательского агента. Каждый пользовательский агент должен иметь список OID, указывающий расширенную проверку.

PKI CA/Browser Forum распознает расширенную проверку, и многие браузеры предоставляют пользователю визуальную обратную связь, указывающую, что сайт предоставляет сертификат EV. Другие PKI, такие как PKI Интернета (PKIX), не придают особого значения расширенной проверке. Инструменты, использующие политики PKIX, такие как cURL и Wget, просто рассматривают сертификат EV как любой другой сертификат.

Эксперт по безопасности Питер Гутманн утверждает, что CA создала сертификаты электромобилей для восстановления уровня прибыли после того, как « Гонка ко дну» сократила прибыль. В ходе гонки ко дну ЦС снизил цены, чтобы побудить потребителей покупать сертификаты. В результате прибыль сократилась, а центры сертификации снизили уровень проверки, которую они выполняли, до такой степени, что в сертификате практически не было гарантий.

Расширения имен файлов сертификатов

Существует несколько часто используемых расширений имен файлов для сертификатов X.509. Некоторые из этих расширений также используются для других данных, таких как закрытые ключи.

• .pem – ( Электронная почта с повышенной конфиденциальностью ) Base64 в кодировке Сертификат DER , заключенный между -----BEGIN CERTIFICATE----- и -----END CERTIFICATE-----
• .cer, .crt, .der – обычно в двоичной форме DER , но также распространены сертификаты в кодировке Base64 (см. .pem выше)
• .p8, .p8e, .pk8 – экспортированный закрытый ключ, как указано в PKCS#8 . Может быть в форме DER или PEM, которая начинается с -----BEGIN PRIVATE KEY-----. Зашифрованный ключ начинается с -----BEGIN ENCRYPTED PRIVATE KEY----- и может иметь .p8e расширение.
• .p10, .csr – PKCS#10 — запрос на подпись сертификата (CSR). В форме PEM начинается с -----BEGIN CERTIFICATE REQUEST-----. Они генерируются для отправки в центры сертификации (CA). Он включает ключевые сведения о запрошенном сертификате, такие как общее имя (/CN), субъект, организация, штат, страна, а также открытый ключ сертификата для подписи. Они подписываются центром сертификации, и сертификат возвращается. Возвращенный сертификат — это открытый сертификат (который включает в себя открытый ключ, но не закрытый ключ), который сам по себе может быть в нескольких форматах, но обычно в .p7r.
• .p7r – Ответ PKCS#7 на CSR. Содержит недавно подписанный сертификат и собственный сертификат центра сертификации.
• .p7s - Цифровая подпись PKCS#7 . Может содержать исходный подписанный файл или сообщение. Используется в S/MIME для подписи электронной почты. Определено в RFC 2311.
• .p7m - PKCS#7 (SignedData, EnvelopedData) Сообщение, например, зашифрованный («завернутый») файл, сообщение или электронное письмо в формате MIME. Определено в RFC 2311.
• .p7c - PKCS#7 вырожденная структура SignedData «только для сертификатов», без каких-либо данных для подписи. Определено в RFC 2311.
• .p7b, .keystore - Структура SignedData PKCS#7 без данных, только пакет сертификатов и/или CRL (редко), но не закрытый ключ. Использует DER форму или BER или PEM, которая начинается с -----BEGIN PKCS7-----. Формат, используемый Windows для обмена сертификатами. Поддерживается Java, но часто имеет .keystore вместо этого в качестве расширения. В отличие от .pem сертификаты стиля, этот формат имеет определенный способ включения сертификатов пути сертификации.
• .p12, .pfx, .pkcs12 – PKCS#12 может содержать сертификат(ы) (открытый) и секретные ключи (защищенные паролем) в одном файле. .pfx – Personal Information eXchange PFX, предшественник PKCS#12 (обычно содержит данные в формате PKCS#12, например, с файлами PFX, созданными в IIS ).
• .crl - Список отзыва сертификатов (CRL). Центры сертификации создают их как способ деавторизации сертификатов до истечения срока их действия.

PKCS#7 — это стандарт подписи или шифрования (официально называемого «обертыванием») данных. Поскольку сертификат необходим для проверки подписанных данных, их можно включить в структуру SignedData.

Цепочки сертификатов и перекрестная сертификация

Цепочка сертификатов (см. эквивалентную концепцию «пути сертификации», определенную RFC   5280 , раздел 3.2) представляет собой список сертификатов (обычно начинается с сертификата конечного объекта), за которым следуют один или несколько сертификатов CA (обычно последний является самозаверяющим сертификатом) со следующими свойствами:

1. Эмитент каждого сертификата (кроме последнего) соответствует субъекту следующего сертификата в списке.
2. Каждый сертификат (кроме последнего) подписывается секретным ключом, соответствующим следующему сертификату в цепочке (т.е. подпись одного сертификата можно проверить с помощью открытого ключа, содержащегося в следующем сертификате).
3. Последний сертификат в списке — это якорь доверия : сертификат, которому вы доверяете, поскольку он был доставлен вам с помощью некоторой заслуживающей доверия процедуры.

Цепочки сертификатов используются для проверки того, что открытый ключ (PK), содержащийся в целевом сертификате (первый сертификат в цепочке), и другие данные, содержащиеся в нем, действительно принадлежат его субъекту. Чтобы убедиться в этом, подпись целевого сертификата проверяется с использованием ПК, содержащегося в следующем сертификате, подпись которого проверяется с использованием следующего сертификата, и так далее, пока не будет достигнут последний сертификат в цепочке. Поскольку последний сертификат является якорем доверия, его успешное получение докажет, что целевому сертификату можно доверять.

Описание в предыдущем абзаце представляет собой упрощенный взгляд на процесс проверки пути сертификации, как это определено Раздел 6 RFC   5280 , который включает дополнительные проверки, такие как проверка дат действия сертификатов, поиск CRL и т. д.

Пример 1: Перекрестная сертификация между двумя PKI

Пример 2: продление сертификата ЦС

Изучая, как строятся и проверяются цепочки сертификатов, важно отметить, что конкретный сертификат может быть частью очень разных цепочек сертификатов (все они действительны). Это связано с тем, что несколько сертификатов ЦС могут быть созданы для одного и того же субъекта и открытого ключа, но подписаны разными закрытыми ключами (от разных ЦС или разными закрытыми ключами от одного и того же ЦС). Таким образом, хотя один сертификат X.509 может иметь только одного эмитента и одну подпись ЦС, он может быть правильно связан с несколькими сертификатами, создавая совершенно разные цепочки сертификатов. Это имеет решающее значение для перекрестной сертификации между PKI и другими приложениями. См. следующие примеры:

Примеры

На этих диаграммах:

• Каждое поле представляет собой сертификат, тема которого выделена жирным шрифтом.
• A → B означает «A подписано B» (или, точнее, «A подписано секретным ключом, соответствующим открытому ключу, содержащемуся в B»).
• Сертификаты одного цвета (не белые/прозрачные) содержат один и тот же открытый ключ.

Пример 1. Перекрестная сертификация на уровне корневого центра сертификации (CA) между двумя PKI.

Чтобы обеспечить доверие сертификатам пользователей, существующим в PKI 2 (например, «Пользователь 2»), со стороны PKI 1, CA1 генерирует сертификат (cert2.1), содержащий открытый ключ CA2. Теперь оба сертификата «cert2» и «cert2.1» (отмечены зеленым) имеют одинаковую тему и открытый ключ, поэтому для cert2.2 (Пользователь 2) существуют две действительные цепочки: «cert2.2 → cert2» и «cert2.2 → cert2». 1 → сертификат1».

Аналогичным образом CA2 может создать сертификат (cert1.1), содержащий открытый ключ CA1, чтобы сертификаты пользователей, существующие в PKI 1 (например, «Пользователь 1»), были доверенными для PKI 2.

Пример 2: продление сертификата ЦС

Понимание построения пути сертификации (PDF) . Форум PKI. Сентябрь 2002 г. Чтобы обеспечить плавный переход от старой пары ключей подписи к новой паре ключей подписи, центр сертификации должен выдать сертификат, содержащий старый открытый ключ, подписанный новым закрытым ключом подписи, и сертификат, содержащий новый подписанный открытый ключ. по старому секретному ключу подписи. Оба этих сертификата выдаются самостоятельно, но ни один из них не является самоподписанным . Обратите внимание, что это дополнение к двум самозаверяющим сертификатам (старому и новому).

Поскольку и cert1, и cert3 содержат один и тот же открытый ключ (старый), для cert5 существует две действительные цепочки сертификатов: «cert5 → cert1» и «cert5 → cert3 → cert2», и аналогично для cert6. Это позволяет безразлично доверять старым пользовательским сертификатам (например, cert5) и новым сертификатам (например, cert6) стороне, имеющей либо новый корневой сертификат ЦС, либо старый в качестве якоря доверия во время перехода к новым ключам ЦС.

Образцы сертификатов X.509

Это пример декодированного сертификата X.509, который ранее использовался wikipedia.org и несколькими другими веб-сайтами Википедии. Он был выпущен компанией GlobalSign , как указано в поле «Эмитент». Поле «Тема» описывает Википедию как организацию, а поле «Альтернативное имя субъекта» (SAN) для DNS описывает имена хостов, для которых оно может использоваться. Поле «Информация об открытом ключе субъекта» содержит открытый ключ ECDSA , а подпись внизу была создана с помощью закрытого ключа RSA компании GlobalSign . (Подписи в этих примерах обрезаны.)

Сертификат конечного лица

Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number:
           10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6
       Signature Algorithm: sha256WithRSAEncryption
       Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
       Validity
           Not Before: Nov 21 08:00:00 2016 GMT
           Not After : Nov 22 07:59:59 2017 GMT
       Subject: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org
       Subject Public Key Info:
           Public Key Algorithm: id-ecPublicKey
               Public-Key: (256 bit)
           pub: 
                   00:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:
                   af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:
                   9d:3b:ef
               ASN1 OID: prime256v1
               NIST CURVE: P-256
       X509v3 extensions:
           X509v3 Key Usage: critical
               Digital Signature, Key Agreement
           Authority Information Access: 
               CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
               OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2
           X509v3 Certificate Policies: 
               Policy: 1.3.6.1.4.1.4146.1.20
                 CPS: https://www.globalsign.com/repository/
               Policy: 2.23.140.1.2.2
           X509v3 Basic Constraints: 
               CA:FALSE
           X509v3 CRL Distribution Points: 
               Full Name:
                 URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
           X509v3 Subject Alternative Name: 
               DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org
           X509v3 Extended Key Usage: 
               TLS Web Server Authentication, TLS Web Client Authentication
           X509v3 Subject Key Identifier: 
               28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36
           X509v3 Authority Key Identifier: 
               keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

   Signature Algorithm: sha256WithRSAEncryption
        8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35:
        ...

Чтобы проверить этот сертификат конечного объекта, необходим промежуточный сертификат, который соответствует его эмитенту и идентификатору ключа центра:

Эмитент	C=BE, O=GlobalSign nv-sa, CN=Проверка организации GlobalSign CA – SHA256 – G2
Идентификатор ключа авторизации	96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

При TLS-соединении правильно настроенный сервер будет предоставлять промежуточное соединение как часть рукопожатия. Однако также возможно получить промежуточный сертификат, получив URL-адрес «CA Issuers» из сертификата конечного объекта.

Промежуточный сертификат

Это пример промежуточного сертификата, принадлежащего центру сертификации . Этот сертификат подписал указанный выше сертификат конечного объекта и был подписан корневым сертификатом ниже. Обратите внимание, что поле субъекта этого промежуточного сертификата совпадает с полем эмитента сертификата конечного объекта, который он подписал. Кроме того, поле «идентификатор ключа субъекта» в промежуточном элементе соответствует полю «идентификатор ключа органа» в сертификате конечного объекта.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:44:4e:f0:42:47
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Validity
            Not Before: Feb 20 10:00:00 2014 GMT
            Not After : Feb 20 10:00:00 2024 GMT
        Subject: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Subject Key Identifier:
                96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
            X509v3 Certificate Policies:
                Policy: X509v3 Any Policy
                  CPS: https://www.globalsign.com/repository/

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.globalsign.net/root.crl

            Authority Information Access:
                OCSP - URI:http://ocsp.globalsign.com/rootr1

            X509v3 Authority Key Identifier:
                keyid:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B

    Signature Algorithm: sha256WithRSAEncryption
         46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8:
         ...

Корневой сертификат

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

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:15:4b:5a:c3:94
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Validity
            Not Before: Sep  1 12:00:00 1998 GMT
            Not After : Jan 28 12:00:00 2028 GMT
        Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B
    Signature Algorithm: sha1WithRSAEncryption
         d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:
         ...

Безопасность

О проблемах PKI имеется ряд публикаций Брюса Шнайера , Питера Гутмана и других экспертов по безопасности.

Архитектурные недостатки

• Использование черных списков недействительных сертификатов (с использованием CRL и OCSP ),
  • Если клиент доверяет сертификатам только тогда, когда доступны списки отзыва сертификатов, он теряет возможность работы в автономном режиме, что делает PKI привлекательным. Таким образом, большинство клиентов доверяют сертификатам, когда CRL недоступны, но в этом случае злоумышленник, контролирующий канал связи, может отключить CRL. Адам Лэнгли из Google сказал, что проверки CRL с мягким сбоем подобны ремню безопасности, который срабатывает, за исключением случаев, когда вы попадаете в аварию.
• CRL — особенно плохой выбор из-за больших размеров и запутанных схем распределения.
• Неоднозначная семантика OCSP и отсутствие статуса исторического отзыва.
• Отзыв корневых сертификатов не рассматривается,
• Проблема агрегации . Заявления об идентичности (аутентификация с помощью идентификатора), утверждения об атрибутах (отправка пакета проверенных атрибутов) и утверждения о политике объединяются в одном контейнере. Это поднимает вопросы конфиденциальности, сопоставления политик и обслуживания.
• Проблема делегирования : центры сертификации не могут технически запретить подчиненным центрам сертификации выдавать сертификаты за пределами ограниченного пространства имен или набора атрибутов; эта функция X.509 не используется. Поэтому в Интернете существует большое количество центров сертификации, и классификация их и их политик является непреодолимой задачей. Делегированием полномочий внутри организации вообще нельзя заниматься, как это принято в обычной деловой практике.
• Проблема федерации . Цепочки сертификатов, являющиеся результатом деятельности подчиненных центров сертификации, мостовых центров сертификации и перекрестной подписи, усложняют проверку и требуют больших затрат времени на обработку. Семантика проверки пути может быть неоднозначной. Иерархия со сторонней доверенной стороной является единственной моделью. Это неудобно, когда уже существуют двусторонние доверительные отношения.
• Выдача сертификата расширенной проверки (EV) для имени хоста не предотвращает выдачу сертификата с более низкой проверкой, действительного для того же имени хоста, а это означает, что более высокий уровень проверки EV не защищает от посредника. атаки.

Проблемы с удостоверяющими центрами

• Человек или организация, приобретающие сертификат, часто используют наименее дорогой центр сертификации. В ответ центры сертификации снизили цены и отменили более дорогие проверки в рамках так называемой « гонки ко дну» . Гонка ко дну частично решается с помощью сертификатов расширенной проверки (EV) , однако ценность доверия в глазах экспертов по безопасности снижается. По словам Питера Гутмана , сертификаты EV не добавляют никаких дополнительных мер безопасности. Скорее, сертификаты EV просто восстанавливают прибыль ЦС до уровня, существовавшего до «Гонки ко дну», позволяя ЦС взимать больше за услугу, которую они должны были предоставлять с самого начала.
• Органы по сертификации пытаются отказать пользователю и доверяющим сторонам почти во всех гарантиях в своем Положении о практике сертификации (CPS) . Например, Apple Inc заявляет в своем CPS: «В пределах, разрешенных применимым законодательством, соглашения с подписчиками, если применимо, отказываются от гарантий Apple, включая любые гарантии коммерческой ценности или пригодности для определенной цели».
• По словам Питера Гутманна, «пользователи используют неопределенный протокол запроса на сертификацию для получения сертификата, который публикуется в неизвестном месте в несуществующем каталоге, без каких-либо реальных средств для его отзыва».
• Как и все предприятия, центры сертификации подчиняются правовой юрисдикции, в пределах которой они действуют, и могут быть по закону вынуждены поставить под угрозу интересы своих клиентов и пользователей. Спецслужбы также использовали фальшивые сертификаты, выданные в результате нелегального взлома центров сертификации, таких как DigiNotar , для проведения атак типа «человек посередине» . Другим примером является запрос на отзыв CA правительства Нидерландов из-за принятого в 2018 году закона Нидерландов, дающего новые полномочия голландским службам разведки и безопасности.

Проблемы реализации

Реализации страдают от недостатков проектирования, ошибок, различных интерпретаций стандартов и отсутствия совместимости различных стандартов. Некоторые проблемы:

• Многие реализации отключают проверку отзыва:
  • Политика рассматривается как препятствие и не соблюдается
  • Если бы он был включен во всех браузерах по умолчанию, включая подпись кода, это, вероятно, привело бы к сбою инфраструктуры.
• DN сложны и малопонятны (отсутствие канонизации, проблемы интернационализации)
• rfc822Name имеет две нотации.
• Ограничения имени и политики практически не поддерживаются.
• Использование ключа игнорируется, используется первый сертификат в списке.
• Обеспечение соблюдения пользовательских OID затруднено.
• Атрибуты не следует делать критическими, поскольку это приводит к сбою клиентов.
• Неуказанная длина атрибутов приводит к ограничениям, специфичным для продукта.
• Существуют ошибки реализации X.509, которые позволяют, например, фальсифицировать имена субъектов с использованием строк с нулевым завершением. или атаки путем внедрения кода в сертификаты
• С помощью нелегального 0x80 дополненные субидентификаторы идентификаторов объектов , неправильные реализации или использование целочисленных переполнений браузеров клиента, злоумышленник может включить в CSR неизвестный атрибут, который подпишет ЦС, который клиент ошибочно интерпретирует как «CN» (OID=2.5. 4.3). Дэн Камински продемонстрировал это на 26-м Конгрессе Chaos Communication «Black OPs of PKI».

Криптографические слабости

систем цифровой подписи зависит от безопасных криптографических хэш-функций Работа . Когда инфраструктура открытых ключей позволяет использовать хэш-функцию, которая больше не является безопасной, злоумышленник может использовать слабые места в хеш-функции для подделки сертификатов. В частности, если злоумышленник может создать коллизию хешей , он может убедить центр сертификации подписать сертификат с безобидным содержимым, где хэш этого содержимого идентичен хешу другого вредоносного набора содержимого сертификата, созданного злоумышленником. с ценностями по своему выбору. Затем злоумышленник может добавить подпись, предоставленную центром сертификации, к содержимому своего вредоносного сертификата, в результате чего вредоносный сертификат будет выглядеть подписанным центром сертификации. Поскольку содержимое вредоносного сертификата выбирается исключительно злоумышленником, у него могут быть другие даты действия или имена хостов, чем у безобидного сертификата. Вредоносный сертификат может даже содержать поле «CA: true», позволяющее выдавать дополнительные доверенные сертификаты.

• Сертификаты на основе MD2 использовались долгое время и были уязвимы для атак на прообразы . Поскольку корневой сертификат уже имел собственную подпись, злоумышленники могли использовать эту подпись и использовать ее в качестве промежуточного сертификата.
• В 2005 году Арьен Ленстра и Бенне де Вегер продемонстрировали, «как использовать коллизии хэшей для создания двух сертификатов X.509, которые содержат идентичные подписи и различаются только открытыми ключами», что было достигнуто с помощью атаки коллизий на хеш-функцию MD5 .
• В 2008 году Александр Сотиров и Марк Стивенс представили на Chaos Communication Congress практическую атаку, которая позволила им создать мошеннический центр сертификации, принимаемый всеми распространенными браузерами, используя тот факт, что RapidSSL все еще выдавал сертификаты X.509 на основе MD5.
• В апреле 2009 года на конференции Eurocrypt Австралийские исследователи из Университета Маккуори представили «Автоматический дифференциальный поиск пути для SHA-1 ». Исследователи смогли вывести метод, который увеличивает вероятность столкновения на несколько порядков.
• В феврале 2017 года группа исследователей под руководством Марка Стивенса произвела столкновение SHA-1, продемонстрировав слабость SHA-1.

Устранение уязвимостей в криптографии

Использование коллизии хэшей для подделки подписей X.509 требует, чтобы злоумышленник был в состоянии предсказать данные, которые подпишет центр сертификации. Это можно несколько смягчить, если центр сертификации генерирует случайный компонент в подписываемых им сертификатах, обычно серийный номер. Форум CA/Browser требует энтропии серийных номеров в разделе 7.1 базовых требований с 2011 года.

По состоянию на 1 января 2016 г. , the Baseline Requirements forbid issuance of certificates using SHA-1. As of early 2017, Хром и Фаерфокс отклонять сертификаты, использующие SHA-1. По состоянию на май 2017 г. оба края и Сафари также отклоняют сертификат SHA-1. Небраузерные валидаторы X.509 еще не отклоняют сертификаты SHA-1.

Стандарты PKI для X.509

• PKCS7 (Стандарт синтаксиса криптографических сообщений — открытые ключи с подтверждением личности для подписанного и/или зашифрованного сообщения для PKI)
• Transport Layer Security (TLS) и его предшественник SSL — криптографические протоколы для безопасной связи в Интернете.
• Протокол статуса онлайн-сертификата (OCSP) / список отзыва сертификатов (CRL) — это проверка статуса отзыва сертификата
• PKCS12 (стандарт синтаксиса обмена личной информацией) — используется для хранения закрытого ключа с соответствующим сертификатом открытого ключа.
• RFC   4158 — Построение путей сертификации — руководство и рекомендации по построению путей сертификации с открытым ключом X.509 в приложениях (т. е. проверка сертификата конечного объекта с использованием сертификата CA).

Рабочая группа PKIX

В 1995 году Рабочая группа по разработке Интернета совместно с Национальным институтом стандартов и технологий сформировал рабочую группу по инфраструктуре открытых ключей (X.509). Рабочая группа, завершившая работу в июне 2014 г., обычно называют «PKIX». Он подготовил RFC и другую стандартную документацию по использованию и развертыванию X.509 на практике. В частности, было произведено RFC   3280 и его преемник RFC 5280, которые определяют, как использовать X.509 в интернет-протоколах.

Основные протоколы и стандарты, использующие сертификаты X.509.

TLS/SSL и HTTPS используют Профиль RFC   5280 для X.509, а также S/MIME (безопасные многоцелевые расширения почты Интернета) и метод EAP-TLS для аутентификации Wi-Fi. Любой протокол, использующий TLS, например SMTP, POP, IMAP, LDAP, XMPP и многие другие, по своей сути использует X.509.

IPsec может использовать Профиль RFC   4945 для аутентификации одноранговых узлов.

Спецификация безопасности OpenCable определяет собственный профиль X.509 для использования в кабельной промышленности.

Такие устройства, как смарт-карты и доверенные платформенные модули, часто имеют сертификаты, позволяющие идентифицировать себя или своих владельцев. Эти сертификаты имеют формат X.509.

Стандарт WS-Security определяет аутентификацию либо через TLS, либо через собственный профиль сертификата. Оба метода используют X.509.

Система подписи кода Microsoft Authenticode использует X.509 для идентификации авторов компьютерных программ.

Стандарт связи промышленной автоматизации OPC UA использует X.509.

SSH обычно использует модель безопасности «Доверие при первом использовании» и не требует сертификатов. Однако популярная реализация OpenSSH поддерживает модель идентификации, подписанную центром сертификации, на основе собственного формата сертификата, отличного от X.509.

См. также

• Обозначение абстрактного синтаксиса один
• Политика сертификатов
• Безопасность доступа к коду
• Безопасность связи
• Информационная безопасность
• ИСО/МЭК ОТК 1
• Протокол запроса ресурсов PKI
• Криптография с открытым ключом
• Инфраструктура открытых ключей
• Протокол отметки времени
• Доверенная временная метка
• ЭдДСА

Внешние ссылки

• Стандарты ITU-T X.509
• Статьи Питера Гутмана:
  • Обзор PKI
  • Замечания по реализации X.509 и руководство по стилю
• «Часто задаваемые вопросы по криптовалюте от RSA Labs» . Лаборатории РСА. Архивировано из оригинала 30 декабря 2006 года.
• Рекомендации по безопасному коду Sun
• RFC 4158 - Инфраструктура открытых ключей Internet X.509: построение пути сертификации
• RFC 5280 - Профиль сертификата инфраструктуры открытых ключей Internet X.509 и списка отзыва сертификатов (CRL)
• Декодер CSR и декодер сертификатов — могут использоваться для декодирования и проверки закодированного CSR или сертификата.
• phpseclib: Декодер X.509 — декодирует в ассоциативный массив, ключи которого соответствуют описанию ASN.1 X.509.
• Общие сведения о цифровых сертификатах Microsoft TechNet