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

Сертификат клиента и сервера * .wikipedia.org

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

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

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

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

Сертификат сервера TLS / SSL [ править ]

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

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

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

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

По приложениям SSL-сертификаты можно разделить на три типа: ^[3]

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

Сертификат клиента TLS / SSL [ править ]

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

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

Электронный сертификат [ изменить ]

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

Сертификат EMV [ править ]

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

Сертификат подписи кода [ править ]

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

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

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

Корневой сертификат [ править ]

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

Промежуточный сертификат [ править ]

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

Конечный объект или листовой сертификат [ править ]

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

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

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

Общие поля [ править ]

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

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

Образец сертификата [ править ]

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

Сертификат: Данные: Версия: 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 Intermediate 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 = Частная организация / street = 3100 Richmond Ave / юрисдикция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 Доступ к информации о полномочиях:  Эмитенты CA - URI: http: //www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt OCSP - URI: http: //ocsps.ssl.com X509v3 Альтернативное имя субъекта:  DNS: www.ssl.com, 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 Точки распространения CRL 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:  Отметка времени подписанного сертификата: Версия: 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Модель доверия, центр сертификации (ЦС) отвечает за подписание сертификатов. Эти сертификаты действуют как вступление между двумя сторонами, что означает, что ЦС действует как доверенная третья сторона. ЦС обрабатывает запросы от людей или организаций, запрашивающих сертификаты (называемые подписчиками), проверяет информацию и потенциально подписывает сертификат конечного объекта на основе этой информации. Для эффективного выполнения этой роли ЦС должен иметь один или несколько широко доверенных корневых сертификатов или промежуточных сертификатов и соответствующие закрытые ключи. Центры сертификации могут достичь этого широкого доверия, включив свои корневые сертификаты в популярное программное обеспечение или получив перекрестную подпись от другого центра сертификации, делегирующего доверие. Другим центрам сертификации доверяют в относительно небольшом сообществе, таком как бизнес, и они распространяются с помощью других механизмов, таких как Windows.Групповая политика .

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

Корневые программы [ править ]

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

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

• Корневая программа Microsoft
• Программа Apple Root
• Программа Mozilla Root
• Корневая программа Oracle Java
• Adobe AATL Adobe Approved Trust List и корневые программы EUTL (используются для подписания документов)

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

Программа Mozilla Root работает публично, и ее список сертификатов является частью веб-браузера Firefox с открытым исходным кодом, поэтому он широко используется за пределами Firefox. Например, хотя не существует общей корневой программы Linux, многие дистрибутивы Linux, такие как Debian ^[7], включают пакет, который периодически копирует содержимое списка доверия 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. Это было сделано путем отображения юридического имени перед доменом и ярко-зеленого цвета, чтобы выделить изменение. Большинство браузеров не рекомендуют эту функцию ^{[8] [9],} не делая визуальных различий для пользователя в зависимости от типа используемого сертификата. Это изменение последовало за проблемами безопасности, высказанными судебными экспертами, и успешными попытками приобрести сертификаты электромобилей для выдачи себя за известные организации, что доказало неэффективность этих визуальных индикаторов и выявило потенциальные злоупотребления. ^[10]

Слабые стороны [ править ]

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

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

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

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

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

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

Стандарты [ править ]

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

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

См. Также [ править ]

• Сертификат авторизации
• Довольно хорошая конфиденциальность

Ссылки [ править ]