Tôi đang gặp lỗi NSS error -12286khi tải xuống tệp từ HTTPS curl.
Tôi có thể tải xuống cùng một tệp mà không gặp sự cố khi sử dụng wgetvì vậy tôi có thể loại trừ mọi sự cố về tường lửa hoặc danh sách đen.
Đã thử, không có may mắn, các tùy chọn -kvà --cipher ecdhe_ecdsa_aes_128_gcm_sha_256, đó là mật mã ưa thích của máy chủ theo công cụ Máy chủ thử nghiệm SSL của Qualys tại đây: https://www.ssllabs.com/ssltest/analyze.html?d=intribunale.net&latest
Đây là cURLnhật ký:
# curl -v https://www.intribunale.net/immobili
* About to connect() to www.intribunale.net port 443 (#0)
* Trying 104.27.150.214... connected
* Connected to www.intribunale.net (104.27.150.214) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* NSS error -12286
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
Phiên bản lib của tôi là:
# curl -V
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
Tôi có thể tái tạo vấn đề của bạn với CentOS6.7 curl-7.19.7-46.el6 nss-3.21.0-0.3.el6_7 đến một máy chủ thử nghiệm. Theo mặc định, nó không cung cấp bất kỳ bộ ECC nào và vì máy chủ của bạn (Cloudfare) chỉ chấp nhận đàm phán bộ ECC (cụ thể là ECDHE) không thành công. Với
—
dave_thndry_085
--cipher[s]việc chỉ định bộ ECDHE, nó thậm chí không gửi ClientHello, chỉ đóng kết nối và báo lỗi. Điều này dường như là một cái gì đó không đồng bộ trong nội bộ, có lẽ sau khi từ chối ECC lâu dài của RedHat. RedHat wget sử dụng OpenSSL và RedHat OpenSSL gần đây không hỗ trợ ECC (chỉ với P256 P384 P521 nhưng điều đó là đủ ở đây).
Lựa chọn đầu tiên của tôi sẽ là (0) không sử dụng (này) curl, nhưng nếu bạn thực sự muốn các tùy chọn tôi thấy là: (1) nếu bạn có hỗ trợ, hãy báo cáo đó là một lỗi và hy vọng họ sẽ sửa nó. (2) đó là nguồn mở; gỡ lỗi và tự sửa nó. (3) nó là nguồn mở; xây dựng lại chống lại openssl (thay vì NSS) sẽ hoạt động. (4) thiết lập
—
dave_thndry_085
stunnel(sử dụng openssl) dưới dạng SSL đơn giản, nói với curl http(notS)://localhost[:port]/whatevernhưng thêm -H "Host: realhost"để máy chủ mục tiêu không thể phân biệt được. ...
... (5) tương tự nhưng chính thức hơn: thiết lập proxy HTTP thực bằng cách sử dụng openssl tại đây hoặc bất kỳ SSL / TLS tương thích TLS1.2-ECDHE nào trên hệ thống khác trong điều khiển của bạn, thậm chí có thể là VM trên máy thật của bạn, như HAproxy hoặc nginx hoặc thậm chí httpd, mà bạn kết nối với HTTP đơn giản hoặc ít nhất là HTTPS không phải ECDHE nhưng chuyển tiếp đến máy chủ thực với HTTPS ECDHE tốt.
—
dave_thndry_085
NSS ngược dòng chắc chắn hỗ trợ ECDHE trong một thời gian dài. RedHat trong nhiều năm cho đến cuối năm 2014 đã loại bỏ (tất cả các biến thể) ECC khỏi các gói xây dựng của họ (AFAIK, chắc chắn là OpenSSL NSS OpenJDK) vì những lý do mơ hồ 'mà tôi gọi là' từ chối dài '. Tôi đoán khi họ đặt nó trở lại, họ đã phạm một số lỗi nhỏ có thể ảnh hưởng đến trường hợp curl / NSS này. Tôi không biết bất kỳ bản phân phối nào khác đã làm điều này, nhưng có rất nhiều và ai đó có thể; trong một Ubuntu tôi hiện có, 14.04LTS Trusty, curl sử dụng OpenSSL và không hỗ trợ ECDHE.
—
dave_thndry_085
SSL_ERROR_NO_CYPHER_OVERLAP"Không thể giao tiếp an toàn với ngang hàng: không có thuật toán mã hóa chung." Các hệ thống cục bộ và từ xa chia sẻ không có bộ mật mã chung. Điều này có thể là do cấu hình sai ở một trong hai đầu. Có thể do máy chủ bị định cấu hình sai khi sử dụng chứng chỉ không phải RSA với thuật toán trao đổi khóa RSA.