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

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

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

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

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

• самоподписанный (сейчас указан в большинстве корневых хранилищ CA)
• один подписанный 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 и эмулировал его старое поведение по умолчанию, заключающееся в отказе от альтернативных цепочек сертификатов. Поскольку сертификат корневого ЦС Equifax больше не существует в моем системном хранилище сертификатов, я явно указываю его использование в качестве корневого хранилища ЦС для этой одной команды:

$ 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 этого нет в списке доверенных. На самом деле это совершенно нормально. Если вы посмотрите на окончательный статус подтверждения внизу, вы правильно прошли проверку.

Иногда корневой ЦС может быть самоподписанным (эмитент == субъект), но это не так. Пока один сертификат в цепочке находится в доверии, он должным образом аутентифицируется.