✖


Jump to content

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

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

В криптографии сертификат открытого ключа , также известный как цифровой сертификат или сертификат личности , представляет собой электронный документ, используемый для подтверждения действительности открытого ключа . [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, сертификаты электронной почты, сертификаты подписи кода и квалифицированные сертификаты — все это сертификаты конечного объекта.

Другие сертификаты [ править ]

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

Общие поля [ править ]

См. также: 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 . [8]

Корневые программы [ править ]

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

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

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

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

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

Отзыв [ править ]

Основная статья: Отзыв сертификата

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

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

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

Безопасность сайта [ править ]

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

Слабые стороны [ править ]

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

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

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

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

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

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

Стандарты [ править ]

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

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

См. также [ править ]

Ссылки [ править ]

  1. ↑ Перейти обратно: Перейти обратно: а б «Список сертификатов, включенных Mozilla» . Мозилла.орг. Архивировано из оригинала 3 августа 2012 года . Проверено 30 июля 2012 г.
  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. ^ «ЭМВ ЦА» . Центр сертификации EMV по всему миру. 2 декабря 2010 г. Архивировано из оригинала 4 июля 2020 г. . Проверено 20 января 2020 г.
  6. ^ «Политика сертификатов X.509 для Федерального центра сертификации мостов (FBCA)» (PDF) . Архивировано (PDF) из оригинала 18 марта 2021 г. Проверено 7 мая 2021 г.
  7. ^ «Политика сертификатов X.509 для Федерального центра сертификации мостов (FBCA)» (PDF) . Архивировано (PDF) из оригинала 18 марта 2021 г. Проверено 7 мая 2021 г.
  8. ^ «Статистика использования и рыночная доля центров сертификации SSL для веб-сайтов, май 2020 г.» . w3techs.com . Архивировано из оригинала 30 июня 2022 г. Проверено 1 мая 2020 г.
  9. ^ «Политика корневых сертификатов — проекты Chromium» . www.chromium.org . Архивировано из оригинала 20 марта 2017 г. Проверено 19 марта 2017 г.
  10. ^ «ca-сертификаты в Launchpad» . launchpad.net . 30 апреля 2010 г. Архивировано из оригинала 20 марта 2017 г. Проверено 19 марта 2017 г.
  11. ^ Смит, Дикинсон и Симонс 2020 , стр. 1.
  12. ↑ Перейти обратно: Перейти обратно: а б Шеффер, Сен-Андре и Фоссати 2022 , 7.5. Отзыв сертификата.
  13. ^ Чунг и др. 2018 , с. 3.
  14. ^ Смит, Дикинсон и Симонс 2020 , стр. 10.
  15. ^ Лариш и др. 2017 , с. 542
  16. ^ Смит, Дикинсон и Симонс 2020 , стр. 1-2.
  17. ^ «Группа Google Firefox-dev – намерение выпустить: переместить информацию расширенной проверки из строки URL» . groups.google.com . Архивировано из оригинала 12 августа 2020 г. Проверено 3 августа 2020 г.
  18. ^ «Группа разработчиков безопасности Chrome в Google: предстоящие изменения в индикаторах идентификации Chrome» . groups.google.com . Архивировано из оригинала 07.06.2020 . Проверено 3 августа 2020 г.
  19. ^ «Сертификаты расширенной проверки (действительно, действительно) мертвы» . troyhunt.com . 12 августа 2019 г. Архивировано из оригинала 16 июля 2020 г. Проверено 3 августа 2020 г.
  20. ^ «Удаление DigiNotar с помощью Mozilla» . Мозилла.орг. 2 сентября 2011 г. Архивировано из оригинала 3 июня 2012 г. Проверено 30 июля 2012 г.
  21. ^ «Удаление DigitNotar Google» . Архивировано из оригинала 13 сентября 2011 года . Проверено 30 июля 2012 г.
  22. ^ «Статья об использовании сертификатов на Mozilla.org» . Мозилла.орг. Архивировано из оригинала 12 июля 2012 года . Проверено 30 июля 2012 г.
  23. ^ Ран Канетти: Универсальная составная подпись, сертификация и аутентификация. CSFW 2004, http://eprint.iacr.org/2003/239. Архивировано 28 августа 2009 г. в Wayback Machine.
  24. ^ Бен Лори , Ян Голдберг (18 января 2014 г.). «Замена паролей в Интернете, известная как оппортунистическое шифрование после Сноудена» (PDF) . Архивировано (PDF) из оригинала 27 октября 2014 г. Проверено 15 ноября 2014 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  25. ^ «Публикации NIST по компьютерной безопасности – Специальные публикации NIST (SP)» . csrc.nist.gov . Архивировано из оригинала 17 сентября 2017 г. Проверено 19 июня 2016 г.
  26. ^ «SP 800-32 Введение в технологию открытых ключей и федеральную инфраструктуру PKI» (PDF) . Национальный институт стандартов и технологий. Архивировано (PDF) из оригинала 5 июня 2018 г. Проверено 19 июня 2016 г.
  27. ^ «SP 800-25 Использование технологии открытого ключа Федеральным агентством для цифровых подписей и аутентификации» (PDF) . Национальный институт стандартов и технологий. Архивировано (PDF) из оригинала 02 июня 2018 г. Проверено 19 июня 2016 г.

Цитируемые работы [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Public_key_certificate&oldid=1227516719"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 29decd0cb82e5adfe86de10aef41a694__1717643580
URL1:https://arc.ask3.ru/arc/aa/29/94/29decd0cb82e5adfe86de10aef41a694.html
Заголовок, (Title) документа по адресу, URL1:
Public key certificate - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)