curl: (60) SSL-сертификат: не удалось получить сертификат локального эмитента
[email protected]:/home/sclr/certs/FreshCerts# curl --ftp-ssl --verbose ftp://{abc}/ -u trup:trup --cacert /etc/ssl/certs/ca-certificates.crt * About to connect() to {abc} port 21 (#0) * Trying {abc}... * Connected to {abc} ({abc}) port 21 (#0) < 220-Cerberus FTP Server - Home Edition < 220-This is the UNLICENSED Home Edition and may be used for home, personal use only < 220-Welcome to Cerberus FTP Server AUTH SSL < 234 Authentication method accepted * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS alert, Server hello (2): * SSL certificate problem: unable to get local issuer certificate * Closing connection 0 curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
Относительно проблемы с сертификатом SSL: невозможно получить сертификат локального эмитента. Скорее, это относится к системе, отправляющей запрос CURL (и сервер, не получающий запрос)
1) Загрузите последнюю версию cacert.pem с https://curl.haxx.se/ca/cacert.pem
2) Добавьте следующую строку в php.ini (если это общий хостинг, и у вас нет доступа к php.ini, вы можете добавить это в .user.ini в public_html)
curl.cainfo="/path/to/downloaded/cacert.pem"
Убедитесь, что вы заключили путь в двойные кавычки !!!
3) По умолчанию процесс FastCGI будет обрабатывать новые файлы каждые 300 секунд (при необходимости вы можете изменить частоту, добавив пару файлов, как предлагается здесь https://ss88.uk/blog/fast-cgi-and-user-ini -files-the-new-htaccess / )
Он терпит неудачу, поскольку cURL не может проверить сертификат, предоставленный сервером.
Есть два способа заставить это работать:
-
Используйте cURL с опцией
-k
которая позволяет завиткам делать небезопасные соединения, то есть cURL не проверяет сертификат. -
Добавьте корневой ЦС (ЦС, подписывающий сертификат сервера) в
etc/ssl/certs/ca-certificates.crt
Вы должны использовать опцию 2, поскольку это опция, которая гарантирует, что вы подключаетесь к защищенному FTP-серверу.
Я решил эту проблему, добавив один код строки в скрипт cURL:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
Предупреждение : это делает запрос абсолютным небезопасным (см. Ответ by @YSU)!
Если бы эта проблема возникла после установки Git Extensions v3.48. Пытался установить mysysgit снова, но такую же проблему. В конце концов, пришлось отключить (просьба рассмотреть последствия для безопасности!) Проверка Git SSL с помощью:
git config --global http.sslVerify false
но если у вас есть сертификат домена, лучше добавьте его в (Win7)
C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
В моем случае это оказалось проблемой при установке моего сертификата на службу, которую я пытался использовать cURL. Мне не удалось связать промежуточные и корневые сертификаты с сертификатом домена . Сначала не было очевидно, что это была проблема, потому что Chrome разработал ее и принял сертификат, несмотря на отсутствие промежуточных и корневых сертификатов.
После связывания сертификата все работало, как ожидалось. Я так привязан
$ cat intermediate.crt >> domain.crt
И повторяется для всех промежуточных и корневых сертификатов.
Недавно мы столкнулись с этой ошибкой. Оказывается, это связано с тем, что корневой сертификат не установлен в каталоге хранилища CA должным образом. Я использовал команду curl, где я напрямую указывал директорию CA. curl --cacert /etc/test/server.pem --capath /etc/test ...
Эта команда терпела неудачу каждый раз с завивкой: (60) Проблема сертификата SSL: не удалось получить сертификат локального эмитента.
После использования strace curl ...
было определено, что curl искал файл корневого сертификата с именем 60ff2731.0, который основан на консенсусе именования hashей openssl. Поэтому я нашел эту команду для эффективного импорта корневого сертификата должным образом:
ln -s rootcert.pem `openssl x509 -hash -noout -in rootcert.pem`.0
который создает программную ссылку
60ff2731.0 -> rootcert.pem
curl, под обложками считывает cert.pem cert, определяет имя корневого файла cert (rootcert.pem), преобразует его в его хеш-имя, затем выполняет поиск файла ОС, но не может его найти.
Таким образом, вынос – это использование strace при запуске завитки, когда ошибка curl является неясной (была огромная помощь), а затем обязательно установите корневой сертификат, используя соглашение об именах openssl.
Это, скорее всего, отсутствующий сертификат с сервера.
Root-> средне-> Сервер
Сервер должен отправить сервер и промежуточное звено как минимум.
openssl s_client -showcerts -starttls ftp -crlf -connect abc:21
используйте openssl s_client -showcerts -starttls ftp -crlf -connect abc:21
.
Если возвращается только один сертификат (либо сам подписан, либо выдается), то вы должны выбрать:
- установить сервер
- доверяйте этому сертификату и добавьте его в свой магазин сертификатов CA (не лучшая идея)
- отключить доверие, например
curl -k
(очень плохая идея)
Если сервер вернулся, более одного, но не включая самоподписанный (корневой) сертификат:
- установите CA (корневой) сертификат в вашем хранилище CA для этой цепочки, например, google эмитента. ( ТОЛЬКО, если вы доверяете этому ЦС)
- иметь сервер, фиксированный для отправки CA как части цепочки
- доверять сертификату в цепочке
- отключить доверие
Если сервер вернул корневой сертификат ЦС, то он не находится в вашем хранилище ЦС, ваши варианты:
- Добавить (доверять)
- отключить доверие
Я проигнорировал истекшие / отозванные сертификаты, потому что не было сообщений, указывающих на это. Но вы можете проверить сертификаты с помощью openssl x509 -text
Учитывая, что вы подключаетесь к домашнему изданию ( https://www.cerberusftp.com/support/help/installing-a-certificate/ ) ftp-сервера, я собираюсь сказать, что он подписан сам.
Пожалуйста, напишите более подробную информацию, например, вывод из openssl.
Для меня простая установка сертификатов помогла:
sudo apt-get install ca-certificates
На windowsх я столкнулся с этой проблемой. Curl был установлен mysysgit, поэтому загрузка и установка последней версии исправила мою проблему.
В противном случае это достойные инструкции о том, как обновить CA-сертификат, который вы могли бы попробовать.
В windowsх – если вы запускаете из cmd
> curl -X GET "https://some.place"
Загрузите cacert.pem из https://curl.haxx.se/docs/caextract.html
Установить переменную среды:
CURL_CA_BUNDLE = C:\Program Files\curl-7.57.0\src\cacert.pem
и перезагрузить среду
refreshenv
Теперь попробуйте еще раз
Причина проблемы: https://laracasts.com/discuss/channels/general-discussion/curl-error-60-ssl-certificate-problem-unable-to-get-local-issuer-certificate/replies/95548
У меня было другое дело. Я размещаю сайт за брандмауэром. Ошибка была вызвана pfSense.
Network layout: |Web Server 10.xxx| <-> |pfSense 49.xxx| <-> |Open Internet|
Благодаря этому ответу я случайно нашел причину.
Все хорошо, когда я обратился к моему сайту с WAN.
Однако, когда сайт был доступен из локальной сети (например, когда WordPress сделал запрос на curl
на свой собственный сервер, несмотря на использование WAN IP 49.xxx
), ему была предложена страница входа в систему pfSense.
Я идентифицировал сертификат как pfSense webConfigurator Self-Signed Certificate
сертификат pfSense webConfigurator Self-Signed Certificate
. Неудивительно, что curl
провалил ошибку.
Причина. Случилось так, что curl
использовал IP-адрес WAN-сайта 49.xxx
. Но в контексте веб-сервера WAN IP был брандмауэром.
Debug: Я обнаружил, что получаю сертификат pfSense.
Решение. На сервере, на котором размещен сайт, укажите его собственное доменное имя на 127.0.0.1
Применяя решение, запрос curl
был правильно обработан веб-сервером и не перенаправлен на брандмауэр, который ответил, отправив страницу входа.
-k
(SSL) Эта опция явно позволяет завитка выполнять «небезопасные» SSL-соединения и передачи. Начиная с curl 7.10, все SSL-соединения будут пытаться быть безопасными с помощью пакета сертификатов CA, установленного по умолчанию. Это заставляет все соединения считаться «небезопасными» сбой, если используется -k / – insecure.
man.cx/curl
Да, вам также нужно добавить сертификат CA. Добавление fragmentа кода в Node.js для четкого представления.
var fs = require(fs) var path = require('path') var https = require('https') var port = process.env.PORT || 8080; var app = express(); https.createServer({ key: fs.readFileSync(path.join(__dirname, './path to your private key/privkey.pem')), cert: fs.readFileSync(path.join(__dirname, './path to your certificate/cert.pem')), ca: fs.readFileSync(path.join(__dirname, './path to your CA file/chain.pem'))}, app).listen(port)
До сих пор я видел, что эта проблема возникает в корпоративных сетях по двум причинам: одна или обе из которых могут происходить в вашем случае:
- Из-за того, как работают сетевые прокси-серверы , у них есть свои собственные сертификаты SSL, тем самым изменяя сертификаты, которые скручиваются. Многие или большинство корпоративных сетей заставляют вас использовать эти прокси.
- Некоторые антивирусные программы, работающие на клиентских ПК, также действуют аналогично прокси HTTPS, чтобы они могли сканировать ваш сетевой трафик. У вашей антивирусной программы может быть возможность отключить эту функцию (при условии, что ее администраторы разрешат ее).
В качестве дополнительной заметки, № 2 выше, вы можете почувствовать себя неловко в том, что ваш якобы безопасный трафик TLS сканируется. Это корпоративный мир для вас.
В частности, для пользователей Windows
, используя curl-7.57.0-win64-mingw
или аналогичную версию.
Это немного поздно, и существующие ответы верны. Но мне все еще пришлось немного поработать, чтобы заставить его работать на моей машине с Windows, хотя процесс на самом деле довольно прямолинейный. Итак, разделите пошаговый процесс.
Эта ошибка в основном означает, что curl не проверяет сертификат целевого URI. Если вы доверяете эмитенту сертификата (CA), вы можете добавить его в список доверенных сертификатов.
Для этого просмотрите URI (например, в Chrome) и следуйте инструкциям
- Щелкните правой кнопкой мыши значок безопасного замка
- Нажмите на сертификат, он откроет окно с данными сертификата
- Перейдите на вкладку «Курс сертификации».
- Нажмите сертификат ROOT
- Нажмите «Просмотреть сертификат», откроется другое окно сертификата.
- Перейдите на вкладку «Подробности»
- Нажмите «Копировать в файл», откроется мастер экспорта
- Нажмите “Далее
- Выберите «Base-64 encoded X.509 (.CER)»
- Нажмите “Далее
- Дайте дружеское имя, например «MyDomainX.cer» (перейдите к нужному каталогу)
- Нажмите “Далее
- Нажмите «Готово», он сохранит файл сертификата
- Теперь откройте этот файл
.cer
и скопируйте содержимое (включая —– BEGIN CERTIFICATE —– и —– END CERTIFICATE —–) - Теперь перейдите в каталог, где
curl.exe
напримерC:\SomeFolder\curl-7.57.0-win64-mingw\bin
- Откройте файл
curl-ca-bundle.crt
с помощью текстового редактора - Добавьте скопированный текст сертификата в конец файла. Сохранить
Теперь ваша команда должна выполнить штраф в curl.
Простое решение: IN ~/.sdkman/etc/config
, change sdkman_insecure_ssl=true
шаги:
nano ~/.sdkman/etc/config
изменить sdkman_insecure_ssl=false
на sdkman_insecure_ssl=true
Сохранить и выйти