В криптографии X.509 — это стандарт Международного союза электросвязи (ITU) , определяющий формат сертификатов открытых ключей . [1] Сертификаты X.509 используются во многих интернет-протоколах, включая TLS/SSL , который является основой HTTPS , [2] безопасного протокола для просмотра веб-страниц . Они также используются в автономных приложениях, таких как электронные подписи . [3]
Сертификат 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 включает гибкую поддержку других топологий, таких как мосты и ячеистые сети . [2] Его можно использовать в одноранговой сети доверия, подобной OpenPGP , [ нужна цитация ] , но с 2004 года он использовался таким образом редко [обновлять]. Система X.500 была внедрена только суверенными государствами [ какими? ] для целей выполнения договора о совместном использовании идентификационной информации штата, а рабочая группа IETF по инфраструктуре открытых ключей (X.509) (PKIX) адаптировала стандарт для более гибкой организации Интернета. Фактически, термин «сертификат X.509» обычно относится к сертификату PKIX IETF и профилю CRL стандарта сертификата X.509 v3, как указано в RFC 5280, обычно называемому PKIX для инфраструктуры открытых ключей (X.509) . [4]
Одной из первых проблем с инфраструктурой открытых ключей (PKI) и сертификатами X.509 была хорошо известная проблема «какого каталога». Проблема в том, что клиент не знает, где взять недостающие промежуточные сертификаты, поскольку глобальный каталог X.500 так и не появился. Проблема была устранена за счет включения в запрос всех промежуточных сертификатов. Например, ранние веб-серверы отправляли клиенту только сертификат веб-сервера. Клиентам, у которых не было промежуточного сертификата ЦС или места его обнаружения, не удалось построить действительный путь от ЦС к сертификату сервера. Чтобы обойти эту проблему, веб-серверы теперь отправляют все промежуточные сертификаты вместе с сертификатом веб-сервера. [5]
Хотя PKIX относится к стандарту PKI IETF или Интернета, существует множество других PKI с другой политикой. Например, правительство США имеет собственную PKI со своей собственной политикой, а CA/Browser Forum имеет собственную PKI со своей собственной политикой. PKI правительства США представляет собой огромную книгу объемом более 2500 страниц. Если PKI организации слишком сильно отличается от IETF или CA/Browser Forum, то организация рискует потерять совместимость с распространенными инструментами, такими как веб-браузеры , cURL и Wget . Например, если PKI имеет политику выдачи сертификатов только в понедельник, то обычные инструменты, такие как cURL и Wget, не будут применять эту политику и разрешать выдачу сертификата во вторник. [5]
Сертификаты 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, содержащий список включенных центров сертификации. [8]
X.509 и RFC 5280 также включают стандарты для реализации списка отзыва сертификатов (CRL). Еще одним одобренным IETF способом проверки действительности сертификата является протокол онлайн-статуса сертификата (OCSP). Firefox 3.0 включил проверку OCSP по умолчанию, как и версии Windows , начиная с Vista и выше. [9]
Структура, предусмотренная стандартами, выражается на формальном языке, абстрактной синтаксической нотации один (ASN.1).
Структура цифрового сертификата X.509 v3 следующая:
Поле «Расширения», если оно присутствует, представляет собой последовательность одного или нескольких расширений сертификата. [10] Каждое расширение имеет свой собственный уникальный идентификатор, выраженный как идентификатор объекта (OID) , который представляет собой набор значений вместе с критическим или некритическим индикатором. Система, использующая сертификат, должна отклонить сертификат, если она встретит критическое расширение, которое она не распознает, или критическое расширение, содержащее информацию, которую она не может обработать. Некритическое расширение может быть проигнорировано, если оно не распознано, но должно быть обработано, если оно распознано. [11]
Структура версии 1 приведена в RFC 1422.
Внутренний формат уникальных идентификаторов эмитента и субъекта, указанный в рекомендации X.520 «Справочник: выбранные типы атрибутов».
МСЭ-Т ввел уникальные идентификаторы эмитента и субъекта в версии 2, чтобы разрешить повторное использование имени эмитента или субъекта через некоторое время. Примером повторного использования может служить ситуация, когда ЦС обанкротится и его название будет удалено из общедоступного списка страны. Через некоторое время может зарегистрироваться другой центр сертификации с таким же именем, даже если он не связан с первым. Однако IETF не рекомендует повторно использовать имена издателя и субъекта. Поэтому версия 2 не получила широкого распространения в Интернете. [ нужна цитата ]
Расширения были представлены в версии 3. Центр сертификации может использовать расширения для выдачи сертификата только для определенной цели (например, только для подписи цифровых объектов ).
Во всех версиях серийный номер должен быть уникальным для каждого сертификата, выданного конкретным центром сертификации (как указано в RFC 5280).
RFC 5280 (и его предшественники) определяет ряд расширений сертификата, которые указывают, как следует использовать сертификат. Большинство из них — это дуги из joint-iso-ccitt(2) ds(5) id-ce(29)OID. Некоторые из наиболее распространенных, определенных в разделе 4.2.1, включают:
{ id-ce 19 }, [12] используются для указания того, является ли сертификат сертификатом CA и может ли он сертифицировать или выдавать другие сертификаты. Ограничение можно пометить как критическое. Если ограничение помечено как критическое, то агенту не удастся обработать сертификат, если агент не понимает ограничение. Агент может продолжать обрабатывать некритическое ограничение, которое он не понимает.{ id-ce 15 }[ 13] предоставляет растровое изображение, определяющее криптографические операции, которые могут быть выполнены с использованием открытого ключа, содержащегося в сертификате; например, это может указывать на то, что ключ следует использовать для подписей, а не для шифрования.{ id-ce 37 }[ 14] обычно используется в листовом сертификате для указания назначения открытого ключа, содержащегося в сертификате. Он содержит список OID, каждый из которых указывает разрешенное использование. Например, { id-pkix 3 1 }указывает, что ключ может использоваться на стороне сервера соединения TLS или SSL; { id-pkix 3 4 }указывает, что ключ может использоваться для защиты электронной почты.Обычно при использовании RFC 5280, если сертификат имеет несколько расширений, ограничивающих его использование, все ограничения должны быть соблюдены, чтобы данное использование было подходящим. В RFC приводится конкретный пример сертификата, содержащего как keyUsage, так и ExtendedKeyUsage: в этом случае оба расширения должны быть обработаны, а сертификат можно использовать только в том случае, если оба расширения согласованы в определении использования сертификата. Например, NSS использует оба расширения для указания использования сертификата. [15]
Центры сертификации, работающие в рамках PKI CA/Browser Forum, выдают сертификаты с различными уровнями проверки. Различные проверки обеспечивают разные уровни уверенности в том, что сертификат представляет то, что он должен. Например, веб-сервер может быть проверен на самом низком уровне гарантий с помощью электронного письма под названием « Проверка домена» (DV) . Или веб-сервер можно проверить на более высоком уровне гарантий, используя более подробные методы, называемые расширенной проверкой (EV) .
На практике сертификат DV означает, что сертификат был выдан для домена, например, example.comпосле того, как кто-то ответил на электронное письмо, отправленное на адрес [email protected]. Сертификат EV означает, что сертификат был выдан для домена, такого как example.com, и такая компания, как Пример, LLC, является владельцем домена, и владелец был подтвержден Уставом корпорации .
Расширенная проверка не добавляет никаких дополнительных элементов управления безопасностью, поэтому настройка безопасного канала с использованием сертификата EV не является «более надежной», чем настройка канала с использованием другого уровня проверки, например DV.
Расширенная проверка обозначается в сертификате с использованием расширения X.509 v3. Каждый центр сертификации использует свой идентификатор объекта (OID) для подтверждения расширенной проверки. Не существует единого OID для обозначения расширенной проверки, что усложняет программирование пользовательского агента. Каждый пользовательский агент должен иметь список OID, указывающий расширенную проверку.
PKI CA/Browser Forum распознает расширенную проверку, и многие браузеры предоставляют пользователю визуальную обратную связь, указывающую, что сайт предоставляет сертификат EV. Другие PKI, такие как PKI Интернета (PKIX), не придают особого значения расширенной проверке. Инструменты, использующие политики PKIX, такие как cURL и Wget, просто рассматривают сертификат EV как любой другой сертификат.
Эксперт по безопасности Питер Гутманн утверждает, что 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. [16].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 обмена личной информацией , предшественник PKCS#12 (обычно содержит данные в формате PKCS#12, например, с файлами PFX, созданными в .pfxIIS ) ..crl- Список отзыва сертификатов (CRL). Центры сертификации создают их как способ деавторизации сертификатов до истечения срока их действия.PKCS#7 — это стандарт подписи или шифрования (официально называемого «обертыванием») данных. Поскольку сертификат необходим для проверки подписанных данных, их можно включить в структуру SignedData.
Цепочка сертификатов (см. эквивалентную концепцию «пути сертификации», определенную в разделе 3.2 RFC 5280) — это список сертификатов (обычно начинающихся с сертификата конечного объекта), за которым следуют один или несколько сертификатов CA (обычно последний из них является собственным). -подписанный сертификат), со следующими свойствами:
Цепочки сертификатов используются для проверки того, что открытый ключ (PK), содержащийся в целевом сертификате (первый сертификат в цепочке), и другие данные, содержащиеся в нем, действительно принадлежат его субъекту. Чтобы убедиться в этом, подпись целевого сертификата проверяется с использованием ПК, содержащегося в следующем сертификате, подпись которого проверяется с использованием следующего сертификата, и так далее, пока не будет достигнут последний сертификат в цепочке. Поскольку последний сертификат является якорем доверия, его успешное получение докажет, что целевому сертификату можно доверять.
Описание в предыдущем абзаце представляет собой упрощенный взгляд на процесс проверки пути сертификации , определенный в разделе 6 RFC 5280, который включает в себя дополнительные проверки, такие как проверка дат действия сертификатов, поиск CRL и т. д.
Изучая, как строятся и проверяются цепочки сертификатов, важно отметить, что конкретный сертификат может быть частью очень разных цепочек сертификатов (все они действительны). Это связано с тем, что несколько сертификатов ЦС могут быть созданы для одного и того же субъекта и открытого ключа, но подписаны разными закрытыми ключами (от разных ЦС или разными закрытыми ключами от одного и того же ЦС). Таким образом, хотя один сертификат X.509 может иметь только одного эмитента и одну подпись ЦС, он может быть правильно связан с несколькими сертификатами, создавая совершенно разные цепочки сертификатов. Это имеет решающее значение для перекрестной сертификации между PKI и другими приложениями. [17] См. следующие примеры:
На этих диаграммах:
Чтобы обеспечить доверие сертификатам пользователей, существующим в PKI 2 (например, «Пользователь 2»), со стороны PKI 1, CA1 генерирует сертификат (cert2.1), содержащий открытый ключ CA2. [18] Теперь оба сертификата «cert2» и «cert2.1» (отмечены зеленым) имеют один и тот же субъект и открытый ключ, поэтому для cert2.2 (Пользователь 2) существуют две действительные цепочки: «cert2.2 → cert2» и «cert2.2». → сертификат2.1 → сертификат1».
Аналогичным образом CA2 может создать сертификат (cert1.1), содержащий открытый ключ CA1, чтобы сертификаты пользователей, существующие в PKI 1 (например, «Пользователь 1»), были доверенными для PKI 2.
Понимание построения пути сертификации (PDF) . Форум PKI. Сентябрь 2002 г. Чтобы обеспечить плавный переход от старой пары ключей подписи к новой паре ключей подписи, центр сертификации должен выдать сертификат, содержащий старый открытый ключ, подписанный новым закрытым ключом подписи, и сертификат, содержащий новый подписанный открытый ключ. по старому секретному ключу подписи. Оба этих сертификата выдаются самостоятельно, но ни один из них не является самоподписанным . Обратите внимание, что это дополнение к двум самозаверяющим сертификатам (старому и новому).
Поскольку и cert1, и cert3 содержат один и тот же открытый ключ (старый), для cert5 существует две действительные цепочки сертификатов: «cert5 → cert1» и «cert5 → cert3 → cert2», и аналогично для cert6. Это позволяет безразлично доверять старым пользовательским сертификатам (например, cert5) и новым сертификатам (например, cert6) стороне, имеющей либо новый корневой сертификат ЦС, либо старый в качестве якоря доверия во время перехода к новым ключам ЦС. [19]
Это пример декодированного сертификата X.509, который ранее использовался wikipedia.org и несколькими другими веб-сайтами Википедии. Он был выпущен компанией GlobalSign , как указано в поле «Эмитент». Поле «Тема» описывает Википедию как организацию, а поле «Альтернативное имя субъекта» (SAN) для DNS описывает имена хостов, для которых оно может использоваться. Поле «Информация об открытом ключе субъекта» содержит открытый ключ 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 г. по Гринвичу Не после: 22 ноября 07:59:59 2017 г. по Гринвичу Тема: 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б:эф OID ASN1: prime256v1 КРИВАЯ НИСТ: P-256 Расширения X509v3: Использование ключа X509v3: критическое Цифровая подпись, Ключевое соглашение Доступ к информации органов власти: Эмитенты ЦС — 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: keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
Алгоритм подписи: sha256WithRSAEncryption 8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e: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 г. по Гринвичу Не после: 20 февраля 10:00:00 2024 г. по Гринвичу Тема: 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: критические КА:ИСТИНА, путь: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. В противном случае сертификат конечного объекта считается недоверенным.
Сертификат: [20] Данные: Версия: 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 г. Не после: 28 января 12:00:00 2028 г. по Гринвичу Тема: 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 имеется ряд публикаций Брюса Шнайера , Питера Гутмана и других экспертов по безопасности. [21] [22] [23]
Реализации страдают от недостатков проектирования, ошибок, различных интерпретаций стандартов и отсутствия совместимости различных стандартов. Некоторые проблемы:
Работа систем цифровой подписи зависит от безопасных криптографических хеш-функций . Когда инфраструктура открытых ключей позволяет использовать хэш-функцию, которая больше не является безопасной, злоумышленник может использовать слабые места в хеш-функции для подделки сертификатов. В частности, если злоумышленник может создать коллизию хешей , он может убедить центр сертификации подписать сертификат с безобидным содержимым, где хэш этого содержимого идентичен хешу другого вредоносного набора содержимого сертификата, созданного злоумышленником. с ценностями по своему выбору. Затем злоумышленник может добавить подпись, предоставленную центром сертификации, к содержимому своего вредоносного сертификата, в результате чего вредоносный сертификат будет выглядеть подписанным центром сертификации. Поскольку содержимое вредоносного сертификата выбирается исключительно злоумышленником, у него могут быть другие даты действия или имена хостов, чем у безобидного сертификата. Вредоносный сертификат может даже содержать поле «CA: true», позволяющее выдавать дополнительные доверенные сертификаты.
Использование коллизии хэшей для подделки подписей X.509 требует, чтобы злоумышленник был в состоянии предсказать данные, которые подпишет центр сертификации. Это можно несколько смягчить, если центр сертификации генерирует случайный компонент в подписываемых им сертификатах, обычно серийный номер. Форум CA /браузера требует энтропии серийных номеров в разделе 7.1 базовых требований с 2011 года. [39]
С 1 января 2016 года [обновлять]Базовые требования запрещают выдачу сертификатов с использованием SHA-1. По состоянию на начало 2017 года [обновлять]Chrome [40] и Firefox [41] отклоняют сертификаты, использующие SHA-1. По состоянию на май 2017 года [обновлять]Edge [42] и Safari [43] также отклоняют сертификат SHA-1. Небраузерные валидаторы X.509 еще не отклоняют сертификаты SHA-1. [44]
В 1995 году Инженерная группа Интернета совместно с Национальным институтом стандартов и технологий [50] сформировала рабочую группу по инфраструктуре открытых ключей (X.509). Рабочая группа, созданная в июне 2014 года [51] , обычно называется «PKIX». Он подготовил RFC и другую стандартную документацию по использованию и развертыванию X.509 на практике. В частности, он выпустил RFC 3280 и его преемник RFC 5280, которые определяют, как использовать 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, либо через собственный профиль сертификата. [20] Оба метода используют X.509.
Система подписи кода Microsoft Authenticode использует X.509 для идентификации авторов компьютерных программ.
Стандарт связи промышленной автоматизации OPC UA использует X.509.
SSH обычно использует модель безопасности «Доверие при первом использовании» и не требует сертификатов. Однако популярная реализация OpenSSH поддерживает модель идентификации, подписанную центром сертификации, на основе собственного формата сертификата, отличного от X.509. [52]
Ниже приводится упрощенное представление архитектурной модели, принятой инфраструктурой открытых ключей с использованием спецификаций X.509 (PKIX).
{{cite journal}}: Требуется цитировать журнал |journal=( помощь ){{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка ) В эту статью включен текст из этого источника, доступного по лицензии CC BY-SA 2.5.