openssl: невозможно получить сертификат местного эмитента для accounts.google.com

asonge правильно, что проблема связана с тем, что третий сертификат в цепочке сертификатов, GeoTrust Global CA ) был выпущен Equifax Центр сертификации безопасности , который не указан в качестве доверенного сертификата CA в файле, загруженном с веб-сайта Curl. Я подумал, что дополню его / ее ответ - и успокою bcardarella - объяснением, почему это так.

Список доверенных сертификатов CA с веб-сайта Curl фактически генерируется из используемых корневых сертификатов пользователя Mozilla. Причина, по которой сертификат Equifax не указан в нем, заключается в том, что: Equifax и другие сертификаты CA были удалены из списка доверенных сертификатов CA Mozilla в октябре 2016 года . См. Следующий отчет об ошибке, которая привела к этому изменению: Удалите неаудитированные корневые сертификаты Symantec из NSS .

Сертификат с перекрестной подписью

Сертификат GeoTrust на самом деле является сертификатом с перекрестной подписью . Это означает, что существует две версии сертификата GeoTrust, сгенерированного из одного и того же закрытого ключа (используемого для подписи сертификата Google Internet Authority G2 ).

• самоподписанный (сейчас перечислен в большинстве корневых хранилищ ЦС) )
• один, подписанный Equifax

Второй сертификат был полезен еще в те дни, когда GeoTrust CA был впервые запущен. В то время клиенты доверяли ему, так как доверяли сертификату Equifax, который использовался для его подписи. Такой сертификат известен как мостовой сертификат .

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

1. Использование самозаверяющего сертификата

Это стандартное поведение последних версий OpenSSL.

$ echo | openssl s_client -connect accounts.google.com:443 -CAfile cacert.pem >/dev/null
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = accounts.google.com
verify return:1
DONE

2. Использование «мостового» сертификата

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

$ echo | openssl s_client -connect accounts.google.com:443 -CAfile Equifax_Secure_CA.pem  -no_alt_chains >/dev/null
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = accounts.google.com
verify return:1
DONE

Поведение OpenSSL

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

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

Эта конкретная проблема

В этом случае запуск s_client с параметром -showcerts показывает, что веб-сервер Google по-прежнему отправляет устаревший сертификат моста, подписанный закрытым ключом Equifax. Я подозреваю, что вы используете старую версию OpenSSL (до 1.0.2b) и что она использует их все при построении своей цепочки промежуточных сертификатов.

Решения

Вот несколько возможных решений для обеспечения s_client показывает, что все сертификаты в цепочке доверия проверяются правильно:

1. Обновление до более новой версии (1.02b и выше), которая проверяет, может ли быть построена альтернативная (более короткая) цепочка, которая проверяет - если первая (длинная) цепочка не может быть проверена.

2. Некоторые старые версии s_client принимают параметр -trusted_first , который приводит к проверке OpenSSL, может ли он построить более короткая цепочка с использованием сертификатов из списка доверенных корневых сертификатов ЦС ( до попытка построения длинной цепочки).

3. Импортируйте Equifax Secure Certificate Authority в свое хранилище сертификатов - или сохраните как файл и обращайтесь к нему с помощью параметров -CAfile или -CApath для s_client .

На самом деле это не ошибка. Это внизу доверенного сертификата (сертификат с темой s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA), но у этого доверенного сертификата есть эмитент i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority, который не входит в список доверенных. На самом деле это совершенно нормально. Если вы посмотрите на итоговый статус проверки внизу, вы будете проверены должным образом.

Некоторое время корневой ЦС может быть самоподписанным (issuer == subject), но это не так. До тех пор, пока один сертификат в цепочке находится в доверительном управлении, он надлежащим образом аутентифицирован