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

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

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

Наиболее распространенный формат сертификатов открытых ключей определяется 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 как часть своих пакетов.

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

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

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

• test.login.example.com

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

• example.com

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

Ограничения

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

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

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

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

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

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

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

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

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

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. для проверки подлинности платежной карты во время платежной операции.
• Сертификат подписи кода . Сертификаты могут проверять приложения (или их двоичные файлы ), чтобы гарантировать, что они не были подделаны во время доставки.
• Квалифицированный сертификат : сертификат, идентифицирующий физическое лицо, обычно для электронной подписи целей . Они чаще всего используются в Европе, где правила eIDAS стандартизируют их и требуют их признания.
• Сертификат на основе ролей: определенные в политике сертификатов X.509 Федерального центра сертификации мостов (FBCA) , сертификаты на основе ролей «определяют конкретную роль, от имени которой подписчик имеет право действовать, а не имя подписчика, и выдаются в интересах поддержки принятой деловой практики».
• Групповой сертификат: определен в Политике сертификатов X.509 Федерального центра сертификации мостов (FBCA) для «случаев, когда несколько объектов действуют в одном качестве и когда невозможность отказа от транзакций нежелательна».

Общие поля

См. также: X.509 § Структура сертификата.

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

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

Пример

Это пример декодированного сертификата SSL/TLS, полученного с веб-сайта SSL.com. Общее наименование эмитента (CN) отображается как SSL.com EV SSL Intermediate CA RSA R3, идентифицируя это как сертификат расширенной проверки (EV). Проверенная информация о владельце сайта (SSL Corp) находится в Subject поле. X509v3 Subject Alternative Name Поле содержит список доменных имен, на которые распространяется сертификат. X509v3 Extended Key Usage и X509v3 Key Usage поля показывают все соответствующие варианты использования.

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

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

            X509v3 Subject Alternative Name: 
                DNS:www.ssl.com, DNS:answers.ssl.com, DNS:faq.ssl.com, DNS:info.ssl.com, DNS:links.ssl.com, DNS:reseller.ssl.com, DNS:secure.ssl.com, DNS:ssl.com, DNS:support.ssl.com, DNS:sws.ssl.com, DNS:tools.ssl.com
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.1
                Policy: 1.2.616.1.113527.2.5.1.1
                Policy: 1.3.6.1.4.1.38064.1.1.1.5
                  CPS: https://www.ssl.com/repository

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

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

            X509v3 Subject Key Identifier: 
                E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 87:75:BF:E7:59:7C:F8:8C:43:99 ...
                    Timestamp : Apr 18 22:25:08.574 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:40:51:53:90:C6:A2 ...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB ...
                    Timestamp : Apr 18 22:25:08.461 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:43:80:9E:19:90:FD ...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 55:81:D4:C2:16:90:36:01:4A:EA ...
                    Timestamp : Apr 18 22:25:08.769 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:C1:3E:9F:F0:40 ...
    Signature Algorithm: sha256WithRSAEncryption
         36:07:e7:3b:b7:45:97:ca:4d:6c ...

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

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

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

Основная статья: Центр сертификации

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

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

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

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

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

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

• Корневая программа Microsoft
• Корневая программа Apple
• Корневая программа Mozilla
• Корневая программа Oracle Java
• Adobe AATL Adobe Approved Trust List и корневые программы EUTL (используются для подписи документов)

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

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

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

отзыв

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

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

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

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

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

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

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

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

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

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

Основная статья: Сертификат, проверенный доменом

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

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

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

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

Основная статья: Сертификат расширенной проверки

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

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

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

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

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

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

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

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

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

Стандарты

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

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

См. также

• Сертификат авторизации
• Довольно хорошая конфиденциальность

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

• Чунг, Тэджун; Лок, Джей; Чандрасекаран, Балакришнан; Чоффнес, Дэвид; Левин, Дэйв; Мэггс, Брюс М.; Мислов, Алан; Рула, Джон; Салливан, Ник; Уилсон, Христо (2018). «Готов ли Интернет к обязательному скреплению OCSP?» (PDF) . Материалы конференции Internet Measurement Conference 2018 . стр. 105–118. дои : 10.1145/3278532.3278543 . ISBN  9781450356190 . S2CID   53223350 .
• Лариш, Джеймс; Чоффнес, Дэвид; Левин, Дэйв; Мэггс, Брюс М.; Мислов, Алан; Уилсон, Христо (2017). «CRLite: масштабируемая система для отправки всех отзывов TLS во все браузеры». Симпозиум IEEE по безопасности и конфиденциальности (SP) 2017 г. стр. 539–556. дои : 10.1109/sp.2017.17 . ISBN  978-1-5090-5533-3 . S2CID   3926509 .
• Шеффер, Ярон; Сен-Андре, Пьер; Фоссати, Томас (ноябрь 2022 г.). Рекомендации по безопасному использованию Transport Layer Security (TLS) и Datagram Transport Layer Security (DTLS) . дои : 10.17487/RFC9325 . РФК 9325 .
• Смит, Тревор; Дикинсон, Люк; Симонс, Кент (2020). «Давайте отзовем: масштабируемый глобальный отзыв сертификатов». Труды 2020 Симпозиума по безопасности сетей и распределенных систем . дои : 10.14722/ndss.2020.24084 . ISBN  978-1-891562-61-7 . S2CID   211268930 .