Что такое чейн SSL сертификата – Stack Overflow на русском

Что такое чейн ssl сертификата

----- BEGIN CERTIFICATE -----

----- END CERTIFICATE -----

----- BEGIN CERTIFICATE -----
base64 одного сертификата
----- END CERTIFICATE -----
----- BEGIN CERTIFICATE -----
base64 другого сертификата
----- END CERTIFICATE -----
...

Введение

На самом деле эта тема тесно переплетается с фундаментальными основами PKI, как доверие сертификатов, защита от подделки цифровых подписей сертификатов, отзыв сертификатов и т.д. Иными словами, сама модель PKI лежит на Certificate Chaining Engine (механизм построения цепочек сертификатов).

Одной из основ PKI является модель доверия центрам сертификации (Certification Authority или просто CA). Прежде чем мы начнём доверять сертификату мы должны явно доверять корневому сертификату CA и так же явно или косвенно (по правилу одностороннего транзитивного доверия) доверять всем промежуточным CA в цепочке.

Корневые сертификаты устанавливаются в систему вручную путём добавляения сертификата CA в секцию Trusted Root CAs. Если корневой сертификат CA есть в этом списке, то мы доверяем всем сертификатам, которые выдал этот CA и любые подчинённые CA (Intermediate CA).

Cross-подпись

Наш промежуточный сертификат “Let’s Encrypt Authority X3” содержит открытый и закрытый ключ. Закрытый ключ из этой пары подписывает все сертификаты конечного пользователя (они же “листовые сертификаты), т.е. сертификаты, которые мы выдаём для вашего web-сервера.

Name match

Но поле AKI не обязательно должно присутствовать в сертификате. Его может не быть совсем и тогда остаётся только один способ проверки целостности цепочки — сравнение поля Issuer текущего сертификата и поля Subject вышестоящего сертификата.

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

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

Дополнительно

Закрытые ключи для корневого ISRG и промежуточных Let’s Encrypt Центров Сертификации надёжно хранятся в аппаратных модулях безопасности (hardware security modules, HSMs), что обеспечивает высокий уровень защиты от кражи ключей.

Все ключи ISRG – это RSA-ключи. Мы планируем переход на ECDSA-ключи.

Запрос на сертификат на открытый ключ

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

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

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

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

  Как именно поступать в такой ситуации, определяется регламентом
  удостоверяющего центра.

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

Корневые сертификаты

Наши корневые сертификаты хранятся в надёжном месте и недоступны онлайн. Мы выпускаем сертификаты для пользователей на основе промежуточных сертификатов из следующего раздела.

Мы создали сайты для проверки цепочек сертификатов вплоть до корневых.

Криптографические операции и цепочки доверия

Понятие «Проверка подписи» подразумевает проверку соответствия подписи
документу, который подписан этой подписью. Если подпись соответствует
документу, документ считается подлинным и корректным.

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

Для этого проводится проверка сертификата на этот ключ. Понятие
«проверка сертификата» означает проверку подписи под этим
сертификатом. Подпись под сертификатом проверяется на открытом ключе
того, кто создал и подписал сертификат — т.е. на открытом ключе
удостоверяющего центра.

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

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

Обработка цепочки кросс-сертификатов

Кросс-сертификация — это новая возможность установления отношений доверия, появившаяся в инфраструктуре PKI среды Windows 2003 (подробнее она рассмотрена в статье «Принципы доверия PKI»). В отличие от списков CTL, кросс-сертификация позволяет устанавливать детальные отношения доверия в PKI между различными инфраструктурами центров CA.

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

Построение цепочки доверия кскпэп – клеверенс – база знаний

Проверка соответствия сертификатов внутри построенной цепочки

Однако, это только половина дела. Мы просто построили цепочку сертификатов, но не более того. Поскольку сертификаты могут быть скачаны в pkcs7 формате, а по ссылкам AIA просто подменить сертификаты, chaining engine делает полнуюю проверку доверия каждого сертификата в цепочке, чтобы исключить возможность подмены сертификатов, а так же достраивает цепочку (если этого не удалось сделать с помощью AIA и pkcs7 используя локальное хранилище сертификатов). Соответствие сертификатов внутри цепочки может происходить по нескольким правилам (в порядке приоритета):

• Exact Match
• Key Match
• Name MAtch

Для этого chaining engine использует следующие поля сертификатов:

• Authority Key Identfier (AKI) — может содержать комбинацию поля Subject и Serial Number сертификата вышестоящего CA или хеш открытого ключа вышестоящего CA (но бывает, что это поле совсем отсутствует).
• Issuer – данное поле используется только если AKI отсутствует в сертификате и это поле должно быть эквивалентно полю Subject вышестоящего CA. По этому полю определяется имя CA, котороый издал этот сертификат.
• Subject в сертификате вышестоящего CA. Данное поле должно быть эквивалентно полю Issuer в издаваемых сертификатах.
• Serial Number сертификата вышестоящего CA.
• Subject Key Identifier (SKI) — может содержать комбинацию поля Subject и Serial Number текущего сертификата или хеш открытого ключа текущего сертификата.

Прозрачность сертификатов

В Let’s Encrypt мы в нацелены на прозрачность в наших процессах и в сертификатах, которые выпускаем. Мы записываем сертификаты в журнал Certificate Transparency сразу, как только выпускаем их. Все наши сертификаты доступны по ссылкам:

Промежуточные сертификаты

Компания IdenTrust подписала наши промежуточные сертификатры. Это позволяет всем основным браузерам принимать наши сертификаты с нашим же корневым сертификатом.

При обычных обстоятельствах, сертификаты Let’s Encrypt создаются на основе “Let’s Encrypt Authority X3”. Другой промежуточный сертификат, “Let’s Encrypt Authority X4”, находится в резерве на случай аварийного восстановления, и будет использован при невозможности использования “Let’s Encrypt Authority X3”.

Промежуточные сертификаты удостоверяющих центров

Промежуточные сертификаты удостоверяющих центров—это сертификаты на
ключи удостоверяющих центров, не являющиеся корневыми. Т.е. это
сертификаты удостоверяющих центров, подписанные на других сертификатах
удостоверяющих центров.

Промежуточные сертификаты могут возникнуть, к примеру:

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

Если в цепочке доверия присутствует промежуточный сертификат
удостоверяющего центра, она оказывается трехзвенной:

Корневой сертификат УЦ—промежуточный сертификат УЦ—сертификат
пользователя.

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

Процедуры сличения

В процессе проверки подлинности сертификата для него выполняются процедуры сличения по следующим критериям: цифровая подпись (digital signature), параметры отношений доверия (trust), временные параметры (time), информация об аннулировании сертификата (revocation) и параметры формата (formatting).

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

Для проверки подлинности подписи недостаточно просто наличия открытого ключа, он должен быть заслуживающим доверия. В инфраструктурах PKI систем Windows Server 2003 и Windows 2000 Server сертификат и открытый ключ заслуживающего абсолютного доверия центра CA называются трастовыми якорями (trust anchor), а доступ к ним осуществляется через контейнер Trusted Root Certification Authorities хранилища сертификатов клиента Windows PKI.

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

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

Во время выполнения процедуры сличения срока действия (revocation check) проверяется, не аннулирован ли данный сертификат выдавшим его центром CA. В средах PKI систем Windows 2003 и Windows 2000 Server реализована поддержка работы с абсолютными списками аннулированных сертификатов (complete CRL) и узлами распространения списков CRL (CRL Distribution Point, CDP).

Помимо этого, служба Windows 2003 Certificate Services может работать и со списками изменений (delta CRL). Используя списки CRL, списки изменений CRL и узлы CDP, можно обеспечить проверку срока действия сертификатов в автоматическом режиме. Более подробно вопросы, связанные с аннулированием сертификатов, рассмотрены в статье «Процедуры аннулирования сертификатов в инфраструктуре Windows PKI», опубликованной в журнале Windows IT Pro/RE № 4 за 2006 г.

Сертификат подписания ответов ocsp

Этот сертификат используется для подписания ответов OCSP для промежуточных Центров Сертификации Let’s Encrypt. Таким образом нам не нужно иметь онлайне-доступ к корневому сертификату, чтобы подписать эти ответы. Копия сертификата подписания включена в ответ OCSP для информирования, дополнительно пользователям ничего делать не нужно.

Сертификаты

Необходимо обеспечить возможность любому пользователю в любой момент:

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

Для того, чтобы обеспечить эти требования, все открытые ключи хранятся и
передаются в виде сертификатов.

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

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

Стандартная процедура обработки цепочки сертификатов

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

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

При использовании иерархической модели доверительных отношений каждый сертификат содержит указатель на родительский (или выдавший сертификат) центр CA, который хранится в поле issuer сертификата X.509. На рис. 1 показан пример цепочки для пользовательского сертификата, выданного центром CA при наличии двухуровневой иерархии в инфраструктуре PKI. Рис.

1 иллюстрирует простейший пример использования параметров certificate subject (субъект) и certificate issuer (издатель сертификата). В данном примере субъектом пользовательского сертификата является пользователь, а издателем сертификата — промежуточный центр CA.

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

Обработка цепочки выполняется программой проверки подлинности сертификатов. Данный процесс разделяется на две составляющие: построение цепочки сертификатов и проверка ее подлинности.

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

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

Проверка подлинности цепочки сертификатов.

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

Для идентификации сертификата центра CA во время процедуры проверки подлинности цепочки используется расширение Authority Key Identifier (AKI) проверяемого сертификата. В поле AKI содержится информация следующих типов.

• Имя центра, выдавшего сертификат и серийный номер сертификата данного центра. Если эта информация имеется в поле AKI, тогда программа проверки подлинности выполняет поиск совпадающего сертификата, используя поля Serial number и Subject. Данный метод идентификации сертификата называется строгим совпадением.
• Идентификатор открытого ключа (KeyID) сертификата центра, выдавшего проверяемый сертификат. Если эта информация имеется в поле AKI, тогда программа проверки подлинности выполняет поиск совпадающего сертификата, используя расширение сертификата Subject Key Identifier (SKI), в котором хранится уникальный идентификатор открытого ключа сертификата субъекта. Данный метод идентификации сертификата называется совпадением ключей.

Если в проверяемом сертификате поле AKI отсутствует, программа проверки подлинности пытается идентифицировать сертификат выдавшего центра CA с помощью проверки совпадения имени, взятого из поля Issuer проверяемого сертификата, с содержимым поля Subject сертификата. Данный метод идентификации сертификата называется совпадением имен.

Удостоверяющие центры

Создает (выпускает) сертификаты специальный административный центр,
называемый удостоверяющим центром (УЦ) или центром сертификации (ЦС).

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

Совокупность требований удостоверяющего центра называется регламентом
удостоверяющего центра.

Удостоверяющий центр имеет собственные ключи подписи и подписывает на
них все электронные документы, которые он выпускает.

Удостоверяющий центр выпускает сертификат на собственный открытый ключ.
Такой сертификат называется сертификатом удостоверяющего центра.

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

Взаимодействие пользователя с удостоверяющим центром происходит следующим образом:

1. Пользователь создает ключевую пару (открытый и закрытый ключи).
2. Пользователь отправляет в удостоверяющий центр запрос на
   сертификат, в который включает открытый ключ и всю необходимую
   информацию о себе и о ключах. Набор необходимых сведений определяется
   регламентом удостоверяющего центра, но всегда необходимо
   указывать имя владельца, назначение ключей, дату создания.
3. Удостоверяющий центр получает запрос и проверяет его подлинность и
   корректность. Как именно это делается, определяется регламентом
   удостоверяющего центра.
4. Если результат проверки запроса положительный, удостоверяющий
   центр создает сертификат на открытый ключ, подписывает его, заносит в
   свою базу данных и отправляет пользователю.
5. Пользователь получает сертификат и устанавливает его у себя в
   системе.

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

Конец срока действия сертификата

Каждый сертификат имеет ограниченный срок действия. Конкретный
максимальный срок действия сертификата устанавливается регламентом УЦ,
но обычно он не превышает одного года.

По истечении срока действия сертификат становится недействительным.

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

По истечении срока действия сертификата на открытый ключ пользователя
необходимо сформировать запрос на новый сертификат.

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