Подтверждение SSL не выполнено - верифицированный сертификат цепи - содержит два подписанных сертификата CA и один самозаверяющий сертификат

Я застрял в проблеме и пытался ее отладить. Мы приобрели сертификат Verisign. Когда мы используем:

openssl> s_client -connect myweb.com:443 -showcerts

SSL Handshake никогда не завершается, и в конце мы видим ошибку:

Verify return code: 19 (self signed certificate in certificate chain)

Он показывает 3 тега ---BEGIN/END CERTIFICATE---. Два сертификата в цепочке - Verisign, но один сам подписан.

  • Если кто-то может объяснить, как этот самозаверяющий сертификат появляется в сертификате, подписанном ЦС?

  • Является ли эта ошибка 19 (self signed certificate in certificate chain) доброкачественной? Если нет, что может быть причиной?

  • Клиент имеет сертификат CA в надежном хранилище, но для самоподписанного сертификата нет ничего. Считаете ли вы, что это может вызвать проблемы? Если да, как я:

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

ОТВЕТЫ

Ответ 1

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

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

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

openssl s_client -connect myweb.com:443 -showcerts не имеет каких-либо особых оснований доверять сертификату корневого ЦС Verisign, и поскольку он самозаверяется, вы получите "самоподписанный сертификат в цепочке сертификатов".

Если в вашей системе есть место с пакетом сертификатов, которому доверяют по умолчанию (я думаю, /etc/pki/tls/certs в RedHat/Fedora и /etc/ssl/certs на Ubuntu/Debian), вы можете настроить OpenSSL, чтобы использовать их как доверительные привязки, например например:

openssl s_client -connect myweb.com:443 -showcerts -CApath /etc/ssl/certs

Ответ 2

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

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

Вот некоторая информация о промежуточных цепочках:
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR657
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AD146

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

Ответ 4

О сервере может доставить клиентам корневой сертификат или нет, извлеченный из документа RFC-5246 "Протокол безопасности транспортного уровня (TLS) версии 1.2":

certificate_list
      Это последовательность (цепочка) сертификатов. Отправитель отправителя       сертификат ДОЛЖЕН войти первым в список. Каждый следующий       сертификат ДОЛЖЕН прямо засвидетельствовать предшествующий ему сертификат. Потому как       проверка сертификата требует, чтобы корневые ключи были распределены       независимо, самоподписанный сертификат, определяющий корень       сертификат МАЙ не указывается в цепочке, под       предположение, что отдаленный конец должен уже обладать им, чтобы       подтвердите его в любом случае.

О термине "МАЙ", извлеченном из RFC-2119 "Лучшая современная практика", говорится:

5.MAY
 Это слово или прилагательное "ДОПОЛНИТЕЛЬНОЕ" означают, что элемент действительно является необязательным. Один поставщик может выбрать включение элемента, потому что конкретный рынок требует этого или потому, что продавец чувствует, что он улучшает продукт, в то время как другой поставщик может опустить тот же элемент.
Реализация, которая не включает конкретный вариант, ДОЛЖНА быть подготовлен к взаимодействию с другой реализацией, которая включите опцию, хотя, возможно, с ограниченной функциональностью. в тот же самый вариант реализации, который включает конкретный вариант
ДОЛЖЕН быть подготовлен к взаимодействию с другой реализацией, которая не включает опцию (кроме, конечно, для функции опция).

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

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

Ответ 5

Когда вы видите "Verify return code: 19 (self signed certificate in certificate chain)", то либо серверы действительно пытаются использовать самозаверяющий сертификат (который клиент никогда не сможет проверить), либо OpenSSL не имеет доступа к но сервер пытается обеспечить его сам (чего он не должен делать, потому что это бессмысленно - клиент никогда не может доверять серверу для подачи корня, соответствующего собственному сертификату сервера).

Опять же, добавление -showcerts поможет вам диагностировать, какие.