stringtranslate.com

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

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

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

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

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

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

Сертификат сервера TLS/SSL

Протокол Transport Layer Security (TLS) – как и его устаревший предшественник, протокол Secure Sockets Layer (SSL) – гарантирует, что связь между клиентским компьютером и сервером является безопасной. Протокол требует, чтобы сервер представил цифровой сертификат, подтверждающий, что он является предполагаемым местом назначения. Подключающийся клиент проводит проверку пути сертификации , гарантируя, что:

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

Поле Subject сертификата должно идентифицировать основное имя хоста сервера как Common Name . [ необходимо уточнение ] Имя хоста должно быть общедоступным, не использовать частные адреса или зарезервированные домены . [4] Сертификат может быть действителен для нескольких имен хостов (например, домена и его поддоменов). Такие сертификаты обычно называются сертификатами Subject Alternative Name (SAN) или Unified Communications Certificates (UCC) . Эти сертификаты содержат поле Subject Alternative Name , хотя многие CA также помещают их в поле Subject Common Name для обратной совместимости. Если некоторые имена хостов содержат звездочку (*), сертификат также может называться wildcard certificate .

После успешной проверки пути сертификации клиент может установить зашифрованное соединение с сервером.

Серверы, имеющие выход в Интернет, такие как публичные веб-серверы , должны получать свои сертификаты от доверенного публичного центра сертификации (CA).

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

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

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

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

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

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

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

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

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

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

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

Сертификат альтернативного имени субъекта

Пример раздела «Альтернативное имя субъекта» для доменных имен, принадлежащих Фонду Викимедиа

Сертификаты Subject Alternative Name (SAN) являются расширением X.509 , которое позволяет связать различные значения с сертификатом безопасности с помощью subjectAltNameполя. [6] Эти значения называются Subject Alternative Names (SAN). Имена включают: [7]

RFC  2818 (май 2000 г.) определяет альтернативные имена субъектов как предпочтительный метод добавления имен DNS в сертификаты, отменяя предыдущий метод размещения имен DNS в commonNameполе. [8] В версии Google ChromecommonName 58 (март 2017 г.) вообще удалена поддержка проверки поля, вместо этого просматриваются только имена субъектов (SAN). [8]

Как показано на рисунке раздела Wikimedia справа, поле SAN может содержать подстановочные знаки. [9] Не все поставщики поддерживают или одобряют смешивание подстановочных знаков в сертификатах SAN. [10]

Wildcard сертификат

Пример wildcard-сертификата на comifuro.net (обратите внимание на звездочку :)*

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

Например, один универсальный сертификат для https://*.example.comзащитит все эти поддомены в https://*.example.comдомене:

Вместо того, чтобы получать отдельные сертификаты для поддоменов, вы можете использовать один сертификат для всех основных доменов и поддоменов и сократить расходы. [11]

Поскольку подстановочный знак охватывает только один уровень поддоменов (звездочка не соответствует точкам), [12] эти домены не будут действительны для сертификатов: [13]

Обратите внимание на возможные исключения со стороны центров сертификации, например, сертификат wildcard-plus от DigiCert содержит автоматическое свойство «Plus» для голого домена example.com. [ требуется ссылка ]

Ограничения

В соответствии с RFC  2818 поддерживается только один уровень соответствия поддоменов . [1]

Невозможно получить подстановочный знак для сертификата расширенной проверки . [14] Обходным путем может быть добавление каждого имени виртуального хоста в расширение альтернативного имени субъекта (SAN), [15] [16] основная проблема заключается в том, что сертификат необходимо перевыпускать каждый раз при добавлении нового виртуального сервера. (Дополнительную информацию см. в разделе Безопасность транспортного уровня § Поддержка виртуальных серверов на основе имен .)

Wildcards могут быть добавлены как домены в многодоменных сертификатах или сертификатах унифицированных коммуникаций (UCC). Кроме того, wildcards сами по себе могут иметь subjectAltNameрасширения, включая другие wildcards. Например, wildcard-сертификат *.wikipedia.orgимеет *.m.wikimedia.orgв качестве Subject Alternative Name. Таким образом, он защищает www.wikipedia.orgтакже и совершенно другое имя веб-сайта meta.m.wikimedia.org. [17]

RFC  6125 выступает против сертификатов с подстановочными знаками по соображениям безопасности, в частности, против «частичных подстановочных знаков». [18]

Дополнительные примеры

Подстановочный знак применяется только к одному уровню доменного имени. *.example.comсовпадает sub1.example.com, но не example.comи неsub2.sub1.domain.com

Подстановочный знак может появляться в любом месте внутри метки как «частичный подстановочный знак» согласно ранним спецификациям [19]

f*.domain.comнормально. Он будет соответствовать frog.domain.com, но неfrog.super.domain.com
baz*.example.netв порядке и соответствуетbaz1.example.net
*baz.example.netв порядке и соответствуетfoobaz.example.net
b*z.example.netв порядке и соответствуетbuzz.example.net

Однако использование сертификатов с частичной подстановкой не рекомендуется. С 2011 года поддержка частичной подстановки является необязательной и явно запрещена в заголовках SubjectAltName, которые требуются для сертификатов с несколькими именами. [20] Все основные браузеры намеренно удалили поддержку сертификатов с частичной подстановкой; [21] [22] они приведут к ошибке «SSL_ERROR_BAD_CERT_DOMAIN». Аналогично, для стандартных библиотек в языках программирования типично не поддерживать сертификаты с частичной подстановкой. Например, любой сертификат с частичной подстановкой не будет работать с последними версиями как Python [23], так и Go. Таким образом,

Не разрешайте метку, состоящую только из подстановочных знаков, если только это не самая левая метка.

sub1.*.domain.comне допускается.

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

*.*.domain.com

Сертификат с *доменом верхнего уровня не допускается.

*.com

Слишком общее и не должно допускаться.

*

Международные доменные имена, закодированные в ASCII (A-метка), представляют собой метки, закодированные в ASCII и начинающиеся с xn--. URL-адреса с международными метками не могут содержать подстановочные знаки. [24]

xn--caf-dma.comявляетсяcafé.com
xn--caf-dma*.comне разрешено
Lw*.xn--caf-dma.comразрешено

Другие сертификаты

Общие поля

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

Пример

Это пример декодированного сертификата 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=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3 Действительность Не раньше: 18 апр. 2019 22:15:06 GMT Не позже: 17 апр. 22:15:06 2021 GMT Тема: C=US, ST=Texas, L=Houston, O=SSL Corp/серийный номер=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Частная организация/улица=3100 Richmond Ave/юрисдикцияST=Невада/юрисдикцияC=US Информация о публичном ключе субъекта: Алгоритм открытого ключа: 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 SCT: Подписанный сертификат. Временная метка: Версия: v1 (0x0) Идентификатор журнала: 87:75:BF:E7:59:7C:F8:8C:43:99 ... Временная метка: 18 апр. 2019 22:25:08.574 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 апр. 2019 22:25:08.461 GMT Расширения: нет Подпись: ecdsa-with-SHA256 30:45:02:20:43:80:9Э:19:90:ФД... Подписанный сертификат. Временная метка: Версия: v1 (0x0) Идентификатор журнала: 55:81:D4:C2:16:90:36:01:4A:EA ... Временная метка: 18 апр. 2019 22:25:08.769 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 центр сертификации (CA) отвечает за подписание сертификатов. Эти сертификаты действуют как введение между двумя сторонами, что означает, что CA действует как доверенная третья сторона. CA обрабатывает запросы от людей или организаций, запрашивающих сертификаты (называемых подписчиками), проверяет информацию и потенциально подписывает сертификат конечного субъекта на основе этой информации. Для эффективного выполнения этой роли CA должен иметь один или несколько широко доверенных корневых сертификатов или промежуточных сертификатов и соответствующие закрытые ключи. CA могут достичь этого широкого доверия, включив свои корневые сертификаты в популярное программное обеспечение или получив перекрестную подпись от другого CA, делегирующего доверие. Другие CA пользуются доверием в относительно небольшом сообществе, например, в бизнесе, и распространяются другими механизмами, такими как групповая политика Windows .

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

Корневые программы

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

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

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

Программа Mozilla Root Program работает публично, а ее список сертификатов является частью веб-браузера Firefox с открытым исходным кодом , поэтому она широко используется за пределами Firefox. [ требуется ссылка ] Например, хотя не существует общей программы Linux Root Program, многие дистрибутивы Linux, такие как Debian, [30] включают пакет, который периодически копирует содержимое списка доверия Firefox, который затем используется приложениями.

Программы root обычно предоставляют набор допустимых целей с сертификатами, которые они включают. Например, некоторые CA могут считаться доверенными для выдачи сертификатов сервера TLS, но не для сертификатов подписи кода. Это указывается набором битов доверия в системе хранения корневых сертификатов.

Отзыв

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

Для распространения информации об отзыве среди клиентов своевременность обнаружения отзыва (и, следовательно, окно для злоумышленника, чтобы использовать скомпрометированный сертификат) идет вразрез с использованием ресурсов при запросе статусов отзыва и проблемами конфиденциальности. [34] Если информация об отзыве недоступна (либо из-за несчастного случая, либо из-за атаки), клиенты должны решить, следует ли использовать отказоустойчивый режим и рассматривать сертификат как отозванный (и таким образом ухудшать доступность ) или отказоустойчивый режим и рассматривать его как неотозванный (и позволить злоумышленникам обойти отзыв). [35]

Из-за стоимости проверок отзыва и влияния на доступность потенциально ненадежных удаленных служб веб-браузеры ограничивают проверки отзыва, которые они будут выполнять, и будут выполнять их с помощью soft-fail. [36] Списки отзыва сертификатов слишком затратны для полосы пропускания для повседневного использования, а протокол статуса сертификата в режиме онлайн создает проблемы с задержкой соединения и конфиденциальностью. Были предложены другие схемы, но пока не были успешно развернуты для включения hard-fail проверки. [32]

Безопасность веб-сайта

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

Например, когда пользователь подключается к https://www.example.com/с помощью своего браузера, если браузер не выдает никаких предупреждающих сообщений о сертификате, то пользователь может быть теоретически уверен, что взаимодействие с https://www.example.com/эквивалентно взаимодействию с субъектом, контактирующим с адресом электронной почты, указанным в публичном регистраторе под "example.com", даже если этот адрес электронной почты может не отображаться нигде на веб-сайте. [ необходима цитата ] Никакие другие гарантии не подразумеваются. Кроме того, отношения между покупателем сертификата, оператором веб-сайта и генератором контента веб-сайта могут быть незначительными и не гарантируются. [ необходима цитата ] В лучшем случае сертификат гарантирует уникальность веб-сайта при условии, что сам веб-сайт не был скомпрометирован (взломан) или процесс выдачи сертификата не был нарушен.

Поставщик сертификатов может выбрать выпуск трех типов сертификатов, каждый из которых требует своей степени строгости проверки. В порядке возрастания строгости (и, естественно, стоимости) они следующие: проверка домена, проверка организации и расширенная проверка. Эти строгости в общих чертах согласованы добровольными участниками CA /Browser Forum . [ необходима цитата ]

Уровни проверки

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

Поставщик сертификатов выдаст покупателю сертификат с проверкой домена (DV), если покупатель сможет продемонстрировать один критерий проверки: право административного управления соответствующим доменом(ами) DNS.

Проверка организации

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

Расширенная проверка

Чтобы получить сертификат Extended Validation (EV), покупатель должен убедить поставщика сертификата в своей юридической идентичности, включая ручные проверки человеком. Как и в случае с сертификатами OV, поставщик сертификатов публикует свои критерии проверки EV через свою политику сертификации .

До 2019 года основные браузеры, такие как Chrome и Firefox, обычно предлагали пользователям визуальное указание юридической идентичности, когда сайт представлял сертификат EV. Это делалось путем отображения юридического имени перед доменом и ярко-зеленого цвета для выделения изменения. Большинство браузеров отказались от этой функции [37] [38], не предоставляя пользователю визуальной разницы в типе используемого сертификата. Это изменение последовало за проблемами безопасности, поднятыми экспертами-криминалистами, и успешными попытками покупки сертификатов EV для выдачи себя за известные организации, что доказывает неэффективность этих визуальных индикаторов и подчеркивает потенциальные злоупотребления. [39]

Слабые стороны

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

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

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

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

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

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

Стандарты

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

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

Ссылки

  1. ^ Ограничение на использование сертификата Wildcard SSL на QuovadisGlobal.com Ошибка цитирования: Именованная ссылка «:0» была определена несколько раз с различным содержимым (см. страницу справки ).
  2. ^ Alrawais, Arwa; Alhothaily, Abdulrahman; Cheng, Xiuzhen ; Hu, Chunqiang; Yu, Jiguo (2018-06-01). «SecureGuard: система проверки сертификатов в инфраструктуре открытых ключей». IEEE Transactions on Vehicular Technology . 67 (6): 5399–5408. doi :10.1109/TVT.2018.2805700. ISSN  0018-9545. S2CID  49270949. Архивировано из оригинала 26.08.2022 . Получено 26.08.2022 .
  3. ^ Chadwick, David W; Basden, Andrew (2001-10-31). «Оценка доверия к центру сертификации открытых ключей». Computers & Security . 20 (7): 592–611. doi :10.1016/S0167-4048(01)00710-6. ISSN  0167-4048. Архивировано из оригинала 26.02.2022 . Получено 26.02.2022 .
  4. ^ "Внутренние имена". Документация DigiCert .
  5. ^ "Бесплатный SSL-сертификат | IONOS от 1&1". www.ionos.co.uk . Архивировано из оригинала 2022-07-18 . Получено 2022-07-15 .
  6. ^ "x509v3_config - Формат конфигурации расширения сертификата X509 V3". OpenSSL . Получено 2020-01-16 .
  7. ^ RFC  5280: 4.2.1.6. Альтернативное имя субъекта
  8. ^ ab Medley, Joseph (март 2017 г.). «Устаревание и удаления в Chrome 58». Google Inc. Получено 2022-01-04 .
  9. ^ «Общее имя (CN) для wildcard-сертификата». Документация DigiCert.
  10. ^ «Wildcard и SAN: Понимание многоцелевых SSL-сертификатов» (PDF) . Thawte . 2013.
  11. ^ «Wildcard Certificate объясняется более простыми словами». 23 мая 2016 г.
  12. ^ "RFC 2818 - HTTP Over TLS". Internet Engineering Task Force . Май 2000. С. 5. Получено 15 декабря 2014 г. [ ...] *.a.com соответствует foo.a.com, но не bar.foo.a.com.
  13. ^ Newman, C. (июнь 1999 г.). RFC 2595 — Использование TLS с IMAP, POP3 и ACAP. Internet Engineering Task Force . стр. 3. doi : 10.17487/RFC2595 . RFC 2595. Получено 15 декабря 2014 г. Например , *.example.com будет соответствовать a.example.com, foo.example.com и т. д., но не будет соответствовать example.com.
  14. ^ "Руководство по выпуску и управлению сертификатами расширенной проверки, версия 1.5.2" (PDF) . Форум CA/Browser. 2014-10-16. стр. 10 . Получено 2014-12-15 . Универсальные сертификаты не допускаются для сертификатов EV.
  15. ^ x509v3_config Альтернативное имя субъекта
  16. ^ Опция SAN доступна для сертификатов EV SSL на Symantec.com.
  17. ^ SSLTools Поиск сертификата для wildcard SSL-сертификата Wikipedia.org
  18. ^ Saint-Andre, P.; Hodges, J. (март 2011 г.). RFC 6125 — Представление и проверка подлинности доменной службы приложений в инфраструктуре открытых ключей Интернета с использованием сертификатов X.509 (PKIX) в контексте безопасности транспортного уровня (TLS). Internet Engineering Task Force . стр. 31. doi : 10.17487/RFC6125 . RFC 6125. Получено 10.12.2014 . В этом документе указано, что подстановочный знак «*» НЕ ДОЛЖЕН включаться в представленные идентификаторы, но МОЖЕТ проверяться клиентами приложений (в основном для обеспечения обратной совместимости с развернутой инфраструктурой). [...] Несколько соображений безопасности оправдывают ужесточение правил: [...]
  19. ^ Рескорла, Э. (май 2000 г.). "RFC 2818 - HTTP Over TLS". tools.ietf.org . doi : 10.17487/RFC2818 . RFC 2818 . Получено 20 апреля 2019 г. .
  20. ^ Сент-Андре, П.; Ходжес, Дж. (март 2011 г.). "RFC 6125 - Представление и проверка подлинности доменной службы приложений в инфраструктуре открытых ключей Интернета с использованием сертификатов X.509 (PKIX) в контексте безопасности транспортного уровня (TLS)". tools.ietf.org . doi : 10.17487/RFC6125 . RFC 6125 . Получено 20 апреля 2019 г. .
  21. ^ "Запретить поддержку a*.example.net, *a.example.net и a*b.example.net при обработке подстановочных знаков сертификатов". Проекты Chromium, Google Inc. 3 декабря 2014 г. Получено 21 октября 2020 г.
  22. ^ "Ограничить поддержку DNS-идентификаторов с подстановочными знаками именами в форме *.example.com (не foo*.example.com)". Mozilla Foundation. 10 декабря 2014 г. Получено 21 октября 2020 г.
  23. ^ "Запретить поддержку a*.example.net, *a.example.net и a*b.example.net при обработке подстановочных знаков сертификатов". The Python Software Foundation. 26 ноября 2017 г. Получено 21 октября 2020 г.
  24. ^ «Ограничения на ввод данных для публичных сертификатов». Документация DigiCert .
  25. ^ "EMV CA". EMV Certificate Authority Worldwide. 2 декабря 2010 г. Архивировано из оригинала 4 июля 2020 г. Получено 20 января 2020 г.
  26. ^ "Политика сертификата X.509 для Федерального центра сертификации мостов (FBCA)" (PDF) . Архивировано (PDF) из оригинала 2021-03-18 . Получено 2021-05-07 .
  27. ^ "Политика сертификата X.509 для Федерального центра сертификации мостов (FBCA)" (PDF) . Архивировано (PDF) из оригинала 2021-03-18 . Получено 2021-05-07 .
  28. ^ «Статистика использования и доля рынка центров сертификации SSL для веб-сайтов, май 2020 г.». w3techs.com . Архивировано из оригинала 2022-06-30 . Получено 2020-05-01 .
  29. ^ "Политика корневых сертификатов – Проекты Chromium". www.chromium.org . Архивировано из оригинала 2017-03-20 . Получено 19-03-2017 .
  30. ^ "ca-certificates in Launchpad". launchpad.net . 30 апреля 2010 г. Архивировано из оригинала 2017-03-20 . Получено 19-03-2017 .
  31. ^ Смит, Дикинсон и Симонс 2020, стр. 1.
  32. ^ Аб Шеффер, Сен-Андре и Фоссати, 2022, 7.5. Отзыв сертификата.
  33. ^ Чунг и др. 2018, стр. 3.
  34. ^ Смит, Дикинсон и Симонс 2020, стр. 10.
  35. ^ Лариш и др. 2017, с. 542.
  36. ^ Смит, Дикинсон и Симонс 2020, стр. 1-2.
  37. ^ "Firefox-dev Google group - Intent to Ship: Move Extended Validation Information out of URL bar". groups.google.com . Архивировано из оригинала 2020-08-12 . Получено 2020-08-03 .
  38. ^ "Группа Google Chrome Security-dev - Предстоящие изменения в индикаторах идентификации Chrome". groups.google.com . Архивировано из оригинала 2020-06-07 . Получено 2020-08-03 .
  39. ^ «Сертификаты расширенной проверки (действительно, действительно) мертвы». troyhunt.com . 12 августа 2019 г. Архивировано из оригинала 2020-07-16 . Получено 2020-08-03 .
  40. ^ "Удаление DigiNotar компанией Mozilla". Mozilla.org. 2 сентября 2011 г. Архивировано из оригинала 3 июня 2012 г. Получено 30 июля 2012 г.
  41. ^ "Удаление DigitNotar компанией Google". Архивировано из оригинала 13 сентября 2011 г. Получено 30 июля 2012 г.
  42. ^ "Использование сертификатов статья на Mozilla.org". Mozilla.org. Архивировано из оригинала 12 июля 2012 года . Получено 30 июля 2012 года .
  43. ^ Ран Канетти: Универсальная составная подпись, сертификация и аутентификация. CSFW 2004, http://eprint.iacr.org/2003/239 Архивировано 28 августа 2009 г. на Wayback Machine
  44. ^ Бен Лори , Ян Голдберг (18 января 2014 г.). «Замена паролей в Интернете, также известная как пост-Сноуденовское оппортунистическое шифрование» (PDF) . Архивировано (PDF) из оригинала 27 октября 2014 г. . Получено 15 ноября 2014 г. . {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  45. ^ "NIST Computer Security Publications – NIST Special Publications (SPs)". csrc.nist.gov . Архивировано из оригинала 2017-09-17 . Получено 2016-06-19 .
  46. ^ "SP 800-32 Введение в технологию открытых ключей и федеральную инфраструктуру PKI" (PDF) . Национальный институт стандартов и технологий. Архивировано (PDF) из оригинала 2018-06-05 . Получено 2016-06-19 .
  47. ^ "SP 800-25 Федеральное агентство Использование технологии открытых ключей для цифровых подписей и аутентификации" (PDF) . Национальный институт стандартов и технологий. Архивировано (PDF) из оригинала 2018-06-02 . Получено 2016-06-19 .

Цитируемые работы