Сертификат открытого ключа
"Удостоверение личности" перенаправляется сюда. Для других целей см. раздел сертификат удостоверения (устранение неоднозначности).
В криптографии сертификат открытого ключа, также известный как цифровой сертификат или удостоверение личности, является электронным документом, используемым, чтобы доказать собственность открытого ключа [1] . Сертификат включает в себя информацию о ключе, информацию о личности его владельца (называемом субъектом) и цифровую подпись субъекта, проверившего содержимое сертификата (называемого эмитентом). Если подпись действительна и программное обеспечение, проверяющее сертификат, доверяет издателю, то оно может использовать этот ключ для безопасного обмена данными с субъектом сертификата. В шифровании электронной почты, системы подписи кода и электронной подписи субъектом сертификата обычно является лицо или организация. Однако в TLS субъектом сертификата обычно является компьютер или другое устройство, хотя сертификаты TLS могут идентифицировать организации или отдельных лиц в дополнение к их основной роли в идентификации устройств. TLS, иногда называемый его старым именем Secure Sockets Layer (SSL), отличается тем, что является частью HTTPS, протокола для безопасного просмотра веб-страниц .
В типичной схеме инфраструктуры открытых ключей (PKI) эмитентом сертификата является Центр сертификации (CA), обычно компания, которая взимает с клиентов плату за выдачу сертификатов для них. Напротив, в схеме web of trust люди подписывают ключи друг друга напрямую, в формате, который выполняет аналогичную функцию для сертификата открытого ключа.
Наиболее распространенный формат сертификатов открытого ключа определяется 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 используется при общении в данной организации, и эта организация запускает свой собственный ЦС, которому доверяют участники этой системы электронной почты.
Сертификат подписи кода[править]
Главная статья: подписание кода
Сертификаты также можно использовать для проверки подписей программ, чтобы убедиться, что они не были подделаны во время доставки.
Квалифицированный сертификат[править]
Основная статья: квалифицированный цифровой сертификат
Сертификат, идентифицирующий физическое лицо, обычно для целей электронной подписи. Они чаще всего используются в Европе, где регулирование eIDAS стандартизирует их и требует их признания.
Корневой сертификат[править]
Основная статья: корневой сертификат
Самозаверяющий сертификат, используемый для подписания других сертификатов. Также иногда называется якорем доверия .
Промежуточный сертификат[править]
Сертификат, используемый для подписания других сертификатов. Промежуточный сертификат должен быть подписан другим промежуточным сертификатом или корневым сертификатом.
Конечная сущность или конечный сертификат[править]
Любой сертификат, который нельзя использовать для подписи других сертификатов. Например, сертификаты сервера и клиента TLS/SSL, сертификаты электронной почты, сертификаты подписи кода и квалифицированные сертификаты являются сертификатами конечных сущностей.
Самозаверяющий сертификат[править]
Главная статья: самозаверяющий сертификат
Сертификат с субъектом, соответствующим его эмитенту, и подписью, которая может быть проверена его собственным открытым ключом. Большинство типов сертификатов могут быть самозаверяющими. Самоподписанные сертификаты также часто называют сертификатами змеиного масла, чтобы подчеркнуть их ненадежность.
Общие поля[править]
См. также: X. 509 § структура сертификата
Это одни из наиболее распространенных полей сертификатов. Большинство сертификатов содержат ряд полей, не перечисленных здесь. Обратите внимание, что с точки зрения представления сертификата X. 509 сертификат не является "плоским", но содержит эти поля, вложенные в различные структуры внутри сертификата.
- Серийный номер: используется для уникальной идентификации сертификата в системах ЦС. В частности, это используется для отслеживания информации об отзыве.
- Субъект: объект, которому принадлежит сертификат: машина, физическое лицо или организация.
- Эмитент: объект, который проверил информацию и подписал сертификат.
- Не ранее: самое раннее время и дата действия сертификата. Обычно устанавливается на несколько часов или дней до момента выдачи сертификата, чтобы избежать проблем с перекосом часов.
- Не После : время и дата, после которых сертификат больше не действителен.
- Использование ключа: допустимое криптографическое использование открытого ключа сертификата. Общие значения включают проверку цифровой подписи, шифрование ключа и подпись сертификата.
- Расширенное использование ключа: приложения, в которых может использоваться сертификат. Общие значения включают проверку подлинности сервера TLS, защиту электронной почты и подпись кода.
- Открытый ключ: открытый ключ, принадлежащий субъекту сертификата.
- Алгоритм подписи: алгоритм, используемый для подписи сертификата открытого ключа.
- Подпись: подпись тела сертификата закрытым ключом эмитента.
Использование в Европейском Союзе[править]
В Европейском Союзе электронные подписи на юридических документах обычно выполняются с использованием цифровых подписей с сопровождающими удостоверениями личности. Во многом это связано с тем , что такие подписи имеют такую же юридическую силу, как и рукописные подписи под eIDAS, регламентом ЕС .
Центры сертификации[править]
Основная статья: Центр сертификации
В модели доверия X. 509 центр сертификации (ЦС) отвечает за подписание сертификатов. Эти сертификаты действуют как введение между двумя сторонами, что означает, что ЦС действует как доверенная третья сторона. ЦС обрабатывает запросы от людей или организаций, запрашивающих сертификаты (называемые подписчиками), проверяет информацию и потенциально подписывает сертификат конечного объекта на основе этой информации. Для эффективного выполнения этой роли ЦС должен иметь один или несколько широко доверенных корневых сертификатов или промежуточных сертификатов и соответствующие закрытые ключи. ЦС могут достичь этого широкого доверия, включив свои корневые сертификаты в популярное программное обеспечение или получив перекрестную подпись от другого ЦС, делегирующего доверие. Другие ЦС доверяются относительно небольшому сообществу, например бизнесу, и распространяются с помощью других механизмов, таких как групповая политика Windows .
Центры сертификации также несут ответственность за поддержание актуальной информации об отзыве сертификатов, которые они выдали, указывая, действительны ли сертификаты. Они предоставляют эту информацию через протокол состояния сертификатов (OCSP) и/или списки отзыва сертификатов (CRL).
Корневые программы[править]
Некоторые основные программы содержат список центров сертификации, которым доверяют по умолчанию. Это облегчает конечным пользователям проверку сертификатов и облегчает людям или организациям, которые запрашивают сертификаты, знать, какие центры сертификации могут выдавать сертификат, который будет широко доверенным. Это особенно важно в HTTPS, где оператор веб-сайта обычно хочет получить сертификат, которому доверяют почти все потенциальные посетители их веб-сайта.
Политики и процессы, используемые поставщиком для определения центров сертификации, которым должно доверять его программное обеспечение, называются корневыми программами. Наиболее влиятельными корневыми программами являются:
- Корневая Программа Microsoft
- Программа Apple Root
- Корневая Программа Mozilla
- Корневая программа Oracle Java
- Adobe Aatl утвержденный список доверия Adobe и корневые программы EUTL (используется для подписания документов)
Браузеры, отличные от Firefox, обычно используют средства операционной системы, чтобы решить, какие центры сертификации являются доверенными. Так, например, Chrome в Windows доверяет центрам сертификации, включенным в корневую программу Microsoft, а в macOS или iOS Chrome доверяет центрам сертификации в корневой программе Apple.[4] Edge и Safari также используют свои соответствующие хранилища доверия операционной системы, но каждый из них доступен только на одной ОС. Firefox использует хранилище доверенных программ Mozilla Root на всех платформах.
Корневая программа Mozilla работает публично, и ее список сертификатов является частью браузера Firefox с открытым исходным кодом, поэтому он широко используется за пределами Firefox. Например, хотя нет общей корневой программы Linux, многие дистрибутивы Linux, такие как Debian, включают пакет, который периодически копирует содержимое списка доверия Firefox, который затем используется приложениями.
Корневые программы обычно предоставляют набор допустимых целей с включенными в них сертификатами. Например, некоторые ЦС могут считаться доверенными для выдачи сертификатов сервера TLS, но не для сертификатов подписи кода. Это обозначается набором битов доверия в корневой системе хранения сертификатов.
Сертификаты и безопасность сайта[править]
Наиболее часто сертификаты используются для веб-сайтов на основе HTTPS. Веб-браузер проверяет, что веб-сервер HTTPS является подлинным, так что пользователь может чувствовать себя в безопасности, что его / ее взаимодействие с веб-сайтом не имеет подслушивающих устройств и что веб-сайт, кто он утверждает, что. Эта безопасность важна для электронной торговли . На практике оператор веб-сайта получает сертификат, обратившись в центр сертификации с запросом на подписание сертификата. Запрос сертификата представляет собой электронный документ, содержащий название веб-сайта, информацию о компании и открытый ключ. Поставщик сертификата подписывает запрос, тем самым создавая публичный сертификат. Во время просмотра веб-страниц этот общедоступный сертификат передается любому веб-браузеру, который подключается к веб-сайту и доказывает веб-браузеру, что поставщик считает, что он выдал сертификат владельцу веб-сайта.
Например, когда пользователь подключается к https://www.example.com/своему браузеру, если браузер не выдает предупреждающее сообщение сертификата, то теоретически пользователь может быть уверен, что https://www.example.com/ эквивалентно взаимодействию с субъектом, находящимся в контакте с адресом электронной почты, указанным в разделе "публичный регистратор" example.com " несмотря на то, что этот адрес электронной почты может не отображаться нигде на веб-сайте. Никакой другой гарантии не подразумевается. Кроме того, отношения между покупателем сертификата, оператором веб-сайта и генератором содержимого веб-сайта могут быть незначительными и не гарантируются. В лучшем случае сертификат гарантирует уникальность веб-сайта при условии, что сам веб-сайт не был взломан или процесс выдачи сертификата не был нарушен.
Поставщик сертификатов может выбрать выдачу трех типов сертификатов, каждый из которых требует собственной степени строгости проверки. В порядке возрастания строгости (и, естественно, стоимости) это: валидация домена, валидация организации и расширенная валидация. Эти строгости свободно согласованы добровольными участниками форума CA/Browser .
Уровни проверки[править]
Проверка домена[править]
Главная статья: проверенный доменом сертификат
Поставщик сертификатов будет выдавать сертификат класса проверки домена (DV) покупателю, если покупатель может продемонстрировать один критерий проверки: право административного управления доменным именем.
Проверка организации[править]
Поставщик сертификата выдаст покупателю сертификат класса проверки подлинности организации (OV), если покупатель может соответствовать двум критериям: право на административное управление рассматриваемым доменным именем и, возможно, фактическое существование организации в качестве юридического лица. Поставщик сертификатов публикует свои критерии проверки OV через свою политику сертификатов .
Расширенная проверка[править]
Главная статья: расширенный сертификат проверки
Чтобы получить сертификат расширенной валидации (EV), покупатель должен убедить поставщика сертификата в его юридической идентичности, включая ручную проверку человеком. Как и в случае с сертификатами OV, поставщик сертификатов публикует свои критерии проверки EV через свою политику сертификатов .
Браузеры, как правило, предлагают пользователям визуальное указание юридического лица, когда сайт представляет сертификат EV. Большинство браузеров показывают законное имя перед доменом и используют ярко-зеленый цвет для выделения изменения. Таким образом, пользователь может видеть, что юридическая личность владельца была проверена.
Слабые сторонки[править]
Веб-браузер не будет предупреждать пользователя о том, что веб-сайт внезапно представляет другой сертификат, даже если этот сертификат имеет меньшее количество ключевых битов, даже если он имеет другого поставщика, и даже если предыдущий сертификат имеет срок действия далеко в будущем.[ цитата необходима] Однако изменение от сертификата EV к сертификату non-EV будет очевидно по мере того как зеленый бар больше не будет показан. В тех случаях, когда поставщики сертификатов находятся под юрисдикцией правительств, эти правительства могут иметь право приказать поставщику выдать любой сертификат, например, для целей правоприменения. У дочерних оптовых поставщиков сертификатов также есть свобода генерировать любой сертификат.
Все веб-браузеры поставляются с обширным встроенным списком доверенных корневых сертификатов, многие из которых контролируются организациями, которые могут быть незнакомы пользователю.[1] Каждая из этих организаций может выдавать любой сертификат для любого веб-сайта и иметь гарантию того, что веб-браузеры, включающие корневые сертификаты, примут его как подлинный. В этом случае конечные пользователи должны полагаться на разработчика программного обеспечения браузера для управления его встроенным списком сертификатов и на поставщиков сертификатов для правильного поведения и информирования разработчика браузера о проблемных сертификатах. В то время как необычно, были случаи, в которых были выданы мошеннические сертификаты: в некоторых случаях браузеры обнаружили мошенничество; в других случаях прошло некоторое время, прежде чем разработчики браузера удалили эти сертификаты из своего программного обеспечения.[6][7]
Список встроенных сертификатов также не ограничивается теми, которые предоставляются разработчиком браузера: пользователи (и в какой-то степени приложения) могут свободно расширять список для специальных целей, таких как для интрасетей компании.[8] это означает, что если кто-то получает доступ к машине и может установить новый корневой сертификат в браузере, браузер распознает веб-сайты, использующие вставленный сертификат, как законные.
Для доказуемой безопасности такая зависимость от чего-то внешнего по отношению к системе приводит к тому, что любая схема сертификации открытого ключа должна опираться на какое-то специальное предположение о настройке, например на существование центра сертификации .[9] Полезность против незащищенных веб-сайтов
Несмотря на описанные выше ограничения, протокол TLS с проверкой подлинности сертификата считается обязательным во всех правилах безопасности, когда на веб-сайте размещается конфиденциальная информация или выполняются существенные транзакции. Это связано с тем, что на практике, несмотря на описанные выше недостатки, веб-сайты, защищенные сертификатами открытого ключа, все еще более безопасны, чем незащищенные веб-сайты http://.
Стандарты[править]
Отдел компьютерной безопасности Национального института стандартов и технологий( NIST) предоставляет руководящие документы для сертификатов открытых ключей:
- SP 800-32 введение в технологию открытых ключей и федеральную инфраструктуру PKI
- SP 800-25 Federal Agency Use of Public Key Technology for Digital Signatures and Authentication