X.509

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

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

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

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

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

Версия 3 X.509 включает гибкость для поддержки других топологий, таких как мосты и сетки . ^[2] Он может использоваться в одноранговой сети доверия, подобной OpenPGP , ^{[ требуется ссылка ],} но редко использовался таким образом по состоянию на 2004 год ^{[обновлять]}. Система X.500 была реализована только суверенными государствами ^{[ какими? ]} для целей выполнения договора о совместном использовании информации о государственных идентификаторах, а рабочая группа IETF Public-Key Infrastructure (X.509) (PKIX) адаптировала стандарт к более гибкой организации Интернета. Фактически, термин сертификат X.509 обычно относится к сертификату IETF PKIX и профилю CRL стандарта сертификата X.509 v3, как указано в RFC  5280, обычно называемому PKIX для Public Key Infrastructure (X.509) . ^[4]

Ранней проблемой с Public Key Infrastructure (PKI) и сертификатами X.509 была известная проблема «какой каталог». Проблема в том, что клиент не знает, где получить отсутствующие промежуточные сертификаты, поскольку глобальный каталог X.500 так и не материализовался. Проблема была смягчена путем включения всех промежуточных сертификатов в запрос. Например, ранние веб-серверы отправляли клиенту только сертификат веб-сервера. Клиенты, у которых не было промежуточного сертификата CA или где его найти, не могли построить действительный путь от CA к сертификату сервера. Чтобы обойти эту проблему, веб-серверы теперь отправляют все промежуточные сертификаты вместе с сертификатом веб-сервера. ^[5]

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

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

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

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

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

X.509 и RFC  5280 также включают стандарты для реализаций списков отзыва сертификатов (CRL). Другим одобренным IETF способом проверки действительности сертификата является Online Certificate Status Protocol (OCSP). Firefox 3.0 включил проверку OCSP по умолчанию, как и версии Windows , начиная с Vista и выше. ^[9]

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

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

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

Поле Extensions, если оно присутствует, представляет собой последовательность одного или нескольких расширений сертификата. ^{[10] : §4.1.2.9: Расширения} Каждое расширение имеет свой собственный уникальный идентификатор, выраженный как идентификатор объекта (OID) , который представляет собой набор значений вместе с критическим или некритическим указанием. Система, использующая сертификат, должна отклонить сертификат, если она сталкивается с критическим расширением, которое она не распознает, или критическим расширением, содержащим информацию, которую она не может обработать. Некритическое расширение может быть проигнорировано, если оно не распознано, но должно быть обработано, если оно распознано. ^{[10] : §4.2: Расширения сертификатов}

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

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

ITU-T ввел уникальные идентификаторы эмитента и субъекта в версии 2, чтобы разрешить повторное использование имени эмитента или субъекта через некоторое время. Примером повторного использования может быть банкротство CA и удаление его имени из публичного списка страны. Через некоторое время другой CA с тем же именем может зарегистрироваться, даже если он не связан с первым. Однако IETF рекомендует не использовать повторно имена эмитента и субъекта. Поэтому версия 2 не получила широкого распространения в Интернете. ^{[ необходима цитата ]}

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

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

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

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

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

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

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

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

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

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

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

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

• .pem– ( Электронная почта с повышенной конфиденциальностью ) Сертификат DER в кодировке Base64 , заключенный между и-----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. ^[12]
• .p7r– Ответ PKCS#7 на CSR. Содержит недавно подписанный сертификат и собственный сертификат CA.
• .p7s– Цифровая подпись PKCS#7 . Может содержать исходный подписанный файл или сообщение. Используется в S/MIME для подписи электронной почты. Определено в RFC 2311.
• .p7m– PKCS#7 (SignedData, EnvelopedData) Сообщение, например, зашифрованный («конвертированный») файл, сообщение или письмо электронной почты MIME. Определено в RFC 2311.
• .p7c– PKCS#7 вырожденная структура SignedData "certs-only", без каких-либо данных для подписи. Определено в RFC 2311.
• .p7b, .keystore– Структура PKCS#7 SignedData без данных, только пакет сертификатов и/или 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.

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

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

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

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

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

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

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

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

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

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

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

Это пример расшифрованного сертификата X.509, который использовался в прошлом wikipedia.org и несколькими другими сайтами Wikipedia. Он был выпущен GlobalSign , как указано в поле Issuer. Его поле Subject описывает Wikipedia как организацию, а его поле Subject Alternative Name (SAN) для DNS описывает имена хостов, для которых он может использоваться. Поле Subject Public Key Info содержит открытый ключ ECDSA , в то время как подпись внизу была сгенерирована закрытым ключом RSA GlobalSign . (Подписи в этих примерах усечены.)

Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6 Алгоритм подписи: sha256WithRSAEncryption Эмитент: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Проверка организации CA - SHA256 - G2 Действительность Не раньше: 21 ноября 08:00:00 2016 GMT Не позже: 22 ноября 07:59:59 2017 GMT Тема: C=США, ST=Калифорния, L=Сан-Франциско, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org Информация о публичном ключе субъекта: Алгоритм открытого ключа: id-ecPublicKey Открытый ключ: (256 бит) паб: 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: 9д:3б:эф ASN1 OID: prime256v1 КРИВАЯ NIST: P-256 Расширения X509v3: Использование ключа X509v3: критическое Цифровая подпись, соглашение о ключах Доступ к информации органов власти: Эмитенты CA - URI: http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt OCSP - URI: http://ocsp2.globalsign.com/gsorganizationvalsha2g2 Политики сертификата X509v3: Политика: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ Политика: 2.23.140.1.2.2 Основные ограничения X509v3: КА:ЛОЖЬ Точки распространения CRL X509v3: Полное имя: URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl X509v3 Альтернативное имя субъекта: 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: Аутентификация веб-сервера TLS, Аутентификация веб-клиента TLS Идентификатор ключа субъекта X509v3: 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36 Идентификатор ключа авторизации X509v3: идентификатор ключа:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

 Алгоритм подписи: sha256WithRSAEncryption 8б:в3:ред:д1:9д:39:6е:аф:40:72:бд:1д:18:5д:30:54:23:35: ...

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

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

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

Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 04:00:00:00:00:01:44:4e:f0:42:47 Алгоритм подписи: sha256WithRSAEncryption Эмитент: C=BE, O=GlobalSign nv-sa, OU=Корневой центр сертификации, CN=Корневой центр сертификации GlobalSign Действительность Не раньше: 20 февраля 10:00:00 2014 GMT Не позже: 20 февраля 10:00:00 2024 GMT Тема: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Проверка организации CA - SHA256 - G2 Информация о публичном ключе субъекта: Алгоритм открытого ключа: rsaEncryption Открытый ключ: (2048 бит) Модуль: 00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e: ... Экспонента: 65537 (0x10001) Расширения X509v3: Использование ключа X509v3: критическое Знак сертификата, знак CRL Основные ограничения X509v3: критические CA:TRUE, pathlen:0 Идентификатор ключа субъекта X509v3: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C Политики сертификата X509v3: Политика: X509v3 Любая политика CPS: https://www.globalsign.com/repository/ Точки распространения CRL X509v3: Полное имя: URI:http://crl.globalsign.net/root.crl Доступ к информации органов власти: OCSP - URI: http://ocsp.globalsign.com/rootr1 Идентификатор ключа авторизации X509v3: идентификатор ключа:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Алгоритм подписи: sha256WithRSAEncryption 46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8: ...

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

Сертификат: [16] Данные: Версия: 3 (0x2) Серийный номер: 04:00:00:00:00:01:15:4b:5a:c3:94 Алгоритм подписи: sha1WithRSAEncryption Эмитент: C=BE, O=GlobalSign nv-sa, OU=Корневой центр сертификации, CN=Корневой центр сертификации GlobalSign Действительность Не раньше: 1 сентября 12:00:00 1998 GMT Не позже: 28 января 12:00:00 2028 GMT Тема: C=BE, O=GlobalSign nv-sa, OU=Корневой центр сертификации, CN=Корневой центр сертификации GlobalSign Информация о публичном ключе субъекта: Алгоритм открытого ключа: rsaEncryption Открытый ключ: (2048 бит) Модуль: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: ... Экспонента: 65537 (0x10001) Расширения X509v3: Использование ключа X509v3: критическое Знак сертификата, знак CRL Основные ограничения X509v3: критические КА:ИСТИНА Идентификатор ключа субъекта X509v3: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Алгоритм подписи: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5: ...

Существует ряд публикаций о проблемах PKI, написанных Брюсом Шнайером , Питером Гутманном и другими экспертами по безопасности. ^{[17] [18] [19]}

• Использование блокирования недействительных сертификатов (с использованием CRL и OCSP ),
  • Если клиент доверяет сертификатам только при наличии CRL, то он теряет возможность офлайн, которая делает PKI привлекательной. Поэтому большинство клиентов доверяют сертификатам, когда CRL недоступны, но в этом случае злоумышленник, контролирующий канал связи, может отключить CRL. Адам Лэнгли из Google сказал, что проверки CRL с мягким отказом похожи на ремень безопасности, который работает, если только вы не попали в аварию. ^[20]
• CRL являются особенно неудачным выбором из-за больших размеров и запутанных схем распределения,
• Неоднозначная семантика OCSP и отсутствие исторического статуса отзыва,
• Отзыв корневых сертификатов не рассматривается,
• Проблема агрегации : Идентификационные требования (аутентификация с помощью идентификатора), атрибутные требования (отправка пакета проверенных атрибутов) и требования политики объединены в одном контейнере. Это поднимает вопросы конфиденциальности, сопоставления политик и обслуживания. ^{[ необходимо разъяснение ]}
• Проблема делегирования : CA не могут технически ограничить подчиненные CA от выдачи сертификатов за пределами ограниченного пространства имен или набора атрибутов; эта функция X.509 не используется. Поэтому в Интернете существует большое количество CA, и их классификация и их политики является непреодолимой задачей. Делегирование полномочий внутри организации вообще не может быть выполнено, как в обычной деловой практике. ^{[21] [ неудавшаяся проверка ]}
• Проблема федерации : цепочки сертификатов, которые являются результатом подчиненных CA, мостовых CA и перекрестной подписи, делают проверку сложной и дорогой с точки зрения времени обработки. Семантика проверки пути может быть неоднозначной. Иерархия со сторонней доверенной стороной является единственной моделью. Это неудобно, когда двусторонние доверительные отношения уже существуют.
• Выдача сертификата с расширенной проверкой (EV) для имени хоста не препятствует выдаче сертификата с более низкой проверкой, действительного для того же имени хоста, что означает, что более высокий уровень проверки EV не защищает от атак типа «человек посередине». ^[22]

• Лицо или организация, которые покупают сертификат, часто используют наименее дорогой центр сертификации. В ответ на это центры сертификации снизили цены и убрали более дорогие проверки валидности в так называемой « гонке на дно» . «Гонка на дно» частично решается сертификатами расширенной проверки (EV) , однако ценность доверия в глазах экспертов по безопасности снижается. ^[23] По словам Питера Гутмана , сертификаты EV не добавляют никаких дополнительных мер безопасности. Скорее, сертификаты EV просто восстанавливают прибыль центра сертификации до уровня, предшествовавшего «гонке на дно», позволяя центру сертификации взимать больше за услугу, которую он должен был предоставлять все это время. ^[5]
• Сертификационные органы пытаются отказать почти во всех гарантиях пользователю и полагающимся сторонам в своем Заявлении о практике сертификации (CPS) . Например, Apple Inc заявляет в своем CPS: «В той мере, в какой это допускается применимым законодательством, соглашения с подписчиками, если применимо, отказываются от гарантий от Apple, включая любые гарантии товарной пригодности или пригодности для определенной цели». ^[24]
• По словам Питера Гутмана, «пользователи используют неопределенный протокол запроса сертификации для получения сертификата, который публикуется в неизвестном месте в несуществующем каталоге, без каких-либо реальных средств его отзыва» ^[19]
• Как и все предприятия, центры сертификации подчиняются правовым юрисдикциям, в которых они работают, и могут быть юридически вынуждены пойти на компромисс с интересами своих клиентов и пользователей. Разведывательные агентства также использовали поддельные сертификаты, выпущенные путем внесудебного взлома центров сертификации, таких как DigiNotar , для проведения атак типа «человек посередине» . ^{[ требуется цитата ]} Другим примером является запрос на отзыв сертификата центра сертификации голландского правительства из-за голландского закона, принятого в 2018 году, который предоставил новые полномочия голландским службам разведки и безопасности ^[25]

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

• Во многих реализациях проверка отзыва отключена:
  • Рассматривается как препятствие, политика не применяется
  • Если бы он был включен во всех браузерах по умолчанию, включая подпись кода, это, вероятно, привело бы к краху инфраструктуры.
• DN сложны и малопонятны (отсутствие канонизации, проблемы интернационализации)
• rfc822Name имеет две нотации
• Ограничения по имени и политике практически не поддерживаются
• Использование ключа игнорируется, используется первый сертификат в списке
• Обеспечение соблюдения пользовательских OID затруднено
• Атрибуты не следует делать критическими, так как это приводит к сбою клиентов.
• Неопределенная длина атрибутов приводит к ограничениям, связанным с конкретным продуктом
• Существуют ошибки реализации X.509, которые позволяют, например, фальсифицировать имена субъектов с использованием строк с завершающим нулем ^[26] или проводить атаки с внедрением кода в сертификаты.
• Используя незаконные ^[27] 0x80 дополненные подидентификаторы идентификаторов объектов , неправильные реализации или используя целочисленные переполнения браузеров клиента, злоумышленник может включить неизвестный атрибут в CSR, который CA подпишет, что клиент ошибочно интерпретирует как "CN" (OID=2.5.4.3). Дэн Камински продемонстрировал это на 26-м конгрессе Chaos Communication "Черные OP PKI" ^[28]

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

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

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

С 1 января 2016 года ^{[обновлять]}Базовые требования запрещают выдачу сертификатов, использующих SHA-1. С начала 2017 года ^{[обновлять]}Chrome ^[36] и Firefox ^[37] отклоняют сертификаты, использующие SHA-1. С мая 2017 года ^{[обновлять]}Edge ^[38] и Safari ^[39] также отклоняют сертификаты SHA-1. Валидаторы X.509, не являющиеся браузерами, пока не отклоняют сертификаты SHA-1. ^[40]

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

В 1995 году Internet Engineering Task Force совместно с Национальным институтом стандартов и технологий ^[45] сформировали рабочую группу Public-Key Infrastructure (X.509). Рабочая группа, завершившая свою работу в июне 2014 года, ^[46] обычно называется «PKIX». Она выпустила RFC и другую документацию по стандартам использования и развертывания X.509 на практике. В частности, она выпустила RFC  3280 и его преемник RFC 5280, которые определяют, как использовать X.509 в интернет-протоколах.

TLS/SSL и HTTPS используют профиль RFC  5280 X.509, как и S/MIME (Secure Multipurpose Internet Mail Extensions) и метод EAP-TLS для аутентификации WiFi. Любой протокол, использующий TLS, например SMTP, POP, IMAP, LDAP, XMPP и многие другие, по своей сути использует X.509.

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

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

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

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

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

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

SSH обычно использует модель безопасности Trust On First Use и не нуждается в сертификатах. Однако популярная реализация OpenSSH поддерживает модель идентификации, подписанную CA, на основе собственного формата сертификата, отличного от X.509. ^[47]

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

• Стандарты X.509 ITU-T
• Статьи Питера Гутмана:
  • Обзор PKI
  • Заметки о внедрении X.509 и руководство по стилю
• "Crypto FAQ от RSA Labs". RSA Laboratories. Архивировано из оригинала 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