Curl: Sửa lỗi SSL CURL (51): không có tên chủ đề chứng chỉ thay thế nào phù hợp


87

Tôi mới làm quen với thế giới CURL, đến từ miền Windows + .NET.

Đang cố gắng truy cập API Rest để xác thực cơ bản tại http://www.evercam.io/docs/api/v1/authentication .

curl -X GET https://api.evercam.io/v1/... \
-u {username}

Không biết cách sử dụng lệnh này trên dấu nhắc lệnh của windows sau khi thiết lập CURL thành công. Đã kiểm tra CURL như sau:

C:\>curl --version
curl 7.33.0 (x86_64-pc-win32) libcurl/7.33.0 OpenSSL/0.9.8y zlib/1.2.8 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp s
ftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate Largefile NTLM SSL SSPI libz

Bây giờ tôi đang kết thúc với điều này

C:\>curl -u myuser:mypassword -X GET https://api.evercam.io/v1/
curl: (51) SSL: no alternative certificate subject name matches target host name 'api.evercam.io'

Làm cách nào để khắc phục lỗi SSL sự cố 51 này?

Câu trả lời:


113

Nó thường xảy ra khi chứng chỉ không khớp với tên máy chủ.

Giải pháp sẽ là liên hệ với máy chủ lưu trữ và yêu cầu máy chủ sửa chứng chỉ của nó.
Nếu không, bạn có thể tắt xác minh chứng chỉ của cURL, sử dụng tùy chọn -k(hoặc --insecure).
Xin lưu ý rằng như tùy chọn đã nói, nó không an toàn . Bạn không nên sử dụng tùy chọn này vì nó cho phép tấn công kẻ trung gian và đánh bại mục đích của HTTPS.

Có thể tìm thấy thêm tại đây: http://curl.haxx.se/docs/sslcerts.html


10
Các câu trả lời nói để tắt kiểm tra, cũng nên làm nổi bật hậu quả là gì. Điều này nguy hiểm!
DrP3pp3r

1
Điều mà tôi đã tìm là tên chủ đề trên cert *.my-domain.comkhông áp dụng cho dev.subdomain.my-domain.com. Nhưng hoạt động tốt cho dev-subdomain.my-domain.com. Vì vậy, để làm cho nhiều miền phụ hoạt động có thể bạn cần những gì bài viết này nói - sslshopper.com/…
Prayagupd

76

Lưu ý của người biên tập: đây là một cách tiếp cận rất nguy hiểm, nếu bạn đang sử dụng phiên bản PHP đủ cũ để sử dụng nó. Nó mở mã của bạn trước các cuộc tấn công man-in-the-middle và loại bỏ một trong những mục đích chính của kết nối được mã hóa. Khả năng thực hiện việc này đã bị loại bỏ khỏi các phiên bản PHP hiện đại vì nó rất nguy hiểm. Lý do duy nhất mà điều này đã được ủng hộ 70 lần là vì mọi người lười biếng. KHÔNG LÀM ĐIỀU NÀY.


Tôi biết đó là một câu hỏi (rất) cũ và đó là về dòng lệnh, nhưng khi tôi tìm kiếm trên Google cho "SSL: không có tên chủ đề chứng chỉ thay thế nào khớp với tên máy chủ mục tiêu", đây là lần truy cập đầu tiên.

Tôi đã mất một khoảng thời gian để tìm ra câu trả lời vì vậy hy vọng điều này sẽ giúp ai đó tiết kiệm được nhiều thời gian! Trong PHP, hãy thêm cái này vào setopts cUrl của bạn:

curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, FALSE);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, FALSE);

ps: đây nên là một giải pháp tạm thời. Vì đây là lỗi chứng chỉ, điều tốt nhất là bạn nên sửa chứng chỉ!


30
Điều này xuất hiện trong tìm kiếm trên google của tôi cho vấn đề tôi gặp phải trong PHP, vì vậy điều này rất hữu ích cho tôi.
Gujamin

1
Tôi đã thực hiện cùng một tìm kiếm và tôi rất vui khi có câu trả lời của bạn ở đây. Cảm ơn!
CptMisery

2
CURLOPT_SSL_VERIFYHOSTtrong trường hợp của tôi là đủ
1234ru

Cảm ơn hữu ích cho mục đích thử nghiệm nếu bạn chưa có chứng chỉ của mình.
Andrew

20

Tên thông dụng trong chứng chỉ dành api.evercam.iocho *.herokuapp.comvà không có tên chủ thể thay thế nào trong chứng chỉ. Điều này có nghĩa là chứng chỉ cho api.evercam.iokhông khớp với tên máy chủ và do đó việc xác minh chứng chỉ không thành công. Tương tự như đúng đối với www.evercam.io, ví dụ: thử https://www.evercam.io bằng trình duyệt và bạn nhận được thông báo lỗi, rằng tên trong chứng chỉ không khớp với tên máy chủ.

Vì vậy, đó là một vấn đề cần được khắc phục bởi evercam.io. Nếu bạn không quan tâm đến bảo mật, các cuộc tấn công man-in-the-middle, v.v. bạn có thể vô hiệu hóa xác minh chứng chỉ ( curl --insecure), nhưng sau đó bạn nên tự hỏi tại sao bạn lại sử dụng https thay vì http.


3

nó có thể tiết kiệm thời gian cho ai đó.

Nếu bạn sử dụng GuzzleHttp và gặp phải thông báo lỗi này cURL error 60: SSL: không có tên chủ đề chứng chỉ thay thế nào khớp với tên máy chủ đích và bạn ổn với giải pháp 'không an toàn' (không được khuyến nghị trên sản xuất) thì bạn phải thêm \GuzzleHttp\RequestOptions::VERIFY => falsevào ứng dụng khách cấu hình:

$this->client = new \GuzzleHttp\Client([
    'base_uri'                          => 'someAccessPoint',
    \GuzzleHttp\RequestOptions::HEADERS => [
        'User-Agent' => 'some-special-agent',
    ],
    'defaults'                          => [
        \GuzzleHttp\RequestOptions::CONNECT_TIMEOUT => 5,
        \GuzzleHttp\RequestOptions::ALLOW_REDIRECTS => true,
    ],
    \GuzzleHttp\RequestOptions::VERIFY  => false,
]);

đặt CURLOPT_SSL_VERIFYHOSTthành 0 và CURLOPT_SSL_VERIFYPEERsai trong CurlFactory::applyHandlerOptions()phương thức

$conf[CURLOPT_SSL_VERIFYHOST] = 0;
$conf[CURLOPT_SSL_VERIFYPEER] = false;

Từ tài liệu GuzzleHttp

kiểm chứng

Mô tả hành vi xác minh chứng chỉ SSL của một yêu cầu.

  • Đặt thành true để bật xác minh chứng chỉ SSL và sử dụng gói CA mặc định> do hệ điều hành cung cấp.
  • Đặt thành false để tắt xác minh chứng chỉ (điều này không an toàn!).
  • Đặt thành chuỗi để cung cấp đường dẫn đến gói CA để cho phép xác minh bằng chứng chỉ tùy chỉnh.

0

Như mã lỗi cho biết, "không có tên chủ đề chứng chỉ thay thế nào khớp với tên máy chủ đích" - do đó, chứng chỉ SSL đã xảy ra sự cố.

Chứng chỉ phải bao gồm SAN và chỉ SAN mới được sử dụng. Một số trình duyệt bỏ qua Tên chung không dùng nữa.

RFC 2818 nêu rõ "Nếu có phần mở rộng SubjectAltName của loại dNSName, thì PHẢI được sử dụng làm danh tính. Nếu không, trường Tên chung (cụ thể nhất) trong trường Chủ đề của chứng chỉ PHẢI được sử dụng. Mặc dù việc sử dụng Tên chung Tên là phương pháp hiện có, nó không được dùng nữa và Tổ chức phát hành chứng nhận được khuyến khích sử dụng dNSName để thay thế. "


0

Tôi gặp vấn đề tương tự. Trong trường hợp của tôi, tôi đang sử dụng digitalocean và nginx.
Trước tiên, tôi đã thiết lập miền example.app và miền phụ dev.exemple.app trong digitalocean. Thứ hai, tôi đã mua hai chứng chỉ ssl từ godaddy. Và finaly, tôi đã định cấu hình hai miền trong nginx để sử dụng hai chứng chỉ ssl đó với đoạn mã sau

Cấu hình miền example.app của tôi

    server {
    listen 7000 default_server;
    listen [::]:7000 default_server;

     listen 443 ssl default_server;
     listen [::]:443 ssl default_server;

    root /srv/nodejs/echantillonnage1;

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;

    server_name echantillonnage.app;
    ssl_certificate /srv/nodejs/certificatSsl/widcardcertificate/echantillonnage.app.chained.crt;
    ssl_certificate_key /srv/nodejs/certificatSsl/widcardcertificate/echantillonnage.app.key;

    location / {
            # First attempt to serve request as file, then
            # as directory, then fall back to displaying a 404.
            proxy_pass http://127.0.0.1:8090;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
    #try_files $uri $uri/ =404;
    }
 }

Dev.example.app của tôi

   server {
    listen 7000 default_server;
    listen [::]:7000 default_server;

     listen 444 ssl default_server;
     listen [::]:444 ssl default_server;

    root /srv/nodejs/echantillonnage1;

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;

    server_name dev.echantillonnage.app;
    ssl_certificate /srv/nodejs/certificatSsl/dev/dev.echantillonnage.app.chained.crt;
    ssl_certificate_key /srv/nodejs/certificatSsl/dev/dev.echantillonnage.app.key;

    location / {
            # First attempt to serve request as file, then
            # as directory, then fall back to displaying a 404.
            proxy_pass http://127.0.0.1:8091;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
    #try_files $uri $uri/ =404;
    }
 }

Khi tôi khởi chạy https://dev.echantillonnage.app , tôi đã nhận được

    Fix CURL (51) SSL error: no alternative certificate subject name matches

Sai lầm của tôi là hai dòng dưới đây

    listen 444 ssl default_server;
     listen [::]:444 ssl default_server;

Tôi đã phải thay đổi điều này thành:

     listen 443 ssl;
     listen [::]:443 ssl;
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 cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.