Мета: не ответ, по крайней мере, пока, но некоторая информация и совет.
Ладно, легкий случай не подходит. Как вы уже столкнулись, завиток
не дает очень полезной информации, когда получает ошибку проверки сертификата из базового стека SSL/TLS, по крайней мере, при использовании GnuTLS, как это делает сборка Ubuntu. Однако OpenSSL (который должен присутствовать, потому что curl имеет его в качестве зависимости, хотя я не понимаю, почему) предоставляет программу командной строки, названную просто openssl
это в основном тестовый инструмент, и он намного более подробный, а также более устойчивый к ошибкам. Например, на заведомо плохом сайте в докер-версии Ubuntu 16.04:
# curl -v https://untrusted-root.badssl.com/
* Попытка 104.154.89.105...
* Подключен к untrusted-root.badssl.com (104.154.89.105), порт 443 (#0)
* найдено 129 сертификатов в /etc/ssl/certs/ca-certificates.crt
* найдено 516 сертификатов в /etc/ssl/certs
* ALPN, предлагающий http/1.1
* SSL-соединение с использованием TLS1.2/ECDHE_RSA_AES_128_GCM_SHA256
* проверка сертификата сервера не удалась. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: нет
* Закрытие соединения 0
curl: (60) проверка сертификата сервера не удалась. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: нет
Подробнее здесь: http://curl.haxx.se/docs/sslcerts.html
[вырезать готовый текст — такой же, как у вас]
# openssl s_client -connect untrusted-root.badssl.com:443 -servername untrusted-root.badssl.com
ПОДКЛЮЧЕН(00000003)
depth=1 C = США, ST = Калифорния, L = Сан-Франциско, O = BadSSL, CN = BadSSL Ненадежный корневой центр сертификации
ошибка подтверждения: num = 19: самоподписанный сертификат в цепочке сертификатов
---
Цепочка сертификатов
0 s:/C=US/ST=Калифорния/L=Сан-Франциско/O=BadSSL/CN=*.badssl.com
i:/C=US/ST=Калифорния/L=Сан-Франциско/O=BadSSL/CN=BadSSL Ненадежный корневой центр сертификации
1 s:/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL Ненадежный корневой центр сертификации
i:/C=US/ST=Калифорния/L=Сан-Франциско/O=BadSSL/CN=BadSSL Ненадежный корневой центр сертификации
---
Сертификат сервера
-----НАЧАТЬ СЕРТИФИКАТ-----
MIIEmTCCAoGgAwIBAgIJAMJ1vCpOBALkMA0GCSqGSIb3DQEBCwUAMIGBMQswCQYD
VQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5j
AXNjbzEPMA0GA1UECgwGQmFkU1NMMTQwMgYDVQQDDCtCYWRTU0wgVW50cnVzdGVk
IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTIxMTIwNDAwMDgxOVoXDTIz
MTIwNDAwMDgxOVowYjELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
FjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xDzANBgNVBAoMBkJhZFNTTDEVMBMGA1UE
AwwMKi5iYWRzc2wuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
wgTs+IzuBMKz2FDVcFjMkxjrXKhoSbAitfmVnrErLHY+bMBLYExM6rK0wA+AtrD5
csmGAvlcQV0TK39xxEu86ZQuUDemZxxhjPZBQsVG0xaHJ5906wqdEVImIXNshEx5
VeTRA+gGPUgVUq2zKNuq/27/YJVKd2s58STRMbbdTcDE/FO5bUKttXz+rvUV0jNI
5yJxx8IUemwo6jdK3+pstXK0flqiFtxpsVdE2woSq97DD0d0XEEi4Zr5G5PmrSIG
KS6xukkcDCeeo/uL90ByAKySCNmMV4RTgQXL5v5rVJhAJ4XHELtzcO9pGEEHRVV8
+WQ/PSzDqXzrkxpMhtHKhQIDAQABozIwMDAJBgNVHRMEAjAAMCMGA1UdEQQcMBqC
DCouYmFkc3NsLmNvbYIKYmFkc3NsLmNvbTANBgkqhkiG9w0BAQsFAAOCageEADVgB
Ias+fb/Ckdnw5iSYsfRIcfhnTBNgvroorUQe09Psx0tAbjlIYqOCtloNhvCbJYa7
tQQOO65s7RKArpAA1qoapWfDti2aHuMNvGwImwX538RiLf4Rm4MEF6vuF6MZMH/u
Ts1iugB3+d7oSWl/K+RvA4NMRNrlxOLelBJwaTsExsQ5QalpPamongnyWXHZ2Sna
dsw9hBku9ZmlRqYOCE/TajsydqCIhCc2QC5xdd3fxXlcfq5h7G0oOuCYvW7BscTk
AQZYkwS+y3mTHF9wSlxJB4iEGC0NovdM5GsVgfvZ5+jtXGuDlsphAIFLxpIJi1bR
+NsAkEthHoQZDNttvtVJPFPp83PdRDmL6IwrbbXvAwZWWgYmS6HpbF5bxR09JIOA
KttGK1wnd6bh2d9Xy6kfoxZ1gz6i2y5OpxbMoi6z8o1Y2hSOv2kgnD2fxtR9X4OO
wrwWZWnhwsiq7pnZbZiA9GFR4tKZVcJ5ny5aul/MZ0wb5MST7wHW/7qhydfBpOy6
hZ5BSbwfmBao+CJ7NxNJb5c03W5+/Vf1uxXZhodpag6Z5p0rru0v7ea9nMk5dNUm
qR+2XGwzDk9n8jCWwfvSKCa77rf2HqKi8ZaQN/NRp7uVqfY++JVI+h3CLyMk8wTL
FifbLPKbSCW7PAFEfM3wh76VQg1CHpHOPVp/wno=
-----КОНЕЦ СЕРТИФИКАТА-----
subject=/C=US/ST=Калифорния/L=Сан-Франциско/O=BadSSL/CN=*.badssl.com
issuer=/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL Ненадежный корневой центр сертификации
---
Имена ЦС сертификата клиента не отправлены
Дайджест одноранговой подписи: SHA512
Временный ключ сервера: ECDH, P-256, 256 бит
---
SSL-рукопожатие прочитало 3561 байт и записало 425 байт.
---
Новый, TLSv1/SSLv3, шифр ECDHE-RSA-AES128-GCM-SHA256.
Открытый ключ сервера 2048 бит.
Поддерживается безопасное повторное согласование IS
Сжатие: НЕТ
Расширение: НЕТ
ALPN не согласован
SSL-сессия:
Протокол: TLSv1.2
Шифр: ECDHE-RSA-AES128-GCM-SHA256
Идентификатор сеанса: AC5EB655FAEA1C1A320CA930E6A087FBFE020D3D9C451A72DD7CE77A8080AF0D
Идентификатор сеанса-ctx:
Мастер-ключ: 419065F69901D74454A224DD22F9D459FA85E6EB4D6F043C649C8FDFA2E5E1FD9C168AC270087B88511B0939927F9A0A
Key-Arg : Нет
Идентификация PSK: нет
Подсказка идентификации PSK: нет
Имя пользователя SRP: нет
Подсказка срока действия билета сеанса TLS: 300 (секунд)
Билет сеанса TLS:
0000 - cc 91 34 52 b1 ce c6 7c-8a 97 27 b0 b4 50 d6 9d ..4R...|..'..P..
0010 - 27 b8 87 13 0b 70 92 e7-23 be 57 5c 00 31 f7 90 '....p..#.W\.1..
0020 - 65 e3 08 d5 63 14 e9 cd-cc 50 59 3f 2a 98 31 d1 e...c....PY?*.1.
0030 - ab f8 ca a8 09 aa 66 bf-7c ff b6 66 42 10 8b 6e ......f.|..fB..n
0040 - c7 e8 7b f3 2b 35 b3 76-8c 95 b3 b5 37 85 09 42 ..{.+5.v....7..B
0050 - 83 a9 c3 f7 54 f4 c5 f5-b2 0d d5 fa c6 24 a6 e2 ....T........$..
0060 - fb 03 cf 35 9c 0d cc 48-e0 bc fc 43 11 3c 19 51 ...5...H...C.<.Q
0070 - 0a 23 7d b2 6c ff 9b e2-bc 64 1d 74 34 cb 13 7b .#}.l....d.t4..{
0080 - c8 55 47 95 71 9d 94 00-33 a0 a0 87 d4 4a fb 81 .UG.q...3....J..
0090 - 34 36 28 2e ac d7 22 36-36 5f 9c cb 3f 0d e7 00 46(..."66_..?...
00a0 - e2 b7 d0 35 48 81 2f c7-9d a1 8a f6 52 a3 11 17 ...5H./.....R...
00b0 - 67 89 94 d3 66 2b 5c c4-73 c5 72 1e 84 46 57 a5 g...f+\.s.r..FW.
00c0 - 77 05 bc 49 a3 1a fe e6-da a8 0f 40 e2 17 f0 40 w..I.......@...@
Время начала: 1644060097
Время ожидания: 300 (сек)
Код возврата проверки: 19 (самоподписанный сертификат в цепочке сертификатов)
---
Вопрос
СДЕЛАНО
Обратите внимание, что первый вывод после СВЯЗАННЫЙ
линия: глубина=1 .../проверить ошибку:num=19:....
указывает, что проверка сертификата не удалась; Однако openssl
игнорирует эту ошибку и завершает рукопожатие, в результате чего получается последний раздел вывода: SSL-сеанс: / Протокол: (действительный) / Шифр: (действительный) / ... / Проверить код возврата: ...
после чего вы должны ввести Вопрос
и return или control-D (только), чтобы выйти из программы, или control-C, чтобы убить, если вы не добавите </dev/null
в командной строке, что имеет тот же эффект, что и автоматический ввод control-D. На данный момент вам не нужно понимать конкретные значения протокола и шифра, просто они НЕ являются чем-то вроде «нет», «ошибка» или «отсутствует».
Но имейте в виду, что текст сообщения OpenSSL для verify=19 неполный до такой степени, что может сбивать с толку; в целом совершенно нормально, когда цепочка сертификатов с сервера SSL/TLS включает корневой сертификат, который является самозаверяющим, и если этот корень находится в локальном хранилище доверенных сертификатов OpenSSL (и curl/GnuTLS, безусловно, должен) принимать такую цепочку. Только если корень находится в цепочке И НЕ является локальным доверенным лицом, вы получите этот проверочный код. Другие коды подтверждения, такие как «истек срок действия», в основном имеют более четкие сообщения.
Также обратите внимание, что я использовал -имя сервера
с именем хоста; это вызывает SNI = указание имени сервера которые сегодня используют многие серверы SSL/TLS, в том числе badssl.com
, необходимо для обслуживания правильных сертификатов. Однако версия curl в Ubuntu 16.04 НЕ отправляет SNI; без исследований я не знаю, связано ли это с немного (но не очень) более старой версией curl, использованием GnuTLS или просто с ошибкой в сборке. Но в любом случае в качестве пробной попытки в openssl s_client
команда против вашего сервера как с, так и без -сервер имя хоста
часть и сохраните вывод (с перенаправлением или тройником, предпочтительно включая stderr с &>
или же |& тройник
или эквивалент), потому что они могут нам понадобиться. Если версия с SNI работает, а версия без SNI выдает ошибку проверки, это ваша проблема — отсутствие SNI. (Это может быть трудно исправить, но, по крайней мере, вы знаете, что это такое.)
В противном случае посмотрите на вывод без SNI. Если OpenSSL сообщает об ошибке проверки (согласие с curl/GnuTLS), посмотрите соответствующее сообщение — оно должно как минимум указывать на проблему, если не точно на нее. Если OpenSSL не сообщает об ошибке проверки (где curl/GnuTLS делает это, используя одно и то же предоставленное системой хранилище доверенных сертификатов в /etc/ssl), это будет сложнее, поэтому я оставлю это сейчас и добавлю позже, если это необходимо.