Рейтинг:0

curl: (60) ошибка проверки сертификата сервера CRLfile: нет

флаг cn

Я постепенно перехожу от эксклюзивной роли разработчика к гибридной роли DevOps в моей компании. Это означает, что я новичок во многом, пожалуйста, будьте со мной полегче... :-p

Сервер моего клиента работает под управлением Ubuntu 16.04 с PHP 5.6.4, и на административном портале их сайта есть функция, которая запускает завиток команда (по существу) обратно к себе для какой-то синхронизации файлов. И это терпит неудачу в течение некоторого времени (несколько недель/месяцев). Проблема (я считать) заключается в том, что проверка сертификата не удалась, и, таким образом, функция умирает на корню.

Когда я подключаюсь к серверу по ssh, я могу без проблем подключиться куда угодно (Google, example.org и т. д.). Но попытка просто закрутить основной URL-адрес сайта боркс.

$ curl -v https://www.[имя-моего-сайта].com

* Попытка [мой-сайт-IP]...
* Подключено к порту [my-site-name] ([my-site-IP]) 443 (#0)
* найдено 258 сертификатов в /etc/ssl/certs/ca-certificates.crt
* найдено 908 сертификатов в /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

curl выполняет проверку SSL-сертификата по умолчанию, используя «пакет»
 открытых ключей центра сертификации (ЦС) (сертификаты ЦС). Если по умолчанию
 файл пакета не подходит, вы можете указать альтернативный файл
 используя параметр --cacert.
Если этот сервер HTTPS использует сертификат, подписанный ЦС, представленным в
 пакет, проверка сертификата, вероятно, не удалась из-за
 проблема с сертификатом (возможно, срок его действия истек, или имя может
 не соответствует доменному имени в URL).
Если вы хотите отключить проверку сертификата curl, используйте
 параметр -k (или --insecure).

Я знаю, что могу запустить керлинг с чтобы это было небезопасно, но я не решаюсь сделать это. Я предполагаю, что первый вопрос заключается в том, не следует ли мне беспокоиться о запуске этого с небезопасным флагом, поскольку технически он вообще не покидает сервер? Я протестировал точно такую ​​же команду curl на одном из наших новых компьютеров под управлением Ubuntu 18.x, а также на DigitalOcean под управлением v20 без каких-либо проблем — как внешние, так и внутренние завитки работали отлично.

Я даже могу быть на другом сервере и вернуться к моему, у которого возникли проблемы, и это тоже работает нормально.

Я пробовал все, что мог придумать (что, по общему признанию, не так уж много), и ничего не работает.

  • запускать обновления для пакетов curl и certbot
  • принуждение обновление-ca-сертификаты
  • добавлен /etc/ssl/сертификаты/cacert.pem к обоим curl.cainfo и openssl.cafile переменные в php.ini

Я знаю, что это, вероятно, не имеет значения, но просто для полноты картины я также проверил сайт через различные службы онлайн-проверки:

Все вернулись с положительными результатами. Единственным недостатком (я думаю) является то, что SSLLabs поставила нам оценку «B», потому что, по-видимому, TLS 1.0 все еще включен.


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

Предложения/советы/хитрости ??

1000 заранее спасибо!

флаг in
Обновите сервер. Ubuntu 16.04 устарел, а openssl и все остальное, связанное с шифрованием, настолько устарели, что их просто невозможно использовать. Обновите сервер до поддерживаемой версии.
флаг cn
@GeraldSchneider Спасибо, и я согласен!! Это именно то, что я предложил нашему премьер-министру во время схватки сегодня утром. Но... это (к сожалению) не в планах прямо сейчас. Что еще хуже... они переезжают на хостинг Pantheon в... августе (?!?), но в краткосрочной перспективе необходимо исправить это на текущем сервере.
dave_thompson_085 avatar
флаг jp
Версии curl и certbot значения не имеют. **Попробуйте обновить пакет `ca-certificates`; ** панель запуска утверждает, что версия 20210119~16.04.1 актуальна. Обратите внимание, что команда `update-ca-certificates` не имеет ничего общего с обновлением пакета, а скорее делает сайт или вручную переопределяет данные _из_ пакета. Если это не поможет, вам придется сравнить сертификаты, используемые сервером, с хранилищем доверенных сертификатов, что потребует реального обучения и размышлений.
флаг cn
Спасибо @dave_thompson_085. Похоже, у меня уже была последняя версия пакета ca-certificates. И... ха, я полностью согласен с частью комментария выше о "фактическом обучении и размышлении". Начав с дизайна, затем перейдя в разработку, а теперь — медленно — получая роль DevOps/SysAdmin… это было немного пугающе и запутанно, по крайней мере для меня.
dave_thompson_085 avatar
флаг jp
Ладно, становится сложнее. См. полуответ.
Рейтинг:0
флаг jp

Мета: не ответ, по крайней мере, пока, но некоторая информация и совет.

Ладно, легкий случай не подходит. Как вы уже столкнулись, завиток не дает очень полезной информации, когда получает ошибку проверки сертификата из базового стека 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), это будет сложнее, поэтому я оставлю это сейчас и добавлю позже, если это необходимо.

Ответить или комментировать

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