Posted:
Фев 11, 2023
Comments:
0 Comments

Проверка цепочки сертификатов: Проверка цепочки сертификатов — Win32 apps

Содержание

Проверка цепочки сертификатов — Win32 apps





Twitter




LinkedIn




Facebook




Адрес электронной почты










  • Статья


  • Чтение занимает 4 мин


В этом разделе описывается, как проверить цепочку сертификатов драйвера при использовании протокола COPP.

Цепочка сертификатов графического драйвера представляет собой XML-документ. Цепочка сертификатов содержит три сертификата. Первый сертификат называется конечным сертификатом и является сертификатом COPP драйвера. Следующий сертификат — это сертификат подписи независимого поставщика оборудования (IHV). Последний сертификат — сертификат подписи Майкрософт. Чтобы графический драйвер был допустимым устройством COPP, приложение должно проверить все три этих сертификата. Вредоносная программа может предотвратить работу COPP, если приложение неправильно проверяет сертификаты в цепочке.

Цепочки сертификатов COPP используют кодировку UTF-8. Двоичные данные в сертификатах, таких как открытый ключ RSA, кодируются в кодировке Base64 и хранятся в порядке больших байтов. (Большой байт означает, что самый значительный байт хранится в расположении памяти с наименьшим адресом.)

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

Определения элементов XML

Ниже приведены определения элементов в схеме сертификата.

  • CertificateCollection. Корневой элемент XML-документа. Он содержит элементы Certificate, по одному для каждого сертификата в цепочке.
  • Сертификат. Содержит один сертификат. Этот элемент содержит элементы Data и Signature.
  • Данные. Содержит сведения о сертификате. В частности, он содержит открытый ключ и тип сертификата. Элемент Data содержит следующие дочерние элементы:
    • PublicKey. Содержит открытый ключ RSA сертификата. Элемент PublicKey содержит элемент KeyValue, который содержит элемент RSAKeyValue. Элемент RSAKeyValue содержит два дочерних элемента, Modulus и Exponent, и они определяют открытый ключ. Элементы Modulus и Exponent закодированы в кодировке Base64 и хранятся в порядке больших байтов.
    • KeyUsage. Если сертификат является сертификатом COPP драйвера, этот элемент должен содержать дочерний элемент с именем EncryptKey. Если сертификат является сертификатом подписи IHV или сертификатом подписи Майкрософт, он должен содержать дочерний элемент с именем SignCertificate. Оба этих дочерних элемента содержат логические значения.
    • SecurityLevel. Этот элемент следует игнорировать.
    • ManufacturerData. Указывает производителя и модель графического устройства. Этот элемент является информационным только.
    • Features. Содержит дочерние элементы, определяющие использование сертификата. Единственным, что относится к COPP, является элемент COPPCertificate. Могут присутствовать другие дочерние элементы; Если да, их следует игнорировать. Если элемент COPPCertificate существует, сертификат является сертификатом COPP. Этот элемент должен присутствовать на конечном узле допустимого сертификата COPP. Этот элемент содержит логическое значение.
  • Подпись. Содержит подпись для этого сертификата. Он содержит следующие дочерние элементы:
    • SignedInfo. Содержит сведения о сигнатуре. Важным дочерним элементом этого элемента является элемент DigestValue, содержащий значение хэша SHA-1 в кодировке Base64 над элементом Data. Значение дайджеста используется при проверке сертификата на соответствие списку отзыва сертификатов (CRL).
    • SignatureValue. Это значение вычисляется по элементу Data и вычисляется в соответствии со схемой цифровой подписи RSASSA-PSS, определенной в Public-Key Cryptography Standards (PKCS) #1 (версия 2.1). Сведения о PKCS No 1 см. на сайте https://www.rsa.com/.
    • KeyInfo. Содержит открытый ключ RSA следующего сертификата в цепочке. Этот элемент используется для проверки того, что данные в элементе Data не были изменены. Этот элемент имеет тот же формат, что и элемент PublicKey.

Проверка сертификатов

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

Проверка процедуры сбора сертификатов

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

  1. Убедитесь, что certificateCollection имеет правильный формат XML.
  2. Убедитесь, что CertificateCollection закодирован в формате UTF-8.
  3. Убедитесь, что атрибут Version в элементе CertificateCollection имеет значение 2.0 или более поздней версии.
  4. Убедитесь, что цепочка сертификатов содержит ровно три элемента certificate.
  5. Loop через каждый элемент Certificate в цепочке сертификатов и выполните процедуру проверки сертификата, описанную ниже, для каждого из них.

Проверка процедуры сертификата

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

  1. Убедитесь, что ни один из дочерних элементов в элементе Data не дублируется. Например, должен быть только один элемент PublicKey.
  2. Убедитесь, что элемент Data/PublicKey/KeyValue/RSAKeyValue/Modulus существует. Декодированные в base64 значения должны иметь длину 256 байт для всех сертификатов, кроме корневого. В корневом сертификате этот элемент должен иметь длину 128 байт.
  3. Убедитесь, что элемент Data/PublicKey/KeyValue/RSAKeyValue/Exponent существует. Декодированные в base64 значение не должно превышать 4 байта.
  4. Если этот сертификат является конечным сертификатом, проверьте следующее:
    • Элемент KeyUsage содержит элемент EncryptKey со значением 1.
    • Элемент Features содержит элемент COPPCertificate со значением 1.
  5. Если этот сертификат не является конечным сертификатом, проверьте следующее:
    • Модуль и экспоненты элемента Data/PublicKey точно соответствуют модуле и экспоненте элемента Signature/KeyInfo предыдущего сертификата.
    • Элемент KeyUsage содержит элемент SignCertificate со значением 1.
  6. Используйте хэш-алгоритм SHA-1 для хэширования каждого байта в элементе Data сертификата. Каждый байт от первого символа в теге <Data> до последнего символа в закрывающем <теге /Data> должен хэшироваться. Хэш-значение используется для проверки сертификата на соответствие списку отзыва сертификатов (CRL), как описано в списках отзыва сертификатов.
  7. Сравните хэш-значение из шага 6 с декодированием base64 элемента Signature/SignedInfo/Reference/DigestValue. Эти значения должны совпадать.
  8. Выполните процедуру проверки подписи, описанную ниже.
  9. Если этот сертификат не является окончательным сертификатом в цепочке, сохраните значение Signature/KeyInfo/KeyValue/RSAKeyValue для следующей итерации цикла.
  10. Если этот сертификат является окончательным сертификатом в цепочке, убедитесь, что значение signature/KeyInfo/KeyValue/RSAKeyValue соответствует открытому ключу Майкрософт. Открытый ключ Майкрософт имеет следующие значения в кодировке Base64:

Проверка процедуры подписи

Значение элемента SignatureValue вычисляется по элементу Data в соответствии со схемой цифровой подписи RSASSA-PSS, определенной в PKCS #1 версии 2.1 (далее называется PKCS). Чтобы проверить эту подпись, выполните следующие действия.

  1. Декодирование значений Modulus и Exponent в элементе Signature/KeyInfo/KeyValue/RSAKeyValue. Эти значения определяют открытый ключ RSA сертификата подписи.
  2. Декодирование элемента Signature/SignatureValue.
  3. Вычислить операцию RSASSA-PSS-Verify, определенную в разделе 8.1.2 PKCS.

Для операции RSASSA-PSS-Verify используйте следующие входные данные:

  • (n,e) — это открытый ключ из шага 1.
  • M — это все байты в элементе Data, включая <теги Data> и </Data> , заключающие элемент.
  • S — это декодированные значения подписи из шага 2.

Операция RSASSA-PSS-Verify использует операцию EMSA-PSS-ENCODE, определенную в разделе 9. 1.1. PKCS. Для этой операции COPP использует следующие параметры:

  • Хэш = SHA-1
  • hLen = 20
  • MGF (функция создания маски) = MGF1
  • sLen = 0

Функция создания маски MGF1 определена в приложении B.2 PKCS. Для этой функции COPP использует следующие параметры:

  • Хэш = SHA-1
  • hLen = 20

Выходные данные операции RSASSA-PSS-Verify указывают, является ли подпись допустимой или недопустимой.

Использование сертифицированного протокола защиты выходных данных (COPP)

 

 






ТП «Фабрикант» — электронная торговая площадка.

Возможная причина:
Не установлен корневой сертификат вашего Удостоверяющего Центра (УЦ).

Ваши действия:
Установить корневой сертификат Удостоверяющего центра.
Подробную инструкцию можете скачать
здесь

Возможные причины:
1) Не установлено дополнительное ПО с сайта Фабрикант;
2) Некорректно работает библиотека КриптоПРО Cadescom.

Ваши действия:
1) Установить Специализированное ПО с Портала Фабрикант;
2) Переустановить КриптоПРО Cadescom.
Подробную инструкцию можете скачать
здесь

Возможные причины:
1) Не установлено дополнительное ПО;
2) Не запущены дополнительные надстройки в браузере.

Ваши действия:
1) Установить Специализированное ПО с Портала Фабрикант;
2) Запустить всплывающие надстройки браузера.
Подробную инструкцию можете скачать
здесь

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

Ваши действия:
Обратитесь в УЦ или самостоятельно установите на своём ПК списки отозванных сертификатов.
Подробную инструкцию можете скачать
здесь

Возможные причины:
1) Рассинхронизация OCSP-сервер вашего УЦ;
2) Отсутствует ссылка на OCSP-сервер УЦ в сертификате.

Ваши действия:
Обратитесь в Удостоверяющий центр для проверки сертификата или проверьте самостоятельно.
Подробную инструкцию можете скачать
здесь

Возможные причины:
1) Вставлен ключевой носитель, не соответствующий выбранному сертификату;
2) Выбран сертификат, не соответствующий вставленному ключевому носителю.

Ваши действия:
1) Проверить, какой ключевой носитель вставлен;
2) Проверить выбранный сертификат.
Подробную инструкцию можете скачать
здесь

Возможная причина:
Истек срок действия лицензии на КриптоПРО CSP.

Ваши действия:
1) Обратитесь в Удостоверяющий центр для получения лицензии на КриптоПРО CSP;
2) Введите лицензию на КриптоПРО CSP.
Подробную инструкцию можете скачать
здесь

Возможная причина:
Некорректно отрабатывают настройки браузера Internet Explorer.

Ваши действия:
1) В браузере зайдите в меню «Сервис» и выберите пункт «Свойства
обозревателя»;
2) В открывшемся окне перейдите на вкладку «Дополнительно» и нажмите кнопку
«Сброс»;
3) Перезапустите браузер Internet Explorer.
Подробную инструкцию можете скачать
здесь

Возможная причина:
Не соответствуют версии криптопровайдера и Операционной системы.

Ваши действия:
1) Если у вас криптопровайдер VipNet CSP, то необходимо проверить версии на
соответствие на
сайте
;
2) Если у вас криптопровайдер КриптоПРО CSP, то необходимо проверить версии на
соответствие на
сайте
;
3) Если версии не соответствуют, то необходимо обратиться в свой Удостоверяющий центр для
обновления.

Возможная причина:
После установки дополнительного программного обеспечения с Портала не перезагрузили ПК.

Ваше действие:
Перезагрузите ПК.

С дополнительной информацией можно ознакомиться в инструкции «Установка ПО для ЭП».
Также можно обратиться в отдел технической поддержки по тел. +7 (495) 514-02-04.

Возможная причина:
1) Не установлено дополнительное ПО;
2) Не запущены дополнительные надстройки в браузере.

Ваше действие:
1) Установить Специализированное ПО с Портала Фабрикант;
2) Запустить всплывающие надстройки браузера.

Подробную инструкцию можете скачать
здесь

.

Не нашли ответа на вопрос?

  • Напишите
    нам

Что такое цепочка сертификатов? И как проверить цепочку сертификатов | Шанака Санданаяка

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

Несколько уровней доверия. Если две стороны доверяют друг другу, это называется прямым доверием. Кроме того, если две стороны доверяют друг другу из-за третьей стороны, тогда это вызывает доверие третьей стороны. Я в PKI, что доверие исходит от третьей стороны, и эта третья сторона вызывает центр сертификации или широко известный как CA.

Кто такие ЦС (центр сертификации)?

ЦС — это глобальные организации, которые предоставляют цифровые сертификаты своим клиентам, могут быть внешние ЦС (например, GlobalSign, VeriSign) или внутренние ЦС, специфичные для его организации.

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

Это можно объяснить на простом примере. Предположим, что кому-то нужно купить товар в интернет-магазине. для совершения платежа этот пользователь использует шлюз онлайн-платежей, такой как PayPal. В этом случае как сайт онлайн-покупок, так и пользователь полагаются на то, что PayPal справится с оплатой этого товара.

Изображение предоставлено: https://medium.com/@keenanrahman96/paypal-integration-with-java-spring-55d0c681c948

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

В техническом плане есть две основные модели есть 2 выдачи сертификатов.

  1. Модель иерархического доверия
  2. Модель распределенного доверия

Модель иерархического доверия

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

Модель распределенного доверия

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

Техническое объяснение

При переходе на facebook.com вы увидите зеленый значок замка в адресной строке.

Это означает, что вы установили безопасное соединение между своим компьютером и facebook.com через Интернет. И как это доверие работает. Если вы продолжите изучение и увидите сертификат, он будет выглядеть так, как показано ниже.

И вы можете видеть, что сертификат выдан facebook.com, И он был выпущен DigiCert Inc (с общим названием DigiCert SHA2 High Assurance Server CA).

И если мы проверим цепочку сертификатов, Следующий промежуточный сертификат (DigiCert SHA2 High Assurance Server CA), был выдан DigiCert High Assurance EV Root CA в соответствии с общим именем.

И когда мы проверяем корневой сертификат, вы можете видеть, что и субъект, и эмитент являются Root CA DigiCert High Assurance EV. Поскольку эти сертификаты ЦС верхнего уровня являются самозаверяющими сертификатами. Обычно эти корневые сертификаты высокого уровня, а также промежуточные доверенные сертификаты по умолчанию доступны в браузере и хранилищах доверия ОС.

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

В этом случае мой браузер доверяет facebook. com следующим образом.

  • Корневой сертификат проверяется на соответствие списку доверенных сертификатов, доступных в хранилище доверенных сертификатов ОС.
  • Промежуточный сертификат подтвержден, поскольку он подписан DigiCert High Assurance EV Root CA и проверен.
  • Наконец, сертификат сайта был проверен, поскольку он был подписан ЦС DigiCert SHA2 High Assurance Server, который является проверенным промежуточным ЦС на предыдущем шаге.

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

OpenSSL — утилита SSL с открытым исходным кодом, доступная для всех распространенных платформ. И у него есть такие возможности, как генерация закрытых ключей, создание CSR, установка вашего сертификата SSL/TLS и идентификация информации о сертификате и т. д.

Некоторые распространенные команды OpenSSL

  • Показать полную информацию о сертификате.
 openssl x509 -text -noout -in
  • Получить тему сертификата
 openssl x509 -noout -subject -in
  • Получить издателя сертификата
       openssl x509 -noout -issuer -in <Файл сертификата>
      • Преобразование сертификатов в разные форматы
       openssl x509-inform <входной_формат> -outform <выходной_формат> -in <файл сертификата> -out <выходной файл>
      • Проверка сертификата
       openssl verify <> -CAfile  -untrusted <промежуточный сертификат> <файл сертификата>

      Обратите внимание, что вы можете предоставить несколько промежуточных сертификатов с параметром -untrusted

      Предположим, у нас есть 3 сертификата, как показано ниже (в этом примере я использовал цепочку сертификатов facebook).

      • server.pem — файл сертификата сервера.
      • im.pem — файл промежуточного сертификата.
      • root.pem — это файл сертификата ЦС.

      В соответствии с этим, если мы получаем server.pem файлов эмитента, это должен быть im.pem файлов предмет. В таком случае.

       user@Users-MBP cert %  openssl x509 -noout -issuer -in server.pem  issuer= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CAuser @Users-MBP сертификат %  openssl x509 -noout -subject -in im.pem  subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA

      Судя по этому выводу, похоже например, эмитент и тема соответствуют соответствующим образом. Мы можем использовать команду openssl verify, чтобы проверить это.

       user@Users-MBP cert %  openssl verify -untrusted im.pem server.pem  server.pem: OK# Если неправильный сертификат, используйте user@Users-MBP cert %  openssl verify -untrusted root.pem server.pem  server.pem: C = США, ST = Калифорния, L = Менло-Парк, O = «Facebook, Inc. », CN = *.facebook.com  ошибка 20 при глубине поиска 0: невозможно получить сертификат локального эмитента

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

       user@Users-MBP cert %  openssl verify -untrusted root.pem im.pem  im.pem: OK

      Кроме того, вы можете сертифицировать всю цепочку сертификатов как парную.

       user@Users-MBP cert %  openssl verify -CAfile root.pem -untrusted im.pem server.pem  server.pem: OK

      При успешной проверке цепочки сертификатов эмитенты и субъекты совпадают в соответствии с приведенной выше диаграммой.

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

      • Если сертификаты не в формате PEM, преобразуйте их в файлы PEM.
       openssl x509 -inform der -outform pem -in root.cer -out root.pem
      • Объедините файлы в следующем порядке.

      Сертификат сервера → Промежуточные сертификаты → Корневой сертификат

       user@Users-MBP cert % cat server.pem im.pem root.pem > bundle.pem

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

       user@Users-MBP сертификат %  openssl crl2pkcs7 -nocrl -certfile bundle.pem | openssl pkcs7 -print_certs -noout  subject=/C=US/ST=California/L=Menlo Park/O=Facebook, Inc./CN=*.facebook.comissuer=/C=US/O=DigiCert Inc/OU= www.digicert.com/CN=DigiCert SHA2 High Assurance Server CAsubject=/C=US/O=DigiCert Inc/OU=www. digicert.com/CN=DigiCert SHA2 High Assurance Server CAissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CAsubject=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CAissuer=/C=US /O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA

      Надеюсь, это поможет вам понять цепочки сертификатов, а также некоторые полезные команды для работы с цепочками сертификатов.

      Happy Coding

      Проверка цепочки сертификатов | Апигей Эдж


      Вы просматриваете документацию по Apigee Edge.
      Посмотреть документацию по Apigee X.

      Примечание: Этот документ применим для пользователей Edge Public и Private Cloud.

      В этом документе объясняется, как проверить цепочку сертификатов перед загрузкой сертификата в
      хранилище ключей или хранилище доверенных сертификатов в Apigee Edge. Процесс опирается на
      Инструментарий OpenSSL для проверки сертификата
      chain и применим в любой среде, где доступен OpenSSL.

      Прежде чем начать

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

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

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

      Проверка субъекта сертификата и издателя для всей цепочки

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

      • Разделение цепочки сертификатов
      • Проверка субъекта и издателя сертификата
      • Проверка субъекта сертификата и хэша эмитента
      • Проверка срока действия сертификата

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

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

      1. Войдите на сервер, где существует клиент OpenSSL.
      2. Разделите цепочку сертификатов на следующие сертификаты (если это еще не сделано):
      • Сертификат объекта: entity.pem
      • Промежуточный сертификат: Intermediate.pem
      • Корневой сертификат: root.pem

      Примечание: В некоторых цепочках сертификатов может быть несколько промежуточных сертификатов.
      между сущностью и корневым сертификатом. В таких случаях назовите промежуточные сертификаты
      как: Intermediate1.pem , Intermediate2.pem и т. д.

      На следующем рисунке показан пример цепочки сертификатов:

      Проверка субъекта сертификата и издателя

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

      1. Выполните следующую команду OpenSSL , чтобы получить Subject и
        Эмитент для каждого сертификата в цепочке от объекта
        на root и убедитесь, что они образуют правильную цепочку сертификатов:

         openssl x509 -text -in  сертификат  | grep -E '(Тема | Издатель):'

        Где сертификат это имя сертификата.

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

        • Субъект каждого сертификата соответствует издателю сертификата
          предшествующий сертификат в цепочке (за исключением сертификата Entity ).
        • Субъект и Издатель одинаковы для корневого сертификата.

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

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

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

        Сертификат организации 

        openssl x509 -text -in entity.pem | grep -E '(Тема | Издатель):'
Эмитент: C = США, O = Google Trust Services, CN = GTS CA 1O1
Тема: C = США, ST = Калифорния, L = Маунтин-Вью, O = Google LLC, CN = *.enterprise.apigee.com

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

        openssl x509 -текст -в промежуточном. pem | grep -E '(Тема | Издатель):'
Эмитент: OU = GlobalSign Root CA — R2, O = GlobalSign, CN = GlobalSign
Тема: C = США, O = Google Trust Services, CN = GTS CA 1O1

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

        openssl x509 -text -in root.pem | grep -E '(Тема | Издатель):'
Эмитент: OU = GlobalSign Root CA — R2, O = GlobalSign, CN = GlobalSign
Тема: OU = GlobalSign Root CA — R2, O = GlobalSign, CN = GlobalSign

        В приведенном выше примере обратите внимание на следующее:

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

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

      Проверка субъекта сертификата и хэша издателя

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

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

      1. Запустите следующую команду OpenSSL , чтобы получить последовательность хэшей для каждого
        сертификат в цепочке от объекта до корня и убедитесь, что они
        сформировать правильную цепочку сертификатов.
        2. openssl x509 -hash -issuer_hash -noout -in  сертификат

        Где сертификат это имя сертификата.

      2. Убедитесь, что сертификаты в цепочке соответствуют следующим рекомендациям:
      • Субъект каждого сертификата соответствует Издатель предыдущего
        сертификат в цепочке (кроме сертификата Entity ).
      • Субъект и Издатель одинаковы для корневого сертификата.

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

      Пример проверки цепочки сертификатов с помощью хэш-последовательности

      В следующем примере представлены выходные данные команд OpenSSL для примера цепочки сертификатов.
      содержащий три сертификата:

      openssl x509 -in entity.pem -hash -issuer_hash -noout
c54c66ba #это тема хеш
99bdd351 #это хэш эмитента
     
      openssl x509 -inintermediate.pem-hash-issuer_hash-noout
99бдд351
4а6481с9
     
      OpenSSL x509-in root.pem -hash -issuer_hash -noout
4а6481с9
4а6481с9

      В приведенном выше примере обратите внимание на следующее:

      • Хэш субъекта промежуточного сертификата соответствует хэшу издателя объекта.
        сертификат.
      • Хэш субъекта корневого сертификата соответствует хэшу издателя сертификата издателя.
      • субъект и хеш эмитента совпадают в корневом сертификате.

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

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

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

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

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

      Образец проверки срока действия сертификата по датам начала и окончания 

      OpenSSL x509-startdate -enddate -noout -in entity. pem
notBefore=6 февраля 21:57:21 2020 по Гринвичу
notAfter=4 февраля 21:57:21 2021 по Гринвичу
 
      openssl x509 -startdate -enddate -noout -в промежуточном.pem
notBefore=15 июня 00:00:42 2017 по Гринвичу
notAfter=15 декабря 00:00:42 2021 по Гринвичу
 
      openssl x509 -startdate -enddate -noout -в root.pem
notBefore=13 апреля 10:00:00 2011 GMT
notAfter=13 апреля 10:00:00 2022 GMT
      Срок действия

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

      openssl x509 -checkend  -noout -in  сертификат

      Где сертификат это имя сертификата.

      This entry was posted in Популярное