Сертификат открытого ключа

редактировать
Электронный документ, используемый для подтверждения права собственности на открытый ключ Сертификат клиента и сервера *.wikipedia.org

В криптографии сертификат открытого ключа, также известный как цифровой сертификат или удостоверение личности, представляет собой электронный документ. используется для подтверждения владения открытым ключом . Сертификат включает информацию о ключе, информацию об идентичности его владельца (называемую субъектом) и цифровую подпись объекта, который проверил содержимое сертификата (называемого эмитентом). Если подпись действительна и программа, проверяющая сертификат, доверяет издателю, то она может использовать этот ключ для безопасного взаимодействия с субъектом сертификата. В системах шифрования электронной почты, подписи кода и электронной подписи субъектом сертификата обычно является человек или организация. Однако в Transport Layer Security (TLS) субъектом сертификата обычно является компьютер или другое устройство, хотя сертификаты TLS могут идентифицировать организации или отдельных лиц в дополнение к их основной роли в идентификации устройств. TLS, иногда называемый более старым названием Secure Sockets Layer (SSL), примечателен тем, что является частью HTTPS, протокола для безопасного просмотра Интернета.

в Типичная схема инфраструктуры открытого ключа (PKI), эмитентом сертификата является центр сертификации (CA), обычно компания, которая взимает с клиентов плату за выдачу сертификатов для них. Напротив, в схеме сеть доверия отдельные лица подписывают ключи друг друга напрямую в формате, который выполняет функцию, аналогичную сертификату открытого ключа.

Наиболее распространенный формат сертификатов открытых ключей определяется в X.509. Поскольку X.509 является очень общим, формат дополнительно ограничивается профилями, определенными для определенных случаев использования, такими как Инфраструктура открытого ключа (X.509), как определено в RFC 5280.

Содержание

  • 1 Типы сертификатов
    • 1.1 Сертификат сервера TLS / SSL
    • 1.2 Сертификат клиента TLS / SSL
    • 1.3 Сертификат электронной почты
    • 1.4 Сертификат EMV
    • 1.5 Сертификат подписи кода
    • 1.6 Квалифицированный сертификат
    • 1.7 Корневой сертификат
    • 1.8 Промежуточный сертификат
    • 1.9 Конечный объект или конечный сертификат
    • 1.10 Самоподписанный сертификат
  • 2 Общие поля
  • 3 Образец сертификата
  • 4 Использование в Европейском Союзе
  • 5 Центры сертификации
  • 6 Корневые программы
  • 7 Сертификаты и безопасность веб-сайтов
    • 7.1 Уровни проверки
      • 7.1.1 Проверка домена
      • 7.1.2 Проверка организации
      • 7.1.3 Расширенная проверка
    • 7.2 Слабые стороны
    • 7.3 Полезность по сравнению с незащищенными веб-сайтами
  • 8 Стандарты
  • 9 См. Также
  • 10 Ссылки

Типы сертификатов

Роли корневого сертификата, i Промежуточный сертификат и сертификат конечного объекта, как в цепочке доверия.

Сертификат сервера TLS / SSL

В TLS (обновленная замена SSL) требуется сервер для предоставления сертификата при первоначальной настройке подключения. клиент, подключающийся к этому серверу, будет выполнять алгоритм проверки пути сертификации :

  1. Субъект сертификата совпадает с именем хоста (то есть доменным именем), к которому клиент пытается для подключения;
  2. Сертификат подписан доверенным центром сертификации.

Основное имя хоста (доменное имя веб-сайта) указано как Общее имя в поле Тема сертификата. Сертификат может быть действителен для нескольких имен хостов (нескольких веб-сайтов). Такие сертификаты обычно называются сертификатами альтернативного имени субъекта (SAN) или сертификатами унифицированных коммуникаций (UCC) . Эти сертификаты содержат поле Альтернативное имя субъекта, хотя многие центры сертификации также помещают их в поле Общее имя субъекта для обратной совместимости. Если некоторые из имен хостов содержат звездочку (*), сертификат также может называться групповым сертификатом.

. Сервер TLS может быть настроен с самозаверяющим сертификатом. В таком случае клиенты обычно не могут проверить сертификат и разрывают соединение, если проверка сертификата не отключена.

В соответствии с приложениями сертификаты SSL можно разделить на три типа:

  • SSL для проверки домена;
  • SSL для проверки организации;
  • SSL для расширенной проверки.

Сертификат клиента TLS / SSL

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

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

Сертификат электронной почты

В протоколе S / MIME для защищенной электронной почты отправителям необходимо определить, какой открытый ключ использовать для каждого получателя. Они получают эту информацию из сертификата электронной почты. Некоторые общественно доверенные центры сертификации предоставляют сертификаты электронной почты, но чаще всего S / MIME используется при взаимодействии внутри данной организации, и эта организация имеет собственный ЦС, которому доверяют участники этой системы электронной почты.

Сертификат EMV

Платежные карты EMV предварительно загружены сертификатом эмитента карты, подписанным центром сертификации EMV для проверки подлинности платежной карты во время платежной транзакции. Сертификат EMV CA загружается в карточные терминалы ATM или POS и используется для проверки сертификата эмитента карты.

Сертификат подписи кода

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

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

Сертификат, идентифицирующий человека, обычно для целей электронной подписи. Чаще всего они используются в Европе, где правила eIDAS стандартизируют их и требуют их признания.

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

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

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

Сертификат, используемый для подписи других сертификатов. Промежуточный сертификат должен быть подписан другим промежуточным сертификатом или корневым сертификатом.

Конечный объект или конечный сертификат

Любой сертификат, который нельзя использовать для подписи других сертификатов. Например, сертификаты сервера и клиента TLS / SSL, сертификаты электронной почты, сертификаты подписи кода и квалифицированные сертификаты являются сертификатами конечных объектов.

Самоподписанный сертификат

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

Общие поля

Это одни из наиболее распространенных полей в сертификатах. Большинство сертификатов содержат ряд полей, не перечисленных здесь. Обратите внимание, что с точки зрения представления сертификата X.509 сертификат не является «плоским», а содержит эти поля, вложенные в различные структуры внутри сертификата.

  • Серийный номер : используется для однозначной идентификации сертификата в системах центра сертификации. В частности, это используется для отслеживания информации об отзыве.
  • Тема : объект, которому принадлежит сертификат: машина, физическое лицо или организация.
  • Эмитент : объект, который проверил информацию и подписал сертификат.
  • Не раньше : Самое раннее время и дата, когда сертификат действителен. Обычно устанавливается за несколько часов или дней до момента выдачи сертификата, чтобы избежать проблем с перекосом часов.
  • Не после : время и дата, по истечении которых сертификат становится недействительным..
  • Использование ключа : Допустимое криптографическое использование открытого ключа сертификата. Общие значения включают проверку цифровой подписи, шифрование ключа и подписание сертификата.
  • Расширенное использование ключа : приложения, в которых может использоваться сертификат. Общие значения включают аутентификацию сервера TLS, защиту электронной почты и подпись кода.
  • Открытый ключ : открытый ключ, принадлежащий субъекту сертификата.
  • Алгоритм подписи : алгоритм, используемый для подписи сертификат открытого ключа.
  • Подпись : подпись тела сертификата закрытым ключом эмитента.

Образец сертификата

Это пример полученного декодированного сертификата SSL / TLS с веб-сайта SSL.com. Общее имя эмитента (CN) отображается как SSL.com EV SSL Intermediate CA RSA R3, идентифицируя его как сертификат расширенной проверки (EV). Подтвержденная информация о владельце веб-сайта (SSL Corp) находится в поле Тема. Поле X509v3 Subject Alternative Nameсодержит список доменных имен, на которые распространяется сертификат. Поля Расширенное использование ключа X509v3и Использование ключа X509v3показывают все подходящие варианты использования.

Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 72: 14: 11: d3: d7: e0: fd: 02: aa: b0: 4e: 90: 09: d4: db: 31 Алгоритм подписи: sha256WithRSAEncryption Эмитент: C = США, ST = Техас, L = Хьюстон, O = SSL Corp, CN = SSL.com EV SSL Промежуточный CA RSA R3 Срок действия не ранее: 18 апреля 22:15:06 2019 GMT Не после: 17 апреля 22:15:06 2021 по Гринвичу Тема: C = США, ST = Техас, L = Хьюстон, O = SSL Corp / serialNumber = NV20081614243, CN = www.ssl.com / postalCode = 77098 / businessCategory = Private Organization / street = 3100 Ричмонд авеню / юрисдикция ST = Невада / юрисдикция C = США Информация об открытом ключе субъекта: Алгоритм открытого ключа: rsaEncryption Открытый ключ RSA: (2048 бит) Модуль: 00: ad: 0f: ef: c1: 97: 5a: 9b: d8 : 1e... Показатель: 65537 (0x10001) Расширения X509v3: Идентификатор ключа авторизации X509v3: keyid: BF: C1: 5A: 87: FF: 28: FA: 41: 3D: FD: B7: 4F: E4: 1D: AF : A0: 61: 58: 29: Доступ к информации о BD Authority: CA Issuers - URI: http: //www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt OCSP - URI: http://ocsps.ssl.com X509v3 Альтернативное имя субъекта: DNS: www.ssl.co m, DNS: answers.ssl.com, DNS: faq.ssl.com, DNS: info.ssl.com, DNS: links.ssl.com, DNS: reseller.ssl.com, DNS: secure.ssl.com, DNS: ssl.com, DNS: support.ssl.com, DNS: sws.ssl.com, DNS: tools.ssl.com X509v3 Сертификаты Политики: Политика: 2.23.140.1.1 Политика: 1.2.616.1.113527.2.5.1. 1 Политика: 1.3.6.1.4.1.38064.1.1.1.5 CPS: https://www.ssl.com/repository Использование расширенного ключа X509v3: проверка подлинности веб-клиента TLS, проверка подлинности веб-сервера TLS Точки распространения списков отзыва сертификатов X509v3: полное имя: URI : http: //crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl Идентификатор ключа субъекта X509v3: E7: 37: 48: DE: 7D: C2: E1: 9D: D0: 11 : 25: 21: B8: 00: 33: 63: 06: 27: C1: 5B Использование ключа X509v3: критическая цифровая подпись, шифрование ключа Предварительный сертификат CT SCT: подписанный сертификат Временная метка: Версия: v1 (0x0) Идентификатор журнала: 87:75 : BF: E7: 59: 7C: F8: 8C: 43: 99... Отметка времени: 18 апреля, 22: 25: 08.574 2019 GMT Расширения: нет Подпись: ecdsa-with-SHA256 30: 44: 02: 20: 40: 51: 53: 90: C6: A2... Метка времени подписанного сертификата: Версия: v1 (0x0) Идентификатор журнала: A4: B9: 09: 90: B4: 18 : 58: 14: 87: BB... Отметка времени: 18 апреля 22: 25: 08.461 2019 GMT Расширения: нет Подпись: ecdsa-with-SHA256 30: 45: 02: 20: 43: 80: 9E: 19: 90: FD... Подписанный сертификат Метка времени: Версия: v1 (0x0) Идентификатор журнала: 55: 81: D4: C2: 16: 90: 36: 01: 4A: EA... Метка времени: 18 апреля 22: 25: 08.769 2019 GMT Расширения: нет Подпись: ecdsa-with-SHA256 30: 45: 02: 21: 00: C1: 3E: 9F: F0: 40... Алгоритм подписи: sha256WithRSAEncryption 36: 07: e7: 3b: b7: 45: 97: ca: 4d: 6c...

Использование в Европейском Союзе

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

Центры сертификации

Процедура получения сертификата открытого ключа

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

Центры сертификации также несут ответственность за поддержание актуальной информации об отзыве сертификатов, которые они выпустили, указывает, действительны ли сертификаты. Они предоставляют эту информацию через онлайн-протокол состояния сертификатов (OCSP) и / или списки отзыва сертификатов (CRL). Некоторые из крупных центров сертификации на рынке включают IdenTrust, DigiCert и Sectigo.

корневые программы

Некоторые основные программы содержат список сертификатов. авторитеты, которым доверяют по умолчанию. Это облегчает конечным пользователям проверку сертификатов, а людям или организациям, запрашивающим сертификаты, проще узнать, какие центры сертификации могут выдать сертификат, который будет пользоваться широким доверием. Это особенно важно в HTTPS, где оператор веб-сайта обычно хочет получить сертификат, которому доверяют почти все потенциальные посетители их веб-сайта.

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

Браузеры, отличные от Firefox, обычно используют возможности операционной системы, чтобы решить, каким центрам сертификации можно доверять. Так, например, Chrome в Windows доверяет центрам сертификации, включенным в корневую программу Microsoft, а в macOS или iOS Chrome доверяет центрам сертификации в корневой программе Apple. Edge и Safari также используют соответствующие хранилища доверенных сертификатов операционной системы, но каждый из них доступен только в одной ОС. Firefox использует хранилище доверенных сертификатов Mozilla Root Program на всех платформах.

Корневая программа Mozilla является общедоступной, и ее список сертификатов является частью веб-браузера Firefox с открытым исходным кодом, поэтому он широко используется за пределами Firefox. Например, хотя общей корневой программы Linux не существует, многие дистрибутивы Linux, такие как Debian, включают пакет, который периодически копирует содержимое списка доверия Firefox, который затем используется приложениями.

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

Сертификаты и безопасность веб-сайтов

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

В качестве примера, когда пользователь подключается к https://www.example.com/с помощью своего браузера, если браузер не выдает предупреждение о сертификате, то пользователь может быть теоретически уверенным, что взаимодействие с https://www.example.com/эквивалентно взаимодействию с лицом, контактирующим с адресом электронной почты, указанным в общедоступном регистраторе в разделе «example.com», даже если это адрес электронной почты может не отображаться на веб-сайте. Никаких других гарантий не предполагается. Кроме того, взаимоотношения между покупателем сертификата, оператором веб-сайта и создателем контента веб-сайта могут быть ненадежными и не гарантируются. В лучшем случае сертификат гарантирует уникальность веб-сайта при условии, что сам веб-сайт не был скомпрометирован (взломан) или не нарушен процесс выдачи сертификата.

Провайдер сертификатов может выбрать выпуск трех типов сертификатов, каждый из которых требует своей степени строгости проверки. В порядке возрастания строгости (и, естественно, стоимости) это: проверка домена, проверка организации и расширенная проверка. Эти требования свободно согласовываются добровольными участниками CA / Browser Forum.

Уровни валидации

Проверка домена

Провайдер сертификатов выдает сертификат, подтвержденный доменом (DV). покупателю, если покупатель может продемонстрировать один критерий проверки: право административно управлять затронутыми доменами DNS.

Проверка организации

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

Расширенная проверка

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

. До 2019 года основные браузеры, такие как Chrome и Firefox, обычно предлагали пользователям визуальную индикацию юридической идентичности, когда сайт представлял сертификат EV.. Это было сделано путем отображения юридического имени перед доменом и ярко-зеленого цвета, чтобы выделить изменение. Большинство браузеров не рекомендуют эту функцию, не создавая визуальной разницы для пользователя в зависимости от типа используемого сертификата. Это изменение последовало за проблемами безопасности, поднятыми судебными экспертами, и успешными попытками приобрести сертификаты EV для выдачи себя за известные организации, доказав неэффективность этих визуальных индикаторов и выявив потенциальные злоупотребления.

Слабые стороны

A веб-браузер даст нет предупреждения пользователю, если веб-сайт внезапно представляет другой сертификат, даже если этот сертификат имеет меньшее количество битов ключа, даже если у него другой поставщик, и даже если у предыдущего сертификата была дата истечения срока действия в далеком будущем. Если поставщики сертификатов находятся в юрисдикции правительств, эти правительства могут иметь право приказать провайдеру создать любой сертификат, например, в целях обеспечения соблюдения законов. Дочерние оптовые поставщики сертификатов также могут создавать любой сертификат.

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

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

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

Полезность по сравнению с незащищенными веб-сайтами

Несмотря на ограничения, описанные выше, TLS с проверкой подлинности считается обязательным по всем правилам безопасности, когда веб-сайт размещает конфиденциальную информацию или выполняет существенные транзакции. Это связано с тем, что на практике, несмотря на недостатки, описанные выше, веб-сайты, защищенные сертификатами открытых ключей, все же более безопасны, чем незащищенные веб-сайты http: //.

Стандарты

Отдел компьютерной безопасности Национального института стандартов и технологий (NIST ) предоставляет руководящие документы для сертификатов открытых ключей:

  • SP 800-32 Введение в технологию открытых ключей и Федеральная инфраструктура PKI
  • SP 800-25 Федеральное агентство по использованию технологии открытого ключа для цифровых подписей и аутентификации

См. также

Ссылки

Последняя правка сделана 2021-06-02 10:10:14
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте