curl: (60) Проблема з сертифікатом SSL: неможливо отримати сертифікат локального емітента

root@sclrdev:/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
< 220 Created by Cerberus, LLC
> 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- файли-новий-htaccess / ).

Це не вдається, оскільки cURL не в змозі перевірити сертифікат, наданий сервером.

Існує два варіанти, щоб змусити це працювати:

1. Використовуйте cURL з -kопцією, яка дозволяє curl робити незахищені з'єднання, тобто cURL не підтверджує сертифікат.

2. Додайте кореневий CA (CA, який підписує сертифікат сервера) в /etc/ssl/certs/ca-certificates.crt

Вам слід скористатися опцією 2, оскільки саме ця опція забезпечує підключення до безпечного FTP-сервера.

Я вирішив цю проблему, додавши один код рядка в скрипт CURL:

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

Попередження : Це робить запит абсолютно незахищеним (див. Відповідь від @YSU)!

У моєму випадку виявилася проблема з установкою мого сертифіката на сервісі, який я намагався споживати з курсом CURL. Мені не вдалося з'єднати / об'єднати проміжні та кореневі сертифікати у свій доменний сертифікат . Спочатку було не очевидно, що це проблема, тому що Chrome розробив це і прийняв сертифікат, незважаючи на те, що вони проміжні та кореневі сертифікати.

Після зв’язування сертифіката все працювало як очікувалося. Я зв'язаний так

$ cat intermediate.crt >> domain.crt

І повторюється для всіх проміжних та кореневих сертифікатів.

Для мене проста установка сертифікатів допомогла:

sudo apt-get install ca-certificates

Виникла ця проблема після встановлення Git Extensions v3.48. Спробував знову встановити mysysgit, але та сама проблема. Зрештою, довелося відключити (будь ласка, врахуйте наслідки для безпеки!) Перевірку SSL Git за допомогою:

git config --global http.sslVerify false

але якщо у вас є сертифікат домену, краще додайте його до (Win7)

C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt

Нещодавно ми зіткнулися з цією помилкою. Виявляється, це було пов'язано з неправильним встановленням кореневого сертифіката в каталозі магазину CA. Я використовував команду curl, де я безпосередньо вказував dir CA. curl --cacert /etc/test/server.pem --capath /etc/test ...Ця команда щоразу провалювалась із згортанням: (60) Проблема SSL-сертифіката: неможливо отримати сертифікат локального емітента.

Після використання strace curl ...було визначено, що curl шукає кореневий файл cert з іменем 60ff2731.0, який базується на конвекції хеш-імен імені opensl. Тож я знайшов цю команду для ефективного імпорту кореневого cert належним чином:

ln -s rootcert.pem `openssl x509 -hash -noout -in rootcert.pem`.0

що створює м'яке посилання

60ff2731.0 -> rootcert.pem

curl, під обкладинками прочитав cert сервера.pem, визначив ім'я файлу root cert (rootcert.pem), перетворив його на його хеш-ім'я, потім здійснив пошук файлів ОС, але не зміг його знайти.

Таким чином, винос є, використовуйте strace під час запуску curl, коли помилка curl невідома (була надзвичайна допомога), а потім переконайтесь, що правильно встановити кореневий cert, використовуючи конвенцію про іменування openssl.

Це, швидше за все, відсутні серт з сервера.

Root-> Intermediate-> Server

Сервер повинен надсилати Сервер і Проміжний мінімум як мінімум.

Використовуйте openssl s_client -showcerts -starttls ftp -crlf -connect abc:21для налагодження проблеми.

Якщо буде повернуто лише один сертифікат (або самостійно підписаний, або виданий), ви повинні вибрати:

1. встановити фіксований сервер
2. довіряйте цьому серту та додайте його до магазину сертифікатів (не найкраща ідея)
3. відключити довіру, наприклад curl -k(дуже погана ідея)

Якщо сервер повернувся, більше одного, але не включаючи самопідписаний (root) cert:

1. встановіть сервер CA (root) у своєму магазині CA для цього ланцюжка, наприклад, google-емітент. ( ТІЛЬКИ, якщо ви довіряєте цьому CA)
2. встановити сервер, зафіксований, щоб відправити ЦС як частину ланцюга
3. довіряйте серту в ланцюжку
4. відключити довіру

Якщо сервер повернув кореневий сертифікат CA, він не знаходиться у вашому магазині CA, вашими параметрами є:

1. Додайте (довіряйте) це
2. відключити довіру

Я проігнорував термін дії / відкликав сертифікати, оскільки не було повідомлень про це. Але ви можете оглянути серти зopenssl x509 -text

З огляду на те, що ви підключаєтесь до домашнього видання ( https://www.cerberusftp.com/support/help/installing-a-certificate/ ) ftp-сервера, я скажу, що він підписався самостійно.

Будь ласка, опублікуйте більше деталей, як-от вихід із openssl.

Відповідно до документів CURL ви також можете передавати сертифікат curlкоманді:

Отримайте сертифікат CA, який може підтвердити віддалений сервер, і скористайтеся належним параметром, щоб вказати цей сертифікат CA для перевірки під час підключення. Для libcurlхакерів:curl_easy_setopt(curl, CURLOPT_CAPATH, capath);

За допомогою інструменту командного рядка curl: --cacert [file]

Наприклад:

curl --cacert mycertificate.cer -v https://www.stackoverflow.com

Можливо, достатньо лише оновити список сертифікатів

sudo update-ca-certificates -f

update-ca-сертифікати - це програма, яка оновлює каталог / etc / ssl / certs для зберігання SSL-сертифікатів та генерує ca-certifikat.crt, об'єднаний однофайловий список сертифікатів.

Спробуйте перевстановити curl в Ubuntu та оновити мої сертифікати CA, sudo update-ca-certificates --freshякими оновлено certs

У Windows у мене була ця проблема. Curl був встановлений mysysgit, тому завантаження та встановлення новітньої версії виправили мою проблему.

В іншому випадку це гідні вказівки щодо оновлення свого сертифіката CA, який ви можете спробувати.

Так, вам також потрібно додати сертифікат CA. Додавання фрагмента коду в 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:

- abc.crt
- abc.pem
- abc-bunde.crt

У abc.crtфайлі був лише один сертифікат:

-----BEGIN CERTIFICATE-----
/*certificate content here*/
-----END CERTIFICATE-----

Якби я поставив його в такому форматі, браузер не показав би жодних помилок (Firefox), але я отримав би curl: (60) SSL certificate : unable to get local issuer certificateпомилку, коли я зробив запит на згортання.

Щоб виправити цю помилку, перевірте свій abc-bunde.crtфайл. Ви, швидше за все, побачите щось подібне:

-----BEGIN CERTIFICATE-----
/*additional certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*other certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*different certificate content here*/
-----END CERTIFICATE-----

Це ваші проміжні та кореневі сертифікати. Помилка відбувається через те, що вони відсутні у сертифікаті SSL, який ви постачаєте до своєї програми.

Щоб виправити помилку, комбінуйте вміст обох цих файлів у такому форматі:

-----BEGIN CERTIFICATE-----
/*certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*additional certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*other certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*different certificate content here*/
-----END CERTIFICATE-----

Зауважте, що між сертифікатами немає пробілів в кінці або на початку файлу. Після того, як ви поставите цей комбінований сертифікат у вашу заявку, вашу проблему слід вирішити.

На 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.x.x.x| <-> |pfSense 49.x.x.x| <-> |Open Internet|

Я випадково знайшов причину, завдяки цій відповіді .

Все добре, коли я перейшов до свого сайту з WAN.

Однак, коли доступ до сайту здійснюється через внутрішню локальну мережу (наприклад, коли Wordpress подав curlзапит на свій власний сервер, незважаючи на використання WAN IP 49.x.x.x), йому було подано сторінку входу в систему pfSense.

Я визначив сертифікат як pfSense webConfigurator Self-Signed Certificate. Недарма curlвикинув помилку.

Причина: сталося те, що curlвикористовується IP-адреса сайту WAN 49.x.x.x. Але в контексті веб-сервера WAN IP був брандмауером.

Налагодження: я виявив, що отримую сертифікат pfSense.

Рішення: На сервері, що розміщує сайт, вкажіть власне доменне ім’я на 127.0.0.1

Застосовуючи рішення, curlзапит належним чином оброблявся веб-сервером, а не пересилався до брандмауера, який відповів, надіславши сторінку входу.

Це проблема магазину ssh-сертифікатів. Вам потрібно завантажити дійсний файл pem сертифіката з цільового веб-сайту CA, а потім створити файл м'якого посилання, щоб доручити ssl довіреному сертифікату.

openssl x509 -hash -noout -in DigiCert_Global_Root_G3.pem

ти отримаєш dd8e9d41

побудувати solf-посилання з хеш-номером та суфіксом файлу з .0 (крапка-нуль)

dd8e9d41.0

Потім спробуйте ще раз.

1. Завантажте https://curl.haxx.se/ca/cacert.pem

2. Після завантаження перемістіть цей файл на свій сервер wamp.

   Для досвіду: D: \ wamp \ bin \ php \

3. Потім додайте наступний рядок у файл php.ini внизу.

curl.cainfo = "D: \ wamp \ bin \ php \ cacert.pem"

4. Тепер перезапустіть ваш сервер wamp.

Ви повинні змінити серверний сер на, cert.pemщоб у fullchain.pem
мене була та сама проблема з Perl HTTPS Daemon:
я змінив:
SSL_cert_file => '/etc/letsencrypt/live/mydomain/cert.pem'
на:
SSL_cert_file => '/etc/letsencrypt/live/mydomain/fullchain.pem'

Поки що я бачив, як ця проблема трапляється в корпоративних мережах через дві причини, одна чи обидві можуть статися у вашому випадку:

1. Через спосіб проксі-мережі працюють , вони мають свої сертифікати SSL, тим самим змінюючи сертифікати, які бачить curl. Багато або більшість корпоративних мереж змушують вас використовувати ці проксі.
2. Деякі антивірусні програми, що працюють на клієнтських ПК, також діють аналогічно HTTPS-проксі, щоб вони могли сканувати ваш мережевий трафік. У вашої антивірусної програми може бути відключена ця функція (якщо ваші адміністратори це дозволять).

Як бічна примітка, № 2 вище може змусити вас неприємно ставитись до скануваного начебто безпечного трафіку TLS. Це корпоративний світ для вас.

Була ця проблема, і вона не була вирішена з новою версією. / etc / certs мав кореневу cert, браузер сказав, що все добре. Після деякого тестування я отримав від ssllabs.com попередження про те, що моя ланцюг не є повною (Дійсно, це був ланцюжок для старого сертифіката, а не нового). Після виправлення ланцюга cert все було добре, навіть із завиткою.

У мене була ця проблема з Digicert усіх ЦА. Я створив файл digicertca.pem, який був як проміжним, так і кореневим, вклеєним разом в один файл.

curl https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem
curl https://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt.pem

curl -v https://mydigisite.com/sign_on --cacert DigiCertCA.pem
...
*  subjectAltName: host "mydigisite.com" matched cert's "mydigisite.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
*  SSL certificate verify ok.
> GET /users/sign_in HTTP/1.1
> Host: mydigisite.com
> User-Agent: curl/7.65.1
> Accept: */*
...

Еорекан мав відповідь, але тільки я та один голос отримали голосування за його відповідь.

Спеціально для Windowsкористувачів, які використовуютьcurl-7.57.0-win64-mingw або подібну версію.

Це трохи пізно, і існуючі відповіді вірні. Але мені все одно довелося трохи боротися, щоб він працював на моїй машині Windows, хоча процес насправді є досить прямим. Отже, обмін покроковим процесом.

В основному ця помилка означає, що curl не може перевірити сертифікат цільового URI. Якщо ви довіряєте емітенту сертифіката (CA), можете додати це до списку довірених сертифікатів.

Для цього перегляньте URI (наприклад, на Chrome) та виконайте кроки

1. Клацніть правою кнопкою миші на значку безпечного замока
2. Натисніть на сертифікат, він відкриє вікно з деталями сертифіката
3. Перейдіть на вкладку "Шлях до сертифікації"
4. Клацніть сертифікат ROOT
5. Клацніть Переглянути сертифікат, це відкриє інше вікно сертифіката
6. Перейдіть на вкладку Деталі
7. Клацніть Копіювати у файл, відкриється майстер експорту
8. Клацніть Далі
9. Виберіть "Base-64 з кодуванням X.509 (.CER)"
10. Клацніть Далі
11. Назвіть дружнє ім’я, наприклад, "MyDomainX.cer" (перегляньте потрібний каталог)
12. Клацніть Далі
13. Натисніть кнопку Готово, це збереже файл сертифіката
14. Тепер відкрийте цей .cerфайл і скопіюйте вміст (включаючи ----- НАЧАЙТЕ СЕРТИФІКАТ ----- та ----- ЗАКРИТИ СЕРТИФІКАТ -----)
15. Тепер перейдіть до каталогу, де curl.exeзберігається, наприкладC:\SomeFolder\curl-7.57.0-win64-mingw\bin
16. Відкрийте curl-ca-bundle.crtфайл за допомогою текстового редактора
17. Додайте скопійований текст сертифіката до кінця файлу. Зберегти

Тепер ваша команда повинна добре виконати завиток.

це може допомогти вам у справі:

$client = new Client(env('API_HOST'));
$client->setSslVerification(false);

перевірено на рушниці / гарматі 3. *

Просте рішення: IN ~/.sdkman/etc/config, змінаsdkman_insecure_ssl=true

Етапи: зміна
нано для збереження та виходу~/.sdkman/etc/config
sdkman_insecure_ssl=falsesdkman_insecure_ssl=true