curl: (60) Vấn đề chứng chỉ SSL: không thể lấy chứng chỉ nhà phát hành địa phương

258 
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.
curl  ssl  openssl  ssl-certificate  x509certificate 
— người dùng 3812540
nguồn
1
— payapl ipn
Tôi đã có vấn đề tương tự. Điều này làm việc cho tôi stackoverflow.com/a/29649024
— Sagruob
Trong trường hợp của tôi, superuser.com/a/719047/137881 đã giúp.
— Abdull
//, Trong trường hợp của tôi, tôi đã gặp lỗi này khi thực hiện các yêu cầu curl đến máy chủ HashiCorp Vault cho đến khi tôi cài đặt chứng chỉ X509 với end-entity / Intermediates / root theo thứ tự ngược lại, mỗi cái được mã hóa Base64.
— Nathan Basan
//, Bạn đã làm nghiên cứu gì về điều này trước khi sao chép lỗi vào đây?
— Nathan Basan

Câu trả lời:

231

Liên quan đến 'vấn đề chứng chỉ SSL: không thể nhận được lỗi chứng chỉ nhà phát hành địa phương'. Điều quan trọng cần lưu ý là điều này áp dụng cho hệ thống gửi yêu cầu CURL và KHÔNG phải máy chủ nhận yêu cầu.

  1. Tải xuống cacert.pem mới nhất từ https://curl.haxx.se/ca/cacert.pem

  2. Thêm dòng sau vào php.ini: (nếu đây là lưu trữ được chia sẻ và bạn không có quyền truy cập vào php.ini thì bạn có thể thêm dòng này vào .user.ini trong public_html).

    curl.cainfo="/path/to/downloaded/cacert.pem"

    Hãy chắc chắn rằng bạn kèm theo đường dẫn trong dấu ngoặc kép !!!

  3. Theo mặc định, quy trình FastCGI sẽ phân tích các tệp mới cứ sau 300 giây (nếu cần, bạn có thể thay đổi tần số bằng cách thêm một vài tệp như được đề xuất tại đây https://ss88.uk/blog/fast-cgi-and-user-ini- tập tin-the-new-htaccess / ).

— Dahomz
nguồn
1
Việc đầu tiên liên quan đến chứng nhận các hoạt động được thực hiện bằng thư viện OpenSSL; thứ hai cho các yêu cầu được thực hiện bằng cURL
— Mike
4
Thật ra tôi đã vật lộn trong một tiếng đồng hồ vì tôi không viết đường dẫn trong dấu ngoặc kép. Vì vậy, xin vui lòng ghi chú ở đâycurl.cainfo="/path/to/downloaded/cacert.pem" // Do not forget to write between quotes
— Himanshu Upadhyay
12
Tôi không thấy bất kỳ tài liệu tham khảo nào trong câu hỏi cho PHP. Tại sao te tham khảo trong câu trả lời? Nếu câu hỏi đã được chỉnh sửa thì câu trả lời có thể được chỉnh sửa để phản ánh dòng lệnh hiện đang được sử dụng không?
— Adam
5
@Adam Trong khi câu hỏi không đề cập đến PHP, thì đây là kết quả tìm kiếm số 1 trong Google cho thông báo lỗi cụ thể do PHP tạo ra. Vì vậy, có thể nó không trả lời cụ thể câu hỏi của OP, nhưng có vẻ như nó vẫn hữu ích cho cộng đồng.
— rinogo
1
Câu trả lời này đã gây hiểu lầm cho tôi vì đây là một giải pháp liên quan đến PHP
— Wasif Khan
141

Đó là thất bại vì cURL không thể xác minh chứng chỉ được cung cấp bởi máy chủ.

Có hai lựa chọn để làm việc này:

  1. Sử dụng cURL với -ktùy chọn cho phép cuộn tròn để tạo các kết nối không an toàn, đó là cURL không xác minh chứng chỉ.

  2. Thêm CA gốc (CA ký chứng chỉ máy chủ) vào /etc/ssl/certs/ca-certificates.crt

Bạn nên sử dụng tùy chọn 2 vì đây là tùy chọn đảm bảo rằng bạn đang kết nối với máy chủ FTP an toàn.

— Yuvika
nguồn
1
Tôi đã thêm tệp rootCA.pem của mình vào bên trong: - root @ sclrdev: / home / certs / FreshCerts # ll /etc/ssl/certs/rootCA.pem -rwxrwxrwx 1 root 1302 Jul 8 00:09 / etc / ssl / certs / rootCA.pem * Ngay cả khi tôi đã xác minh tệp ServerCert ve.pem bằng rootCA.pem: - root @ sclrdev: / home / certs / FreshCerts # openssl verify -CAfile rootCA.pem ../ServerCert ve.pem ServerCertuler.pem: OK và cũng nội dung của rootCA.pem bên trong ca-cert.crt. root @ sclrdev: / home / sclr / subhendu / certs / FreshCerts # ll /etc/ssl/certs/ca-certert.crt -rw-r - r-- 1 root 247945 ngày 8 tháng 7 00:10 / etc / ssl /certs/ca-certert.crt
— user3812540
Tôi không thể tìm ra tôi đang đi sai ở đâu. Trong dấu vết của WireShark, tôi gặp phải lỗi sau: - Máy khách Xin chào Máy chủ Xin chào, Chứng chỉ, Máy chủ Xin chào Thông báo đã hoàn thành (cấp độ: Tử vong, Mô tả: CA không xác định (48)) Bạn có thể vui lòng hướng dẫn và giúp tôi trong việc này không?
— dùng3812540
Cách openssl hoạt động là nó cố gắng hoàn thành chuỗi chứng chỉ trong khi xác minh. Là chứng chỉ máy chủ của bạn được ký bởi một CA xen kẽ và không phải là CA gốc. ví dụ
— Yuvika
Chứng chỉ của tôi chỉ được ký bởi CA gốc.
— dùng3812540
1
Tôi đã gặp một số lỗi: - root @ sclrdev: ~ # openssl s_client -connect <server_ip>: 21 -showcerts CONNECTED (00000003) 3074050248: error: 140770FC: Các thường trình SSL: SSL23_GET_SERVER_HELLO: không có chứng chỉ ngang hàng --- Không có chứng chỉ CA nào được gửi tên --- Bắt tay SSL đã đọc 7 byte và được viết 225 byte --- Mới, (KHÔNG), Mật mã là (KHÔNG) Tái tạo bảo mật KHÔNG được hỗ trợ Nén: Mở rộng NONE: KHÔNG --- Tôi không chắc điều này có nghĩa là gì?
— dùng3812540
69

Tôi đã giải quyết vấn đề này bằng cách thêm một mã dòng trong tập lệnh cURL:

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

Cảnh báo : Điều này làm cho yêu cầu không an toàn tuyệt đối (xem câu trả lời của @YSU)!

— Vijay Bhandari
nguồn
42
Điều này có thể giúp phá vỡ vấn đề. Nhưng nó hoàn toàn bỏ lỡ ý tưởng về https và hệ thống chứng nhận.
— Stephan Richter
1
Làm! Bỏ qua nhanh chóng bẩn nếu bạn không quan tâm đến chứng chỉ
— Gilly
2
Điều này làm cho nó hoàn toàn không an toàn.
— Moox
1
Tôi đã phải đối mặt với vấn đề này trên máy chủ cục bộ của mình mặc dù cùng một mã hoạt động tốt trên máy chủ dàn dựng. Tốt cho tôi như nó là trên địa phương. Cảm ơn
— sabin
1
thêm kiểm tra này để đảm bảo bạn chỉ sử dụng nó với máy chủ cục bộ if( stristr("127.0.0.1",$_SERVER["SERVER_NAME"] ) || stristr("localhost",$_SERVER["SERVER_NAME"] )) curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
— Hussain
20

Trong trường hợp của tôi, nó hóa ra là một vấn đề với việc cài đặt chứng chỉ của tôi trên dịch vụ mà tôi đang cố gắng sử dụng với cURL. Tôi không thể bó / ghép các chứng chỉ trung gian và gốc vào chứng chỉ miền của mình . Ban đầu, rõ ràng đây là vấn đề vì Chrome đã xử lý và chấp nhận chứng chỉ mặc dù đã bỏ các chứng chỉ trung gian và gốc.

Sau khi đóng gói chứng chỉ, mọi thứ hoạt động như mong đợi. Tôi đã bó như thế này

$ cat intermediate.crt >> domain.crt

Và lặp đi lặp lại cho tất cả các chứng chỉ trung gian và gốc.

— Daniel Watky
nguồn
2
Tôi đã gặp một vấn đề tương tự, ngoại trừ tôi đã không đặt Apache SSLCertertChainFile của mình thành đúng chứng chỉ.
— Wayne Piekarski
1
Lưu ý rằng nếu bạn làm điều này và crt bạn đang thêm không có dòng mới, thì bạn sẽ có các dòng như -----END CERTIFICATE----------BEGIN CERTIFICATE-----trong gói của mình và bạn sẽ gặp lỗi tối nghĩa:curl: (77) error setting certificate verify locations
— Marty Neal
2
Tôi đang sử dụng chứng chỉ letencrypt nhưng chỉ triển khai chứng chỉ và khóa riêng cho máy chủ. Chrome và cuộn tròn trên máy tính của tôi đã không phàn nàn, tuy nhiên một ứng dụng nodejs mà tôi đang xây dựng không chấp nhận chứng chỉ. Việc triển khai fullchain đến máy chủ đã khắc phục sự cố! Cảm ơn bạn đã chỉ đúng hướng!
— Paulo Santos
Trong trường hợp của tôi (chứng chỉ từ comodo), họ đã gửi chứng chỉ trung gian dưới dạng my-domain.ca-bundle. Tôi đã phải nối nó với my-domain.crt. Cảm ơn!
— Jon Hulka
18

Đối với tôi, cài đặt chứng chỉ đơn giản đã giúp:

sudo apt-get install ca-certificates
— Maxim Krušina
nguồn
2
Ví dụ, một số container docker nhỏ có thể không được cài đặt này và không có điểm nào gây rắc rối cho bất cứ điều gì khác khi toàn bộ gói không có mặt.
— muni764
16

Có vấn đề này sau khi cài đặt Git Tiện ích mở rộng v3.48. Đã thử cài đặt mysysgit một lần nữa nhưng cùng một vấn đề. Cuối cùng, phải vô hiệu hóa (vui lòng xem xét ý nghĩa bảo mật!) Xác minh Git SSL với:

git config --global http.sslVerify false

nhưng nếu bạn có chứng chỉ miền tốt hơn hãy thêm nó vào (Win7)

C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
— Riga
nguồn
23
Hoạt động, nhưng cảm giác như che giấu triệu chứng, không chữa khỏi bệnh.
— MonoThreaded 10/2/2015
4
Vô hiệu hóa xác minh SSL là rất nguy hiểm
— jonasl
1
Bạn có thể làm mà không --globalcó SSL chỉ bị vô hiệu hóa cho kho lưu trữ nơi bạn gặp sự cố. Xem nhóm.google.com/forum/#!topic/git- for- windows/mlqn5J4OLlw để thảo luận về các tệp crt cần thiết hiện tại.
— koppor
13

Chúng tôi đã gặp phải lỗi này gần đây. Hóa ra nó có liên quan đến chứng chỉ gốc không được cài đặt trong thư mục lưu trữ CA đúng cách. Tôi đã sử dụng một lệnh curl nơi tôi đang chỉ định trực tiếp CA dir. curl --cacert /etc/test/server.pem --capath /etc/test ...Lệnh này đã thất bại mỗi lần với curl: (60) Vấn đề chứng chỉ SSL: không thể có được chứng chỉ nhà phát hành địa phương.

Sau khi sử dụng strace curl ..., người ta đã xác định rằng curl đang tìm kiếm tệp chứng chỉ gốc với tên là 60ff2731.0, dựa trên một tham chiếu đặt tên băm openssl. Vì vậy, tôi tìm thấy lệnh này để nhập chứng chỉ gốc đúng cách:

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

tạo ra một liên kết mềm

60ff2731.0 -> rootcert.pem

curl, dưới vỏ bọc đọc cert.pem cert, xác định tên của tệp chứng chỉ gốc (rootcert.pem), chuyển đổi nó thành tên băm của nó, sau đó thực hiện tra cứu tệp OS, nhưng không thể tìm thấy nó.

Vì vậy, việc thực hiện là, sử dụng strace khi chạy curl khi lỗi curl bị che khuất (là một trợ giúp rất lớn), và sau đó hãy chắc chắn cài đặt đúng chứng chỉ gốc bằng cách sử dụng quy ước đặt tên openssl.

— lập trình viên
nguồn
2
Phew, nó đã giúp. Để giải thích một chút điều gì đã giúp tôi: a) chạy strace curl ... b) tìm kiếm stat () với cái gì đó-hex.0 c) googled cho cái gì đó hex, tìm thấy chứng chỉ tương ứng d) đặt chứng chỉ tìm thấy vào / usr / local / share / ca-cert / (với phần mở rộng * .crt, vì * .pem không hoạt động) e) chạy update-ca-chứng chỉ. Rồi chơi lô tô! - symlink cần thiết đã được tạo tự động trong / usr / lib / ssl / certs /
— No-Bugs Hare
11

Nó rất có thể là một chứng chỉ bị thiếu từ máy chủ.

Root-> Trung cấp-> Máy chủ

Một máy chủ nên gửi tối thiểu Máy chủ & Trung gian.

Sử dụng openssl s_client -showcerts -starttls ftp -crlf -connect abc:21để gỡ lỗi vấn đề.

Nếu chỉ có một chứng nhận được trả lại (tự ký hoặc được cấp), thì bạn phải chọn một trong hai:

  1. đã sửa máy chủ
  2. tin tưởng chứng chỉ đó và thêm nó vào cửa hàng chứng chỉ CA của bạn (không phải ý tưởng tốt nhất)
  3. vô hiệu hóa lòng tin, vd curl -k(ý tưởng rất tệ)

Nếu máy chủ trả về, nhiều hơn một, nhưng không bao gồm chứng chỉ tự ký (root):

  1. cài đặt chứng chỉ CA (root) trong cửa hàng CA của bạn cho chuỗi này, ví dụ: google nhà phát hành. ( CHỈ nếu bạn tin tưởng CA đó)
  2. đã sửa máy chủ để gửi CA như một phần của chuỗi
  3. tin tưởng một chứng chỉ trong chuỗi
  4. vô hiệu hóa niềm tin

Nếu máy chủ trả về chứng chỉ CA gốc, thì nó không có trong cửa hàng CA của bạn, các tùy chọn của bạn là:

  1. Thêm (tin tưởng) nó
  2. vô hiệu hóa niềm tin

Tôi đã bỏ qua các certs đã hết hạn / bị thu hồi vì không có tin nhắn nào cho biết điều đó. Nhưng bạn có thể kiểm tra các certs vớiopenssl x509 -text

Cho rằng bạn đang kết nối với phiên bản gia đình ( https://www.cerberusftp.com/support/help/installing-a-cert ve / ) máy chủ ftp, tôi sẽ nói rằng nó là tự ký.

Vui lòng gửi thêm chi tiết, như đầu ra từ openssl.

— Jason Pyeron
nguồn
6

Theo tài liệu cURL, bạn cũng có thể truyền chứng chỉ cho curllệnh:

Nhận chứng chỉ CA có thể xác minh máy chủ từ xa và sử dụng tùy chọn phù hợp để chỉ ra chứng chỉ CA này để xác minh khi kết nối. Đối với libcurltin tặc:curl_easy_setopt(curl, CURLOPT_CAPATH, capath);

Với công cụ dòng lệnh curl: --cacert [file]

Ví dụ: 

curl --cacert mycertificate.cer -v https://www.stackoverflow.com
— Giorgos Myrianthous
nguồn
5

Chỉ cần cập nhật danh sách chứng chỉ là đủ.

sudo update-ca-certificates -f

update-ca-cert là chương trình cập nhật thư mục / etc / ssl / certs để giữ chứng chỉ SSL và tạo ca-cert.crt, một danh sách chứng chỉ tập tin đơn được ghép nối.

— Michael P. Bazos
nguồn
đã làm nó và mọi thứ được thực hiện sau khi chạy nó. Nhưng curl không hoạt động. vẫn cùng một lỗi.
— AGamePlayer
1
Tôi đã chỉ huy, và nó không giúp được gì, và tôi không thể tin rằng tôi phải làm mọi thứ ở trên. Và sau đó là câu trả lời của bạn ... Cảm ơn lá cờ '-f'.
— Alex Shtromberg
1
Đây là giải pháp tôi đã đến là tốt. +1
— SS Anne
3

Hãy thử cài đặt lại curl trong Ubuntu và cập nhật certs CA của tôi với sudo update-ca-certificates --freshcập nhật certs

— Ankit Singh
nguồn
2

Trên cửa sổ tôi đã gặp vấn đề này. Curl đã được cài đặt bởi mysysgit, vì vậy việc tải xuống và cài đặt phiên bản mới nhất đã khắc phục sự cố của tôi.

Nếu không, đây là những hướng dẫn hợp lý về cách cập nhật chứng chỉ CA mà bạn có thể thử.

— Steve
nguồn
2

Có, bạn cần phải thêm một chứng chỉ CA. Thêm một đoạn mã trong Node.js để xem rõ ràng.

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)
— Ravi Prakash
nguồn
2

Tôi đã gặp vấn đề này là tốt. Tôi đã đọc chủ đề này và hầu hết các câu trả lời là thông tin nhưng quá phức tạp đối với tôi. Tôi không có kinh nghiệm trong các chủ đề mạng nên câu trả lời này dành cho những người như tôi.

Trong trường hợp của tôi, lỗi này xảy ra do tôi không bao gồm chứng chỉ trung gian và chứng chỉ gốc bên cạnh chứng chỉ tôi đang sử dụng trong ứng dụng của mình.

Đây là những gì tôi nhận được từ nhà cung cấp chứng chỉ SSL:

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

Trong abc.crttệp, chỉ có một chứng chỉ:

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

Nếu tôi cung cấp nó ở định dạng này, trình duyệt sẽ không hiển thị bất kỳ lỗi nào (Firefox) nhưng tôi sẽ gặp curl: (60) SSL certificate : unable to get local issuer certificatelỗi khi tôi thực hiện yêu cầu cuộn tròn.

Để khắc phục lỗi này, hãy kiểm tra abc-bunde.crttệp của bạn . Bạn rất có thể sẽ thấy một cái gì đó như thế này:

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

Đây là chứng chỉ trung cấp và gốc của bạn. Xảy ra lỗi vì chúng bị thiếu trong chứng chỉ SSL mà bạn đang cung cấp cho ứng dụng của mình.

Để khắc phục lỗi, kết hợp nội dung của cả hai tệp này theo định dạng này:

-----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-----

Lưu ý rằng không có khoảng trắng giữa các chứng chỉ, ở cuối hoặc ở đầu tệp. Khi bạn cung cấp chứng chỉ kết hợp này cho ứng dụng của mình, vấn đề của bạn sẽ được khắc phục.

— Eorekan
nguồn
1

Trường hợp của tôi thì khác. Tôi đang lưu trữ một trang web đằng sau tường lửa. Lỗi được gây ra bởi pfSense.

Network layout: |Web Server 10.x.x.x| <-> |pfSense 49.x.x.x| <-> |Open Internet|

Tôi vô tình tìm ra nguyên nhân, nhờ câu trả lời này .

Tất cả đều ổn khi tôi truy cập trang web của mình từ mạng WAN.

Tuy nhiên, khi trang web được truy cập từ bên trong mạng LAN (ví dụ: khi Wordpress đưa ra curlyêu cầu đến máy chủ của chính nó, mặc dù sử dụng IP WAN 49.x.x.x), nó đã được phục vụ trang đăng nhập pfSense.

Tôi xác định giấy chứng nhận là pfSense webConfigurator Self-Signed Certificate. Không có thắc mắc curlđã ném một lỗi.

Nguyên nhân: Điều gì đã xảy ra là việc curlsử dụng địa chỉ IP WAN của trang web 49.x.x.x. Nhưng, trong bối cảnh của máy chủ web, mạng IP IP là tường lửa.

Gỡ lỗi: Tôi thấy rằng tôi đã nhận được chứng chỉ pfSense.

Giải pháp: Trên máy chủ lưu trữ trang web, hãy trỏ tên miền của chính nó tới 127.0.0.1

Bằng cách áp dụng giải pháp, curlyêu cầu của máy chủ web đã được xử lý đúng cách và không được chuyển tiếp đến tường lửa phản hồi bằng cách gửi trang đăng nhập.

— PNDA
nguồn
0

Đây là vấn đề cửa hàng chứng chỉ ssh. Bạn cần tải xuống tệp pem chứng chỉ hợp lệ từ trang web CA đích, sau đó xây dựng tệp liên kết mềm để hướng dẫn ssl chứng chỉ tin cậy.

openssl x509 -hash -noout -in DigiCert_Global_Root_G3.pem

bạn sẽ nhận được dd8e9d41

xây dựng liên kết solf với số băm và hậu tố tệp có dấu .0 (dấu chấm 0)

dd8e9d41.0

Sau đó thử lại.

— roger
nguồn
0

  1. Tải xuống https://curl.haxx.se/ca/cacert.pem

  2. Sau khi tải xuống, di chuyển tệp này đến máy chủ wamp của bạn.

    Đối với exp: D: \ wamp \ bin \ php \

  3. Sau đó thêm dòng sau vào tệp php.ini ở phía dưới.

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

  1. Bây giờ khởi động lại máy chủ wamp của bạn.
— cát kumar
nguồn
0

Bạn phải thay đổi máy chủ cert từ cert.pemđể fullchain.pem
tôi có cùng một vấn đề với Perl HTTPS Daemon:
Tôi đã thay đổi:
SSL_cert_file => '/etc/letsencrypt/live/mydomain/cert.pem'
đến:
SSL_cert_file => '/etc/letsencrypt/live/mydomain/fullchain.pem'

— k-messaoudi
nguồn
-1

Cho đến nay, tôi đã thấy vấn đề này xảy ra trong các mạng công ty vì hai lý do, một hoặc cả hai có thể xảy ra trong trường hợp của bạn:

  1. Do cách thức hoạt động của proxy mạng , họ có chứng chỉ SSL riêng, do đó thay đổi chứng chỉ mà curl nhìn thấy. Nhiều hoặc hầu hết các mạng doanh nghiệp buộc bạn phải sử dụng các proxy này.
  2. Một số chương trình chống vi-rút chạy trên PC khách cũng hoạt động tương tự như proxy HTTPS, để chúng có thể quét lưu lượng mạng của bạn. Chương trình chống vi-rút của bạn có thể có tùy chọn để tắt chức năng này (giả sử quản trị viên của bạn sẽ cho phép).

Là một lưu ý phụ, số 2 ở trên có thể khiến bạn cảm thấy khó chịu về lưu lượng truy cập TLS được cho là an toàn của bạn đang được quét. Đó là thế giới doanh nghiệp dành cho bạn.

— lần thứ nhất
nguồn
-1

Có vấn đề đó và nó đã không được giải quyết với phiên bản mới hơn. / etc / certs đã có chứng chỉ gốc, trình duyệt cho biết mọi thứ đều ổn. Sau một số thử nghiệm tôi nhận được từ ssllabs.com cảnh báo, chuỗi của tôi chưa hoàn thành (Quả thực đó là chuỗi cho chứng chỉ cũ chứ không phải chuỗi mới). Sau khi sửa chuỗi cert, mọi thứ đều ổn, ngay cả với curl.

— Frank
nguồn
-1

Tôi gặp vấn đề này với Digicert của tất cả các CA. Tôi đã tạo một tệp digicertca.pem chỉ là trung gian và gốc được dán cùng nhau thành một tệp.

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: */*
...

Eorekan đã có câu trả lời nhưng chỉ có tôi và một người khác bỏ phiếu trả lời.

— Kirt Carson
nguồn
-2

Cụ thể cho Windowsngười dùng, sử dụng curl-7.57.0-win64-mingwhoặc phiên bản tương tự.

Điều này hơi muộn và các câu trả lời hiện có là chính xác. Nhưng tôi vẫn phải đấu tranh một chút để nó hoạt động trên máy Windows của mình, mặc dù quá trình này thực sự khá đơn giản. Vì vậy, chia sẻ quá trình từng bước.

Lỗi này về cơ bản có nghĩa là, curl không xác minh được chứng chỉ của URI đích. Nếu bạn tin tưởng nhà phát hành chứng chỉ (CA), bạn có thể thêm nó vào danh sách chứng chỉ tin cậy.

Để làm điều đó, hãy duyệt URI (ví dụ: trên Chrome) và làm theo các bước

  1. Nhấp chuột phải vào biểu tượng ổ khóa an toàn
  2. Bấm vào chứng chỉ, nó sẽ mở một cửa sổ với các chi tiết chứng chỉ
  3. Chuyển đến tab 'Đường dẫn chứng nhận'
  4. Nhấp vào chứng chỉ ROOT
  5. Nhấp vào Xem chứng chỉ, nó sẽ mở một cửa sổ chứng chỉ khác
  6. Chuyển đến tab Chi tiết
  7. Nhấp vào Sao chép vào tệp, nó sẽ mở trình hướng dẫn xuất khẩu
  8. Nhấn tiếp
  9. Chọn 'Base-64 được mã hóa X.509 (.CER)'
  10. Nhấn tiếp
  11. Đặt tên thân thiện, ví dụ: 'MyDomainX.cer' (duyệt đến thư mục mong muốn)
  12. Nhấn tiếp
  13. Nhấp vào Kết thúc, nó sẽ lưu tệp chứng chỉ
  14. Bây giờ hãy mở .certệp này và sao chép nội dung (bao gồm ----- BEGIN CHỨNG NHẬN ----- và ----- KẾT THÚC KẾT THÚC -----)
  15. Bây giờ đi đến thư mục curl.exeđược lưu, ví dụC:\SomeFolder\curl-7.57.0-win64-mingw\bin
  16. Mở curl-ca-bundle.crttệp bằng trình soạn thảo văn bản
  17. Nối văn bản chứng chỉ đã sao chép vào cuối tệp. Tiết kiệm

Bây giờ lệnh của bạn sẽ thực hiện tốt trong curl.

— Arghya C
nguồn
3
Một số nhận xét về lý do downvote sẽ được đánh giá cao
— Arghya C
Tôi không tìm thấy bất kỳ tệp nào có tên "curl-ca-bundle.crt" trong "C: \ xampp \ apache \ bin" (windows). Đoán số phiếu giảm là do điều này. Tôi có "curl.exe" trong thư mục "bin" được đề cập ở trên
— kathikeyan A
-4

điều này có thể giúp bạn đoán 

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

đã thử nghiệm trên guồng / guin 3. *

— fico7361
nguồn
-5

Giải pháp đơn giản: IN ~/.sdkman/etc/config, thay đổisdkman_insecure_ssl=true

Các bước: thay đổi
nano để lưu và thoát~/.sdkman/etc/config
sdkman_insecure_ssl=falsesdkman_insecure_ssl=true

— biniam
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.