13:45 Сертификат открытого ключа | |
| В криптографии , открытый ключ сертификат, также известный как цифровой сертификат или удостоверение личности, представляет собой электронный документ , используемый , чтобы доказать право собственности на открытом ключе . Сертификат включает в себя информацию о ключе, информацию о личности его владельца (называемого субъектом) и цифровую подпись субъекта, который проверил содержимое сертификата (называемого эмитентом). Если подпись действительна, и программное обеспечение, проверяющее сертификат, доверяет эмитенту, то оно может использовать этот ключ для безопасной связи с субъектом сертификата. В шифровании электронной почты , подписи кода иВ системах электронной подписи субъектом сертификата обычно является человек или организация. Однако в безопасности транспортного уровня (TLS) субъектом сертификата обычно является компьютер или другое устройство, хотя сертификаты TLS могут идентифицировать организации или отдельных лиц в дополнение к их основной роли в идентификации устройств. TLS, иногда называемый его старым названием Secure Sockets Layer (SSL), известен тем, что является частью HTTPS , протокола для безопасного просмотра веб-страниц . В типичной схеме инфраструктуры открытого ключа (PKI) эмитентом сертификата является центр сертификации (CA), обычно это компания, которая взимает с клиентов плату за выдачу им сертификатов. В отличие от этого в схеме сети доверия люди подписывают ключи друг друга напрямую в формате, который выполняет функцию, аналогичную сертификату открытого ключа. Сертификат сервера TLS / SSL В TLS (обновленная замена SSL) сервер должен представить сертификат как часть начальной настройки соединения. Клиент подключения к этому серверу будет выполнять алгоритм проверки пути сертификации : Тема сертификата соответствует имени хоста (то есть имени домена), к которому клиент пытается подключиться; Сертификат подписан доверенным центром сертификации. Основное имя хоста ( доменное имя веб-сайта) указывается как Общее имя в поле Тема сертификата. Сертификат может быть действительным для нескольких имен хостов (несколько веб-сайтов). Такие сертификаты обычно называют сертификатами альтернативного имени субъекта (SAN) или сертификатами унифицированных коммуникаций (UCC) . Эти сертификаты содержат поле Subject Alternative Name , хотя многие CA также помещают их в поле Subject Common Name для обратной совместимости. Если некоторые из имен хостов содержат звездочку (*), сертификат также можно назвать групповым сертификатом . Сервер TLS может быть настроен с самозаверяющим сертификатом. В этом случае клиенты, как правило, не могут проверить сертификат и прерывают соединение, если проверка сертификата не отключена. Согласно приложениям, SSL-сертификаты могут быть классифицированы на три типа: Проверка домена SSL; Проверка организации SSL; Расширенная проверка SSL. Сертификат клиента TLS / SSL Клиентские сертификаты менее распространены, чем серверные сертификаты, и используются для проверки подлинности клиента, подключающегося к службе TLS, например, для обеспечения контроля доступа. Поскольку большинство служб предоставляют доступ отдельным пользователям, а не устройствам, большинство клиентских сертификатов содержат адрес электронной почты или личное имя, а не имя хоста. Кроме того, поскольку проверкой подлинности обычно управляет поставщик услуг, клиентские сертификаты обычно не выдаются общедоступным центром сертификации, который предоставляет сертификаты сервера. Вместо этого оператор службы, которой требуются клиентские сертификаты, обычно использует собственный внутренний ЦС для их выдачи. Клиентские сертификаты поддерживаются многими веб-браузерами, но большинство служб используют пароли и файлы cookie для аутентификации пользователей, а не клиентские сертификаты. Клиентские сертификаты более распространены в системах RPC , где они используются для аутентификации устройств, чтобы гарантировать, что только авторизованные устройства могут выполнять определенные вызовы RPC. Сертификат электронной почты В протоколе S / MIME для защищенной электронной почты отправителям необходимо выяснить, какой открытый ключ использовать для любого получателя. Они получают эту информацию из сертификата электронной почты. Некоторые общедоступные центры сертификации предоставляют сертификаты электронной почты, но чаще всего S / MIME используется при обмене данными внутри определенной организации, и эта организация использует свой собственный центр сертификации, которому доверяют участники этой системы электронной почты. Это некоторые из наиболее распространенных полей в сертификатах. Большинство сертификатов содержат ряд полей, не перечисленных здесь. Обратите внимание, что с точки зрения представления сертификата X.509, сертификат не является «плоским», но содержит эти поля, вложенные в различные структуры в сертификате. Серийный номер : используется для уникальной идентификации сертификата в системах ЦС. В частности, это используется для отслеживания информации об отзыве. Предмет : объект, которому принадлежит сертификат: машина, физическое лицо или организация. Эмитент : лицо, которое проверило информацию и подписало сертификат. Не раньше : самое раннее время и дата, когда сертификат действителен. Обычно устанавливается за несколько часов или дней до момента выдачи сертификата, чтобы избежать проблем с перекосом часов . Не после : время и дата, после которых сертификат больше не действителен. Использование ключа : допустимое криптографическое использование открытого ключа сертификата. Общие значения включают проверку цифровой подписи, шифрование ключа и подпись сертификата. Расширенное использование ключа : приложения, в которых может использоваться сертификат. Общие значения включают аутентификацию сервера TLS, защиту электронной почты и подпись кода. Открытый ключ : открытый ключ, принадлежащий субъекту сертификата. Алгоритм подписи : алгоритм, используемый для подписи сертификата открытого ключа. Подпись : подпись тела сертификата закрытым ключом эмитента. Некоторые основные программы содержат список центров сертификации, которым доверяют по умолчанию. Это облегчает конечным пользователям проверку сертификатов, а людям и организациям, которые запрашивают сертификаты, легче узнать, какие центры сертификации могут выдать сертификат, который будет широко доверять. Это особенно важно в HTTPS, где оператор веб-сайта обычно хочет получить сертификат, которому доверяют почти все потенциальные посетители своего веб-сайта. Политики и процессы, используемые поставщиком для определения того, каким центрам сертификации следует доверять их программному обеспечению, называются корневыми программами. Наиболее влиятельные корневые программы: Корневая программа Microsoft Программа Apple Root Корневая программа Mozilla Oracle Java корневая программа Adobe AATL Список утвержденных доверенных сертификатов Adobe и корневые программы EUTL (используются для подписи документов) Браузеры, отличные от Firefox, обычно используют возможности операционной системы, чтобы решить, каким центрам сертификации доверять. Так, например, Chrome в Windows доверяет центрам сертификации, включенным в корневую программу Microsoft, в то время как в macOS или iOS Chrome доверяет центрам сертификации в корневой программе Apple. Edge и Safari также используют свои соответствующие хранилища доверия операционной системы, но каждое из них доступно только в одной ОС. Firefox использует доверенное хранилище Mozilla Root Program на всех платформах. Корневая программа Mozilla работает публично, и ее список сертификатов является частью веб-браузера Firefox с открытым исходным кодом, поэтому она широко используется вне Firefox. Например, несмотря на то, что не существует обычной Linux Root Program, многие дистрибутивы Linux, такие как Debian, [5] включают в себя пакет, который периодически копирует содержимое списка доверия Firefox, который затем используется приложениями. Корневые программы обычно предоставляют набор действительных целей с сертификатами, которые они включают. Например, некоторые ЦС могут считаться доверенными для выдачи сертификатов сервера TLS, но не для сертификатов подписи кода. На это указывает набор битов доверия в системе хранения корневых сертификатов. Чаще всего сертификаты используются для веб-сайтов на основе HTTPS . Через веб - браузер Подтверждает , что HTTPS веб - сервер является подлинным, так что пользователь может чувствовать себя в безопасности , что его / ее взаимодействие с веб - сайта не имеет перехватчика и что веб - сайт , который он претендует. Эта безопасность важна для электронной коммерции . На практике оператор веб-сайта получает сертификат, обращаясь в центр сертификации с запросом на подпись сертификата., Запрос сертификата представляет собой электронный документ, который содержит название веб-сайта, информацию о компании и открытый ключ. Поставщик сертификата подписывает запрос, создавая публичный сертификат. Во время просмотра веб-страниц этот общедоступный сертификат передается любому веб-браузеру, который подключается к веб-сайту, и доказывает веб-браузеру, что поставщик считает, что он выдал сертификат владельцу веб-сайта. Например, когда пользователь подключается к https://www.example.com/своему браузеру, и если браузер не выдает предупреждающее сообщение о сертификате, то теоретически пользователь может быть уверен, что взаимодействие с https://www.example.com/ним эквивалентно взаимодействию с объектом, контактирующим с адресом электронной почты, указанным в общедоступный регистратор в разделе "example.com", даже если этот адрес электронной почты может нигде не отображаться на веб-сайте. Никаких других поручительств не предусмотрено. Кроме того, отношения между покупателем сертификата, оператором веб-сайта и генератором контента веб-сайта могут быть ненадежными и не гарантированы. В лучшем случае сертификат гарантирует уникальность веб-сайта при условии, что сам веб-сайт не был скомпрометирован (взломан) или процесс выдачи сертификата подорван. Поставщик сертификатов может принять решение о выдаче трех типов сертификатов, каждый из которых требует своей степени строгости проверки. В порядке увеличения строгости (и, естественно, стоимости) это: проверка домена, проверка организации и расширенная проверка. Об этих суровостях свободно соглашаются добровольные участники CA / Browser Forum . Проверка организации Поставщик сертификатов выдаст покупателю сертификат класса проверки организации (OV), если покупатель может соответствовать двум критериям: право административно управлять данным доменным именем и, возможно, фактическое существование организации как юридического лица. Поставщик сертификата публикует свои критерии проверки OV через свою Политику сертификации . Чтобы приобрести сертификат расширенной проверки (EV), покупатель должен убедить поставщика сертификата в его юридической идентичности, включая проверки вручную человеком. Как и в случае с сертификатами OV, поставщик сертификатов публикует свои критерии проверки EV через свою политику сертификатов . Браузеры обычно предлагают пользователям визуальную индикацию юридической идентичности, когда сайт представляет сертификат EV. Большинство браузеров показывают официальное имя перед доменом и используют ярко-зеленый цвет, чтобы выделить изменения. Таким образом, пользователь может видеть, что его личность была проверена. Веб - браузер не даст предупреждения пользователю , если веб - сайт вдруг представляет другой сертификат, даже если этот сертификат имеет меньшее число бит ключа, даже если она имеет другой провайдер, и даже если предыдущий сертификат имел срок годности далеко в будущее. Однако, переход от сертификата EV к сертификату не-EV будет очевиден, поскольку зеленая полоса больше не будет отображаться. В тех случаях, когда поставщики сертификатов находятся под юрисдикцией правительств, эти правительства могут иметь право приказать поставщику генерировать любой сертификат, например, для целей правоохранительной деятельности. Дочерние оптовые поставщики сертификатов также могут создавать любые сертификаты. Все веб-браузеры поставляются с обширным встроенным списком доверенных корневых сертификатов , многие из которых контролируются организациями, которые могут быть незнакомы пользователю. Каждая из этих организаций может бесплатно выпустить любой сертификат для любого веб-сайта и иметь гарантию, что веб-браузеры, включающие его корневые сертификаты, примут его как подлинный. В этом случае конечные пользователи должны полагаться на разработчика программного обеспечения браузера для управления его встроенным списком сертификатов и на поставщиков сертификатов для правильного поведения и информирования разработчика браузера о проблемных сертификатах. Хотя это было редкостью, были случаи, когда выдавались поддельные сертификаты: в некоторых случаях браузеры обнаружили мошенничество; в других прошло некоторое время, прежде чем разработчики браузеров удалили эти сертификаты из своего программного обеспечения. Список встроенных сертификатов также не ограничивается теми, что предоставляются разработчиком браузера: пользователи (и в некоторой степени приложения) могут свободно расширять список для специальных целей, например для внутренних сетей компании. Это означает, что если кто-то получит доступ к компьютеру и сможет установить новый корневой сертификат в браузере, этот браузер распознает веб-сайты, использующие вставленный сертификат, как законные. Для доказуемой безопасности эта зависимость от чего-то внешнего по отношению к системе приводит к тому, что любая схема сертификации открытых ключей должна опираться на какое-то специальное допущение настройки, такое как наличие центра сертификации . Несмотря на ограничения, описанные выше, TLS с проверкой подлинности на основе сертификата считается обязательным во всех правилах безопасности всякий раз, когда веб-сайт размещает конфиденциальную информацию или выполняет существенные транзакции. Это связано с тем, что на практике, несмотря на описанные выше недостатки , веб-сайты, защищенные сертификатами открытых ключей, все еще более безопасны, чем незащищенные веб-сайты http: // | |
|
| |
| Всього коментарів: 0 | |