Другая ситуация, когда я получаю X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY - PullRequest
0 голосов
/ 27 октября 2018

В продолжение этого оригинального вопроса:

Невозможно получить сертификат локально

Я решил исходную проблему, ответив jww.

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

Теперь, хотя это все еще хорошо работает с "google", когда я подключаюсь к веб-сайту нашей компании, я все равно получаю код ошибки 20 при вызове SSL_get_verify_result ().

Является ли это результатом использования нами сертификата «подстановочный знак»? т.е.: * .domain.com.

Версия OpenSSL, которую я сейчас использую, - 1.0.1 г.

Я не вижу других отличий с моей точки зрения.

Спасибо за любой совет.

----- Обновлено ------

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

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

Our Company Cert -----BEGIN CERTIFICATE----- .... -----END CERTIFICATE----- and it is signed by these guys - ComodoRSA -----BEGIN CERTIFICATE----- .... -----END CERTIFICATE----- and that is signed at the root here - ComodoRoot -----BEGIN CERTIFICATE----- .... -----END CERTIFICATE----- and this is the GOOGLE G3 who signed the "www.google.com" -----BEGIN CERTIFICATE----- .... -----END CERTIFICATE----- and the GOOGLE G3 is signed by this one - globalSign -----BEGIN CERTIFICATE----- .... -----END CERTIFICATE-----

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

strcpy(host,"our.domain.com");
//  strcpy(host,"www.google.com");
/* Build our SSL context*/
ctx = initialize_ctx(KEYFILE,NULL);

/* Connect the TCP socket*/
sock = tcp_connect(host,port);

А потом позже ...

result = SSL_get_verify_result(ssl);
switch(result) {
case X509_V_ERR_CERT_HAS_EXPIRED : break;
case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN : break;
case X509_V_OK : break;
case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT : break;
default :puts("Certificate doesn't verify");
}

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

Соединения с сервером HTTPS с коммерческими клиентами (Chrome, IE, FF ...) не имеют ошибок.

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

Для Google:

depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com
verify return:1
read:errno=0
----   other stuff ----
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---

А для нашего домена я получаю следующее (данные компании скрыты):

depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
read:errno=10054
----   other stuff ---
Certificate chain
 0 s:/C=US/postalCode=00000/ST=IL/L=city/street=main/O=company./OU=PremiumSSL Wildcard/CN=*.domain.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
    i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
    i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
----

Теперь цепочка заключается в том, что наш сертификат подписан "ComodoRSA", и что он подписан "ComodoRoot".

Однако, как я изначально указывал, наш сертификат является «подстановочным» сертификатом, а сертификат Google - нет.

Итак, это был мой вопрос: есть ли проблема с использованием подстановочных сертификатов с версией openSSL 1.0.1g?

--- EDIT2 ----

Я добавляю больше контента к сообщению, чтобы добавить изображение из браузера.

Наш сертификат размещен на действующем веб-сайте и не является самозаверяющим.

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

Я нашел сайт, который использует ту же цепочку, что и мы: DrudgeReport.com

Я просто извлек сертификаты с помощью браузера и сохранил их в файл. Это было идентично шагам, которые я использовал на сайте google.com. (Просмотреть сертификат и скопировать в файл)

DrudgeReport chain

Результатом Drudge является ошибка 19, которая является «самоподписанной», а не ошибка 20, которая была моей ошибкой. Корневой уровень (comodo secure) одинаков при копировании в файл с любого сайта (как и следовало ожидать).

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

Учебный материал по openssl, и его довольно сложно найти. Просто много документов, которые для новичка, такого как я, довольно округлые в своих определениях.

Спасибо за ваш отзыв.

1 Ответ

0 голосов
/ 29 октября 2018

Итак, это был мой вопрос: есть ли проблема с использованием подстановочных сертификатов с версией openSSL 1.0.1g?

Это не проблема подстановочных сертификатов.Фактически, ваш код даже не проверяет тему сертификата (т. Е. Ваш код небезопасен), он в основном проверяет цепочку сертификатов, срок действия и назначение сертификата.И сообщение об ошибке от openssl s_client ясно указывает на проблему:

проверьте ошибку: num = 20: невозможно получить сертификат локального эмитента

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

 [1] CN=*.domain.com, issued by [2]
 [2] CN=COMODO RSA Organization Validation Secure Server CA, issued by [3]
 [3] CN=COMODO RSA Certification Authority, issued by [ROOT]

Ожидаемый [ROOT] - «CN = AddTrust External CA Root» - только этот CA отсутствует в списке доверенных корней.CA.

Хотя вы не даете подробных названий сертификатов, которые есть в вашем местном хранилище доверия, я предполагаю, что CA, который вы называете «ComodoRoot», похож на то, что у меня есть как «[3] CN = COMODO RSA CertificationАвторитет »в списке.Только в вашем хранилище доверенных сертификатов это, скорее всего, самозаверяющая версия сертификата, в то время как в цепочке сертификатов, предоставляемой сервером, это сертификат, выданный «[ROOT] CN = AddTrust External CA Root».Оба сертификата имеют один и тот же открытый и закрытый ключи, что означает, что подписи в цепочке сертификатов могут быть успешно проверены с обоими.

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

Это означает, что он будет успешным, если у вас в хранилище доверенных сертификатов будет либо «CN = AddTrust External CA Root», либо если сервер отправит короткую цепочку, которая заканчивается «[2] CN = COMODO RSA Проверка организации Безопасный серверCA "с тех пор он найдет поставщика для этого (ваш" ComodoRoot ", то есть" CN = COMODO RSA Certification Authority ") в вашем хранилище доверенных сертификатов.

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

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