Войти
| Информационные технологии - Взаимодействие открытых систем - Справочник: структуры сертификатов открытых ключей и атрибутов | |
| Статус | Действует |
|---|---|
| Год начала | 1988 |
| Последняя версия | (19.10). Октябрь 2019 |
| Организация | ITU -T |
| Комитет | |
| Базовые стандарты | ASN.1 |
| Связанные стандарты | X.500 |
| Домен | Криптография |
| Веб-сайт | https: //www.itu.int / rec / T-REC-X.509 |
В криптографии, X.509 - это стандарт, определяющий формат сертификатов открытого ключа. Сертификаты X.509 используются во многих интернет-протоколах, включая TLS / SSL, который является основой HTTPS, безопасного протокола для просмотра сети. Они также используются в автономных приложениях, например, электронные подписи. Сертификат X.509 содержит открытый ключ и идентификатор (имя хоста, или организацию, или отдельное лицо) и подписан либо центром сертификации , либо самозаверяющим. Когда сертификат подписан доверенным центром сертификации или подтвержден другими способами, кто-либо, владеющий этим сертификатом, может полагаться на открытый ключ, который он содержит, для установления защищенной связи с другой стороной или проверки документов с цифровой подписью соответствующий закрытый ключ.
X.509 также определяет списки отзыва сертификатов, которые являются средством распространения информации о сертификатах, которые были признаны недействительными органом подписи, а также алгоритм проверки пути сертификации, который позволяет подписывать сертификаты промежуточными сертификатами ЦС, которые, в свою очередь, подписываются другими сертификатами, в конечном итоге достигая якоря доверия .
X.509 определяется тегом «Сектор стандартизации» Международного союза электросвязи (ITU-T ), основанный на ASN.1, другом стандарте ITU-T.
X.509 был первоначально выпущен 3 июля 1988 г. и был начат в связи с X.500 стандарт. Это предполагает строгую иерархическую систему центров сертификации (CA) для выдачи сертификатов. Это контрастирует с моделями сети доверия, такими как 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).
В системе X.509 организация, которой нужен подписанный сертификат, запрашивает его через запрос подписи сертификата ( CSR).
Для этого он сначала генерирует пару ключей , сохраняя секретный ключ в секрете и используя его для подписи CSR. Он содержит информацию, идентифицирующую заявителя, и его открытый ключ , который используется для проверки подписи CSR - и отличительное имя (DN), для которого предназначен сертификат. CSR может сопровождаться другими учетными данными или доказательствами личности, требуемыми центром сертификации.
Центр сертификации выдает сертификат, связывающий открытый ключ с конкретным отличительным именем.
Доверенные корневые сертификаты организации могут быть распространены среди всех сотрудников чтобы они могли использовать систему PKI компании. Такие браузеры, как Internet Explorer, Firefox, Opera, Safari и Chrome, поставляются с заранее определенным набором корневых предварительно установленные сертификаты, поэтому сертификаты SSL от основных центров сертификации будут работать мгновенно; по сути, разработчики браузеров определяют, какие центры сертификации являются доверенными третьими сторонами для пользователей браузеров. Например, Firefox предоставляет файл CSV и / или HTML, содержащий список включенных центров сертификации.
X.509 и RFC 5280 также включают стандарты для сертификатов списка отзыва (CRL) реализации. Другой одобренный IETF способ проверки действительности сертификата - это Online Certificate Status Protocol (OCSP). Firefox 3 включает проверку OCSP по умолчанию, как и версии Windows, начиная с Vista и более поздних.
Структура, предусмотренная стандартами, выражена на формальном языке, Абстрактная синтаксическая нотация один (ASN.1).
Структура цифрового сертификата X.509 v3 выглядит следующим образом:
Каждое расширение имеет свой собственный идентификатор, выраженный как идентификатор объекта, который представляет собой набор значения вместе с критическим или некритическим показателем. Система, использующая сертификат, должна отклонить сертификат, если она обнаруживает критическое расширение, которое она не распознает, или критическое расширение, которое содержит информацию, которую она не может обработать. Некритическое расширение может быть проигнорировано, если оно не распознано, но должно быть обработано, если оно распознано.
Структура версии 1 приведена в RFC 1422.
Представлен ITU-T уникальные идентификаторы издателя и субъекта в версии 2, чтобы разрешить повторное использование имени эмитента или субъекта через некоторое время. Примером повторного использования может быть ситуация, когда CA обанкротится и его имя будет удалено из общедоступного списка страны. Через некоторое время другой ЦС с тем же именем может зарегистрироваться, даже если он не связан с первым. Однако IETF рекомендует не использовать повторно имена издателя и субъектов. Поэтому версия 2 не получила широкого распространения в Интернете.
В версии 3 были введены расширения. ЦС может использовать расширения для выдачи сертификата только для определенной цели (например, только для подписи цифровых объектов ).
Во всех версиях серийный номер должен быть уникальным для каждого сертификата, выданного конкретным ЦС (как указано в RFC 5280).
RFC 5280 (и его предшественники) определяет ряд расширений сертификатов, которые указывают, как следует использовать сертификат. Большинство из них являются дугами из Joint-iso-ccitt (2) ds (5) id-ce (29)OID. Некоторые из наиболее распространенных, определенных в разделе 4.2.1, следующие:
В общем, если сертификат имеет несколько расширений, ограничивающих его использование, все ограничения должны быть выполнены для данного использования для быть подходящим. RFC 5280 дает конкретный пример сертификата, содержащего как keyUsage, так и extendedKeyUsage: в этом случае оба должны быть обработаны, и сертификат может использоваться только в том случае, если оба расширения согласованы с указанием использования сертификата. Например, NSS использует оба расширения для определения использования сертификата.
Существует несколько часто используемых расширений имени файла для сертификатов X.509. К сожалению, некоторые из этих расширений также используются для других данных, таких как закрытые ключи.
PKCS # 7 - это стандарт для подписи или шифрования (официально называемого «конвертирующим») данных. Поскольку сертификат необходим для проверки подписанных данных, их можно включить в структуру SignedData. A . Файл P7Cпредставляет собой вырожденную структуру SignedData без каких-либо данных для подписи.
PKCS # 12 эволюционировал из стандарта обмена личной информацией (PFX) и используется для обмена общедоступными и частными объектами в одном файле.
A цепочка сертификатов (см. эквивалентную концепцию " путь сертификации ", определенный в RFC 5280 ), представляет собой список сертификатов (обычно начинающийся с сертификата конечного объекта), за которым следует один или несколько сертификатов CA (обычно последний из них является собственным -подписанный сертификат) со следующими свойствами:
Цепочки сертификатов используются для проверки того, что открытый ключ (PK), содержащийся в целевом сертификате (первый сертификат в цепочке), и другие данные, содержащиеся в нем, действительно принадлежат его субъекту. Чтобы убедиться в этом, подпись на целевом сертификате проверяется с помощью PK, содержащегося в следующем сертификате, подпись которого проверяется с помощью следующего сертификата, и так далее, пока не будет достигнут последний сертификат в цепочке. Поскольку последний сертификат является якорем доверия, его успешное получение доказывает, что целевому сертификату можно доверять.
Описание в предыдущем абзаце представляет собой упрощенный взгляд на процесс проверки пути сертификации, как определено в RFC 5280, который включает дополнительные проверки, такие как проверка сроков действия. по сертификатам, поиск CRL и т. д.
Пример 1: Перекрестная сертификация между двумя PKI 
Пример 2: Обновление сертификата CA Изучение того, как строятся и проверяются цепочки сертификатов, это Важно отметить, что конкретный сертификат может быть частью очень разных цепочек сертификатов (все они действительны). Это связано с тем, что несколько сертификатов CA могут быть сгенерированы для одного и того же субъекта и открытого ключа, но подписаны разными закрытыми ключами (от разных CA или разными закрытыми ключами от одного CA). Таким образом, хотя у одного сертификата X.509 может быть только один издатель и одна подпись CA, он может быть корректно связан с более чем одним сертификатом, создавая совершенно разные цепочки сертификатов. Это очень важно для перекрестной сертификации между PKI и другими приложениями. См. Следующие примеры:
На этих схемах:
Чтобы управлять сертификатами пользователей, существующими в PKI 2 (например, «Пользователь 2»), доверенные PKI 1, CA1 генерирует сертификат ( cert2.1), содержащий открытый ключ CA2. Теперь и «cert2», и «cert2.1» (обозначены зеленым цветом) имеют один и тот же субъект и открытый ключ, поэтому есть две допустимые цепочки для cert2.2 (пользователь 2): «cert2.2 → cert2» и «cert2.2 → cert2». 1 → cert1 ".
Точно так же CA2 может сгенерировать сертификат (cert1.1), содержащий открытый ключ CA1, чтобы сертификаты пользователей, существующие в PKI 1 (например," User 1 "), были доверенными для PKI 2.
Общие сведения о построении пути сертификации (PDF). Форум PKI. Сентябрь 2002 г. Обеспечение плавного перехода от старой пары ключей подписи к новой подписи пары ключей, ЦС должен выдать сертификат, содержащий старый открытый ключ, подписанный новым закрытым ключом подписи, и сертификат, содержащий новый открытый ключ, подписанный старым закрытым ключом подписи. Оба эти сертификата выдаются самостоятельно, но ни один из них самоподписанный. Обратите внимание, что они являются дополнением к двум самоподписанным сертификатам (один старый, один новый).
Поскольку и cert1, и cert3 содержат одинаковые публикации c (старый) существуют две действующие цепочки сертификатов для cert5: «cert5 → cert1» и «cert5 → cert3 → cert2», и аналогично для cert6. Это позволяет безразлично доверять старым сертификатам пользователя (например, cert5) и новым сертификатам (например, cert6) сторона, имеющая либо новый корневой сертификат CA, либо старый в качестве якоря доверия во время перехода к новым ключам CA.
Это пример декодированного сертификата X.509, который использовался wikipedia.org и несколькими другими веб-сайтами Википедии. Он был выдан GlobalSign, как указано в поле «Эмитент». Его поле «Тема» описывает Википедию как организацию, а поле «Альтернативное имя субъекта» описывает имена хостов, для которых он может использоваться. Поле «Информация об открытом ключе субъекта» содержит открытый ключ 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 г. по Гринвичу Тема: C = США, ST = Калифорния, L = Сан-Франциско, O = Wikimedia Foundation, Inc., CN = *. Wikipedia.org Информация об открытом ключе субъекта: Алгоритм открытого ключа: id-ecPublicKey Открытый ключ: (256 бит) 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 OID ASN1: 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 / Policy: 2.23.140.1.2.2 Основные ограничения X509v3: CA: FALSE 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: wikiq uote.org, DNS: wikisource.org, DNS: wikiversity.org, DNS: wikivoyage.org, DNS: wiktionary.org, DNS: wmfusercontent.org, DNS: wikipedia.org X509v3 Расширенное использование ключа: проверка подлинности веб-сервера TLS, TLS Аутентификация веб-клиента 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 Идентификатор: 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:...
Чтобы проверить этот сертификат конечного объекта, нужен промежуточный сертификат, который соответствует идентификатору его эмитента и ключа авторизации:
| Issuer | C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2 |
| Authority Key Идентификатор | 96: DE: 61: F1: BD: 1C: 16: 29: 53: 1C: C0: CC: 7D: 3B: 83: 00: 40: E6: 1A: 7C |
In При подключении TLS правильно настроенный сервер предоставит промежуточное звено как часть рукопожатия. Однако также возможно получить промежуточный сертификат, получив URL-адрес «CA Issuers» из сертификата конечного объекта.
Это пример промежуточного сертификата, принадлежащего центру сертификации. Этот сертификат подписал сертификат конечного объекта выше и был подписан корневым сертификатом ниже. Обратите внимание, что поле темы этого промежуточного сертификата совпадает с полем издателя сертификата конечного объекта, который он подписал. Кроме того, поле «идентификатор ключа субъекта» в промежуточном звене совпадает с полем «идентификатор ключа органа» в сертификате конечного объекта.
Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 04: 00: 00: 00: 00: 01: 44: 4e: f0: 42: 47 Алгоритм подписи: sha256WithRSAEncryption Issuer: 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 Основные ограничения: критические 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 Any Policy CPS: https://www.globalsign.com/repository/ X509v3 Точки распространения списков отзыва сертификатов: полное имя: URI: http: //crl.globalsign.net/root.crl Доступ к информации о полномочиях: OCSP - URI: http: / / ocsp. globalsign.com/rootr1 Идентификатор ключа авторизации X509v3: keyid: 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-соединении. В противном случае сертификат конечного объекта считается ненадежным.
Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 04: 00: 00: 00: 00: 01: 15: 4b: 5a: c3: 94 Алгоритм подписи: sha1WithRSAEncryption Issuer: 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: критические CA: TRUE 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 Брюса Шнайера, Питера Гутмана и других экспертов по безопасности.
Реализации страдают от недостатков конструкции, ошибок, различного толкования стандартов и отсутствия взаимодействия различных стандартов. Вот некоторые проблемы:
Работа систем цифровой подписи зависит от безопасных криптографических хеш-функций. Когда инфраструктура открытого ключа позволяет использовать хэш-функцию, которая больше не является безопасной, злоумышленник может использовать слабые места в хэш-функции для подделки сертификатов. В частности, если злоумышленник может создать хэш-коллизию, он может убедить ЦС подписать сертификат с безобидным содержимым, где хэш этого содержимого идентичен хешу другого вредоносного набора сертификатов. содержимое, созданное злоумышленником со значениями по их выбору. Затем злоумышленник может добавить подпись, предоставленную ЦС, к содержимому своего вредоносного сертификата, в результате чего злонамеренный сертификат будет подписан ЦС. Поскольку содержимое вредоносного сертификата выбирается исключительно злоумышленником, они могут иметь другие даты действия или имена хостов, чем безобидный сертификат. Вредоносный сертификат может даже содержать поле «CA: true», позволяющее выдавать дополнительные доверенные сертификаты.
Использование хэш-коллизии для подделки подписей X.509 требует, чтобы злоумышленник мог предсказать данные, которые подпишет центр сертификации. Это можно несколько смягчить, если CA генерирует случайный компонент в сертификатах, которые он подписывает, обычно серийный номер. CA / Browser Forum требует энтропии серийного номера в разделе 7.1 базовых требований с 2011 года.
С 1 января 2016 года базовые требования запрещают выпуск сертификатов с использованием SHA-1. С начала 2017 года Chrome и Firefox отклоняют сертификаты, использующие SHA-1. По состоянию на май 2017 года и Edge, и Safari также отклоняют сертификат SHA-1. Валидаторы X.509, не являющиеся браузерами, еще не отклоняют сертификаты SHA-1.
В 1995 году Инженерная группа Интернета совместно с Национальным институтом стандартов и технологий сформировали рабочую группу по инфраструктуре открытого ключа (X.509). Рабочая группа, созданная в июне 2014 года, обычно именуется «PKIX». Он подготовил RFC и другую документацию по стандартам по использованию X.509 на практике. In particular it produced RFC 3280 and its successor RFC 5280, which define how to use X.509 in Internet protocols.
TLS/SSL and HTTPS use the RFC 5280 profile of X.509, as do S/MIME (Secure Multipurpose Internet Mail Extensions) and the EAP-TLS method for WiFi authentication. Any protocol that uses TLS, such as SMTP, POP, IMAP, LDAP, XMPP, and many more, inherently uses X.509.
IPSec can use the RFC 4945 profile for authenticating peers.
The OpenCable security specification defines its own profile of X.509 for use in the cable industry.
Devices like smart cards and TPMs often carry certificates to identify themselves or their owners. These certificates are in X.509 form.
The WS-Security standard defines authentication either through TLS or through its own certificate profile. Both methods use X.509.
The Microsoft Authenticode code signing system uses X.509 to identify authors of computer programs.
The OPC UA industrial automation communication standard uses X.509.
SSH generally uses a Trust On First Use security model and doesn't have need for certificates. However, the popular OpenSSH implementation does support a CA-signed identity model based on its own non-X.509 certificate format.
