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

Сертификат открытого ключа * .comifuro.net, выданный Let's Encrypt

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

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

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

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

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

Сертификат сервера 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 загружается в банкоматы или терминалы для карт и используется для проверки сертификата эмитента карты.

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

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

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

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

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

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

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

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

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

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

Ролевой сертификат

Ролевые сертификаты, определенные в политике сертификатов X.509 для Федерального центра сертификации мостов, определяют конкретную роль, от имени которой подписчик имеет право действовать, а не имя подписчика, и выдаются в интересах поддержки принятой деловой практики. . "

Групповой сертификат

Определяется в политике сертификатов X.509 для Федерального центра сертификации мостов для «случаев, когда несколько объектов действуют в одном качестве, и когда неотказуемость транзакций нежелательна».

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

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

Общие поля

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

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

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

Это пример декодированного сертификата 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поля показать все соответствующие виды использования.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3
        Validity
            Not Before: Apr 18 22:15:06 2019 GMT
            Not After : Apr 17 22:15:06 2021 GMT
        Subject: C=US, ST=Texas, L=Houston, O=SSL Corp/serialNumber=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Private Organization/street=3100 Richmond Ave/jurisdictionST=Nevada/jurisdictionC=US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:ad:0f:ef:c1:97:5a:9b:d8:1e ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD

            Authority Information Access: 
                CA Issuers - URI:http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt
                OCSP - URI:http://ocsps.ssl.com

            X509v3 Subject Alternative Name: 
                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 Certificate Policies: 
                Policy: 2.23.140.1.1
                Policy: 1.2.616.1.113527.2.5.1.1
                Policy: 1.3.6.1.4.1.38064.1.1.1.5
                  CPS: https://www.ssl.com/repository

            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl

            X509v3 Subject Key Identifier: 
                E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 87:75:BF:E7:59:7C:F8:8C:43:99 ...
                    Timestamp : Apr 18 22:25:08.574 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:40:51:53:90:C6:A2 ...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB ...
                    Timestamp : Apr 18 22:25:08.461 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:43:80:9E:19:90:FD ...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 55:81:D4:C2:16:90:36:01:4A:EA ...
                    Timestamp : Apr 18 22:25:08.769 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:C1:3E:9F:F0:40 ...
    Signature Algorithm: 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 Root работает публично, и ее список сертификатов является частью веб-браузера 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. Это было сделано путем отображения юридического имени перед доменом и ярко-зеленого цвета, чтобы выделить изменение. Большинство браузеров не рекомендуют эту функцию, не создавая визуальной разницы для пользователя в зависимости от типа используемого сертификата. Это изменение последовало за проблемами безопасности, высказанными судебными экспертами, и успешными попытками приобрести сертификаты электромобилей, чтобы выдавать себя за известные организации, что доказало неэффективность этих визуальных индикаторов и выявило потенциальные злоупотребления.

Недостатки

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

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

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

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

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

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

Стандарты

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

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

Смотрите также

использованная литература