Введение

Электронный документ, используемый для подтверждения права собственности на открытый ключ.

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

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

Протокол Transport Layer Security (TLS), а также его устаревший предшественник, протокол Secure Sockets Layer (SSL), обеспечивают безопасную связь между клиентским компьютером и сервером. Протокол требует от сервера предоставить цифровой сертификат, подтверждающий, что это целевой сервер. Подключающийся клиент выполняет проверку цепочки сертификатов, удостоверяясь в следующем:
Субъект сертификата соответствует имени хоста (не следует путать с доменным именем), к которому клиент пытается подключиться. Сертификат подписан доверенным центром сертификации. Поле "Субъект" сертификата должно указывать основное имя хоста сервера как общее имя. Сертификат может быть действителен для нескольких имен хостов (например, домена и его поддоменов). Такие сертификаты обычно называют сертификатами с альтернативными именами субъекта (SAN) или сертификатами унифицированных коммуникаций (UCC). Эти сертификаты содержат поле "Альтернативное имя субъекта", хотя многие центры сертификации также помещают их в поле "Общее имя субъекта" для обеспечения обратной совместимости. Если некоторые из имен хостов содержат звездочку (*), сертификат также может называться сертификатом подстановки (wildcard certificate). После успешной проверки цепочки сертификатов клиент может установить зашифрованное соединение с сервером. Серверы, доступные из Интернета, такие как публичные веб-серверы, должны получать свои сертификаты от надежного, общедоступного центра сертификации (CA).

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

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

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

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

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

Самоподписанный сертификат — это сертификат, у которого субъект (subject) совпадает с эмитентом (issuer), а подпись может быть проверена с помощью его собственного открытого ключа. Самоподписанные сертификаты имеют ограниченное применение. Они обладают полной степенью доверия, когда эмитент и единственный пользователь являются одним и тем же субъектом. Например, система шифрования файлов (Encrypting File System) в Microsoft Windows выдает самоподписанный сертификат от имени шифрующего пользователя и использует его для прозрачного расшифрования данных в режиме реального времени. Цифровая цепочка доверия сертификатов начинается с самоподписанного сертификата, называемого корневым сертификатом, доверительным якорем или корнем доверия. Центр сертификации самоподписывает корневой сертификат, чтобы иметь возможность подписывать другие сертификаты. Промежуточный сертификат имеет аналогичное назначение с корневым сертификатом — его единственная функция заключается в подписании других сертификатов. Однако промежуточный сертификат не является самоподписанным. Он должен быть подписан корневым сертификатом или другим промежуточным сертификатом. Конечный сертификат или сертификат-лист — это любой сертификат, который не может подписывать другие сертификаты. Например, серверные и клиентские сертификаты TLS/SSL, сертификаты электронной почты, сертификаты подписи кода и квалифицированные сертификаты — все это конечные сертификаты.

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

Сертификат EMV: EMV – это способ оплаты, основанный на техническом стандарте для платежных карт, платежных терминалов и банкоматов (ATM). Платежные карты EMV предварительно загружаются сертификатом эмитента, подписанным удостоверяющим центром EMV для подтверждения подлинности платежной карты в ходе платежной операции. Сертификат подписи кода: Сертификаты могут подтверждать подлинность приложений (или их исполняемых файлов), гарантируя, что они не были изменены при доставке. Квалифицированный сертификат: Сертификат, идентифицирующий физическое лицо, как правило, для целей электронной подписи. Они наиболее распространены в Европе, где регламент eIDAS стандартизирует их и требует их признания. Сертификат, основанный на ролях: Определенный в политике сертификатов X.509 для Федерального мостового удостоверяющего центра (FBCA), сертификаты, основанные на ролях, "идентифицируют конкретную роль, от имени которой подписчик уполномочен действовать, а не имя самого подписчика, и выпускаются для поддержки общепринятых деловых практик". Групповой сертификат: Определенный в политике сертификатов X.509 для Федерального мостового удостоверяющего центра (FBCA), для "случаев, когда несколько субъектов действуют в одном качестве, и когда не требуется неотрекаемость транзакций".

Общие поля

Это некоторые из наиболее распространенных полей в сертификатах. Большинство сертификатов содержат ряд полей, не перечисленных здесь. Важно отметить, что с точки зрения 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 за подписание сертификатов отвечает центр сертификации (ЦС). Эти сертификаты служат своего рода представлением между двумя сторонами, что означает, что ЦС выступает в роли доверенной третьей стороны. ЦС обрабатывает запросы от лиц или организаций, запрашивающих сертификаты (называемых подписчиками), проверяет предоставленную информацию и, при необходимости, подписывает сертификат конечной сущности на основе этих данных. Для эффективного выполнения своей роли ЦС должен обладать одним или несколькими широко доверенными корневыми или промежуточными сертификатами, а также соответствующими закрытыми ключами. ЦС могут добиться широкого доверия, включив свои корневые сертификаты в популярное программное обеспечение или получив перекрестную подпись от другого ЦС, делегирующего доверие. Некоторые ЦС пользуются доверием в относительно небольшом сообществе, например, в рамках организации, и распространяются посредством других механизмов, таких как групповая политика Windows. Центры сертификации также несут ответственность за поддержание актуальной информации об отзыве выданных ими сертификатов, указывающей на их текущую действительность. Эту информацию они предоставляют посредством протокола онлайн-проверки статуса сертификатов (OCSP) и/или списков отзыва сертификатов (CRL). К числу крупных центров сертификации на рынке относятся IdenTrust, DigiCert и Sectigo.

Отмена

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

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

Наиболее распространенное применение сертификатов – веб-сайты, использующие HTTPS. Веб-браузер проверяет подлинность веб-сервера HTTPS, чтобы пользователь мог быть уверен, что его взаимодействие с веб-сайтом не перехватывается и что веб-сайт действительно является тем, за кого себя выдает. Эта безопасность особенно важна для электронной коммерции. На практике оператор веб-сайта получает сертификат, обращаясь в центр сертификации с запросом на подпись сертификата. Запрос на сертификат – это электронный документ, содержащий имя веб-сайта, информацию о компании и открытый ключ. Центр сертификации подписывает запрос, создавая тем самым публичный сертификат. При просмотре веб-страниц этот публичный сертификат передается любому веб-браузеру, подключающемуся к веб-сайту, и подтверждает браузеру, что центр сертификации считает, будто он выдал сертификат владельцу веб-сайта. Например, при подключении пользователя к https://www.example.com/ через браузер, если браузер не выдает никаких предупреждений о сертификате, пользователь может теоретически быть уверен, что взаимодействие с https://www.example.com/ эквивалентно взаимодействию с лицом, связавшимся по адресу электронной почты, указанному в публичном реестре домена "example.com", даже если этот адрес электронной почты нигде не отображается на веб-сайте. Никаких иных гарантий не предоставляется. Более того, связь между покупателем сертификата, оператором веб-сайта и создателем контента веб-сайта может быть непрочной и не гарантируется. В лучшем случае сертификат гарантирует уникальность веб-сайта, при условии, что сам веб-сайт не был скомпрометирован (взломан) или процесс выдачи сертификата не был подорван. Центр сертификации может выбрать один из трех типов сертификатов, каждый из которых требует различной степени проверки. В порядке возрастания строгости (и, соответственно, стоимости) это: валидация домена, валидация организации и расширенная валидация. Эти требования к проверке в общих чертах согласованы добровольными участниками Форума CA/Browser.

Валидация домена

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

Валидация организации

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

Расширенная валидация

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

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

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

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

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