Jump to content

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

(Перенаправлено из сертификата Wildcard )

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

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

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

Виды сертификатов

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

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

[ редактировать ]

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

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

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

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

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

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

[ редактировать ]

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

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

Сертификат электронной почты

[ редактировать ]

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

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

Самозаверяющие и корневые сертификаты

[ редактировать ]

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

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

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

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

Подстановочный сертификат

[ редактировать ]
Пример подстановочного сертификата на comifuro.net (обратите внимание на звездочку : *)
Пример поля альтернативного имени субъекта (SAN)

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

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

  • payment.example.com
  • contact.example.com
  • login-secure.example.com
  • www.example.com

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

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

  • test.login.example.com

«Голый» домен действителен, если его добавить отдельно в качестве альтернативного имени субъекта ( SubjectAltName): [ 7 ]

  • example.com

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

Ограничения

[ редактировать ]

только один уровень сопоставления субдоменов в соответствии с Поддерживается РФК   2818 . [ 1 ]

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

Подстановочные знаки можно добавлять в качестве доменов в многодоменные сертификаты или сертификаты унифицированных коммуникаций (UCC). Кроме того, сами подстановочные знаки могут иметь subjectAltName расширения, включая другие подстановочные знаки. Например, групповой сертификат *.wikipedia.org имеет *.m.wikimedia.org в качестве альтернативного имени субъекта. Тем самым он обеспечивает www.wikipedia.org а также совершенно другое название сайта meta.m.wikimedia.org. [ 11 ]

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

Дальнейшие примеры

[ редактировать ]

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

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

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, которые необходимы для сертификатов с несколькими именами. [ 14 ] Все основные браузеры намеренно удалили поддержку сертификатов с частичным подстановочным знаком; [ 15 ] [ 16 ] они приведут к ошибке «SSL_ERROR_BAD_CERT_DOMAIN». Точно так же стандартные библиотеки языков программирования обычно не поддерживают сертификаты с частичным подстановочным знаком. Например, любой сертификат с частичным подстановочным знаком не будет работать с последними версиями Python. [ 17 ] и Иди. Таким образом,

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

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

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

*.*.domain.com

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

*.com

Слишком общий подход, и его нельзя допускать.

*

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

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

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

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

[ редактировать ]
  • Сертификат EMV: EMV — это метод оплаты, основанный на техническом стандарте для платежных карт , платежных терминалов и банкоматов (банкоматов). В платежные карты EMV предварительно загружен сертификат эмитента карты, подписанный центром сертификации EMV. [ 18 ] для проверки подлинности платежной карты во время платежной операции.
  • Сертификат подписи кода . Сертификаты могут проверять приложения (или их двоичные файлы ), чтобы гарантировать, что они не были подделаны во время доставки.
  • Квалифицированный сертификат : сертификат, идентифицирующий физическое лицо, обычно для электронной подписи целей . Они чаще всего используются в Европе, где правила eIDAS стандартизируют их и требуют их признания.
  • Сертификат на основе ролей: определенные в политике сертификатов X.509 Федерального центра сертификации мостов (FBCA) , сертификаты на основе ролей «определяют конкретную роль, от имени которой подписчик имеет право действовать, а не имя подписчика, и выдаются в интересах поддержки принятой деловой практики». [ 19 ]
  • Групповой сертификат: определен в политике сертификатов X.509 Федерального центра сертификации мостов (FBCA) для «случаев, когда несколько объектов действуют в одном качестве и когда невозможность отказа от транзакций нежелательна». [ 20 ]

Общие поля

[ редактировать ]

Это одни из наиболее распространенных полей сертификатов. Большинство сертификатов содержат ряд полей, не перечисленных здесь. Обратите внимание, что с точки зрения представления сертификата 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 поля показывают все соответствующие варианты использования.

Использование в Европейском Союзе

[ редактировать ]

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

Центры сертификации

[ редактировать ]
Процедура получения сертификата открытого ключа

В модели доверия X.509 за подпись сертификатов отвечает центр сертификации (CA). Эти сертификаты действуют как средство знакомства между двумя сторонами, а это означает, что центр сертификации выступает в качестве доверенной третьей стороны. Центр сертификации обрабатывает запросы от людей или организаций, запрашивающих сертификаты (называемых подписчиками), проверяет информацию и потенциально подписывает сертификат конечного объекта на основе этой информации. Чтобы эффективно выполнять эту роль, центр сертификации должен иметь один или несколько корневых сертификатов с широким доверием или промежуточных сертификатов и соответствующие закрытые ключи. Центры сертификации могут добиться такого широкого доверия, включив свои корневые сертификаты в популярное программное обеспечение или получив перекрестную подпись от другого центра сертификации, делегирующего доверие. Другим центрам сертификации доверяют в относительно небольшом сообществе, например в бизнесе, и они распространяются с помощью других механизмов, таких как групповая политика Windows .

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

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

[ редактировать ]

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

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

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

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

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

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

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

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

Безопасность сайта

[ редактировать ]

Чаще всего сертификаты используются для веб-сайтов на базе 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. Это было сделано путем отображения официального имени перед доменом и ярко-зеленого цвета, чтобы подчеркнуть изменение. В большинстве браузеров эта функция устарела. [ 30 ] [ 31 ] не обеспечивая пользователю визуальной разницы в типе используемого сертификата. Это изменение последовало за проблемами безопасности, поднятыми экспертами-криминалистами, и успешными попытками приобрести сертификаты электромобилей, чтобы выдать себя за известные организации, доказав неэффективность этих визуальных индикаторов и выявив потенциальные злоупотребления. [ 32 ]

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

[ редактировать ]

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

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

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

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

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

[ редактировать ]

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

Стандарты

[ редактировать ]

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

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

См. также

[ редактировать ]
  1. ^ Перейти обратно: а б с Ограничение сертификата Wildcard SSL на QuovadisGlobal.com Ошибка цитирования: именованная ссылка «:0» была определена несколько раз с разным содержимым (см. страницу справки ).
  2. ^ Альравайс, Арва; Альхотайли, Абдулрахман; Ченг, Сючжэнь ; Ху, Чунцян; Ю, Цзиго (01.06.2018). «SecureGuard: система проверки сертификатов в инфраструктуре открытых ключей» . Транзакции IEEE по автомобильным технологиям . 67 (6): 5399–5408. дои : 10.1109/TVT.2018.2805700 . ISSN   0018-9545 . S2CID   49270949 . Архивировано из оригинала 26 августа 2022 г. Проверено 26 августа 2022 г.
  3. ^ Чедвик, Дэвид В.; Басден, Эндрю (31 октября 2001 г.). «Оценка доверия к центру сертификации открытых ключей» . Компьютеры и безопасность . 20 (7): 592–611. дои : 10.1016/S0167-4048(01)00710-6 . ISSN   0167-4048 . Архивировано из оригинала 26 февраля 2022 г. Проверено 26 февраля 2022 г.
  4. ^ «Бесплатный SSL-сертификат | IONOS от 1&1» . www.ionos.co.uk . Архивировано из оригинала 18 июля 2022 г. Проверено 15 июля 2022 г.
  5. ^ «Подстановочный сертификат, объясненный более простыми словами» . 23 мая 2016 г.
  6. ^ «RFC 2818 — HTTP через TLS» . Рабочая группа по интернет-инжинирингу . Май 2000. с. 5 . Проверено 15 декабря 2014 г. [...] *.a.com соответствует foo.a.com, но не соответствует bar.foo.a.com.
  7. ^ Ньюман, К. (июнь 1999 г.). RFC 2595 — Использование TLS с IMAP, POP3 и ACAP . Рабочая группа по интернет-инжинирингу . п. 3. дои : 10.17487/RFC2595 . РФК 2595 . Проверено 15 декабря 2014 г. Например, *.example.com будет соответствовать a.example.com, foo.example.com и т. д., но не будет соответствовать example.com.
  8. ^ «Руководство по выдаче сертификатов расширенной проверки и управлению ими, версия 1.5.2» (PDF) . Форум CA/браузера. 16 октября 2014 г. п. 10 . Проверено 15 декабря 2014 г. Сертификаты Wildcard не допускаются для сертификатов EV.
  9. ^ x509v3_config Альтернативное имя субъекта
  10. ^ Опция SAN доступна для сертификатов EV SSL на Symantec.com.
  11. ^ SSLTools Сертификат Поиск SSL-сертификата с подстановочными знаками Wikipedia.org
  12. ^ Сен-Андре, П.; Ходжес, Дж. (март 2011 г.). RFC 6125 — Представление и проверка идентичности доменной службы приложений в инфраструктуре открытых ключей Интернета с использованием сертификатов X.509 (PKIX) в контексте безопасности транспортного уровня (TLS) . Рабочая группа по интернет-инжинирингу . п. 31. дои : 10.17487/RFC6125 . РФК 6125 . Проверено 10 декабря 2014 г. В этом документе указано, что подстановочный знак «*» НЕ ДОЛЖЕН включаться в представленные идентификаторы, но МОЖЕТ проверяться клиентами приложений (в основном ради обратной совместимости с развернутой инфраструктурой). [...] Несколько соображений безопасности оправдывают ужесточение правил: [...]
  13. ^ Рескорла, Э. (май 2000 г.). «RFC 2818 — HTTP через TLS» . www.tools.ietf.org . дои : 10.17487/RFC2818 . РФК 2818 . Проверено 20 апреля 2019 г.
  14. ^ Сен-Андре, П.; Ходжес, Дж. (март 2011 г.). «RFC 6125 — Представление и проверка идентичности доменных служб приложений в инфраструктуре открытых ключей Интернета с использованием сертификатов X.509 (PKIX) в контексте безопасности транспортного уровня (TLS)» . www.tools.ietf.org . дои : 10.17487/RFC6125 . РФК 6125 . Проверено 20 апреля 2019 г.
  15. ^ «Запретить поддержку a*.example.net, *a.example.net и a*b.example.net при обработке подстановочных знаков сертификата» . Проекты Chromium, Google Inc., 3 декабря 2014 г. Проверено 21 октября 2020 г.
  16. ^ «Ограничить поддержку DNS-идентификаторов с подстановочными знаками именами в форме *.example.com (не foo*.example.com)» . Фонд Мозилла. 10 декабря 2014 года . Проверено 21 октября 2020 г.
  17. ^ «Запретить поддержку a*.example.net, *a.example.net и a*b.example.net при обработке подстановочных знаков сертификата» . Фонд программного обеспечения Python. 26 ноября 2017 года . Проверено 21 октября 2020 г.
  18. ^ «ЭМВ ЦА» . Центр сертификации EMV по всему миру. 2 декабря 2010 г. Архивировано из оригинала 4 июля 2020 г. . Проверено 20 января 2020 г.
  19. ^ «Политика сертификатов X.509 для Федерального центра сертификации мостов (FBCA)» (PDF) . Архивировано (PDF) из оригинала 18 марта 2021 г. Проверено 7 мая 2021 г.
  20. ^ «Политика сертификатов X.509 для Федерального центра сертификации мостов (FBCA)» (PDF) . Архивировано (PDF) из оригинала 18 марта 2021 г. Проверено 7 мая 2021 г.
  21. ^ «Статистика использования и рыночная доля центров сертификации SSL для веб-сайтов, май 2020 г.» . w3techs.com . Архивировано из оригинала 30 июня 2022 г. Проверено 1 мая 2020 г.
  22. ^ «Политика корневых сертификатов — проекты Chromium» . www.chromium.org . Архивировано из оригинала 20 марта 2017 г. Проверено 19 марта 2017 г.
  23. ^ «ca-сертификаты в Launchpad» . launchpad.net . 30 апреля 2010 г. Архивировано из оригинала 20 марта 2017 г. Проверено 19 марта 2017 г.
  24. ^ Смит, Дикинсон и Симонс 2020 , стр. 1.
  25. ^ Перейти обратно: а б Шеффер, Сен-Андре и Фоссати 2022 , 7.5. Отзыв сертификата.
  26. ^ Чунг и др. 2018 , с. 3.
  27. ^ Смит, Дикинсон и Симонс 2020 , стр. 10.
  28. ^ Лариш и др. 2017 , с. 542
  29. ^ Смит, Дикинсон и Симонс 2020 , стр. 1-2.
  30. ^ «Группа Google Firefox-dev – намерение выпустить: переместить информацию расширенной проверки из строки URL» . groups.google.com . Архивировано из оригинала 12 августа 2020 г. Проверено 3 августа 2020 г.
  31. ^ «Группа разработчиков безопасности Chrome в Google: предстоящие изменения в индикаторах идентификации Chrome» . groups.google.com . Архивировано из оригинала 07.06.2020 . Проверено 3 августа 2020 г.
  32. ^ «Сертификаты расширенной проверки (действительно, действительно) мертвы» . troyhunt.com . 12 августа 2019 г. Архивировано из оригинала 16 июля 2020 г. Проверено 3 августа 2020 г.
  33. ^ «Удаление DigiNotar с помощью Mozilla» . Мозилла.орг. 2 сентября 2011 г. Архивировано из оригинала 3 июня 2012 г. Проверено 30 июля 2012 г.
  34. ^ «Удаление DigitNotar Google» . Архивировано из оригинала 13 сентября 2011 года . Проверено 30 июля 2012 г.
  35. ^ «Статья об использовании сертификатов на Mozilla.org» . Мозилла.орг. Архивировано из оригинала 12 июля 2012 года . Проверено 30 июля 2012 г.
  36. ^ Ран Канетти: Универсальная составная подпись, сертификация и аутентификация. CSFW 2004, http://eprint.iacr.org/2003/239. Архивировано 28 августа 2009 г. в Wayback Machine.
  37. ^ Бен Лори , Ян Голдберг (18 января 2014 г.). «Замена паролей в Интернете, известная как оппортунистическое шифрование после Сноудена» (PDF) . Архивировано (PDF) из оригинала 27 октября 2014 г. Проверено 15 ноября 2014 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  38. ^ «Публикации NIST по компьютерной безопасности – Специальные публикации NIST (SP)» . csrc.nist.gov . Архивировано из оригинала 17 сентября 2017 г. Проверено 19 июня 2016 г.
  39. ^ «SP 800-32 Введение в технологию открытых ключей и федеральную инфраструктуру PKI» (PDF) . Национальный институт стандартов и технологий. Архивировано (PDF) из оригинала 5 июня 2018 г. Проверено 19 июня 2016 г.
  40. ^ «SP 800-25 Использование технологии открытого ключа Федеральным агентством для цифровых подписей и аутентификации» (PDF) . Национальный институт стандартов и технологий. Архивировано (PDF) из оригинала 02 июня 2018 г. Проверено 19 июня 2016 г.

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

[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: ac8316f46810820d4eb756a22e737a43__1723070160
URL1:https://arc.ask3.ru/arc/aa/ac/43/ac8316f46810820d4eb756a22e737a43.html
Заголовок, (Title) документа по адресу, URL1:
Public key certificate - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)