Сертификат открытого ключа - Public key certificate

Сертификат клиента и сервера * .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) сервер требуется для предъявления сертификата при начальной настройке подключения. А клиент подключение к этому серверу выполнит алгоритм проверки пути сертификации:

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

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

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

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

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

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

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

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

Электронный сертификат

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

Сертификат EMV

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

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

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

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

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

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

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

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

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

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

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

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

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

Общие поля

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

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

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

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

Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 72: 14: 11: d3: d7: e0: fd: 02: aa: b0: 4e: 90: 09: d4: db: 31 Алгоритм подписи: sha256WithRSAEncryption Issuer: C = США, ST = Техас, L = Хьюстон, O = SSL Corp, CN = SSL.com EV SSL Промежуточный CA RSA R3 Срок действия не раньше: 18 апреля, 22:15:06 2019 г., не позднее: 17 апреля, 22:15: 06 2021 GMT Тема: 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 Аутентификация X509v3 Точки распространения CRL: Полное имя: 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) Lo g ID: 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 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 / Форум браузеров.

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

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

Поставщик сертификатов выдает покупателю сертификат, подтвержденный доменом (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]