OpenSSL không chọn CA trong thư mục certs

Chúng tôi gặp sự cố khi curlkhông kết nối với máy chủ HTTPS:

$ curl https://the-problem-site.com    (not the real URL!)   
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

1112 là SSL_R_TLSV1_UNRECOGNIZED_NAMEtrong ssl.h.

Nếu tôi thử openssl s_client -connect the-problem-site.com:443thay thế thì tôi thấy

CONNECTED(00000003)   
depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
verify error:num=20:unable to get local issuer certificate   
verify return:0   

Certificate chain   
0 s:/serialNumber=xx/C=xx/ST=xx/L=xxxx/O=xx/OU=xx/CN=the-problem-site.com   
i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA   

tức là có vẻ như vấn đề là nó không tin tưởng /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA. Tuy nhiên, chứng chỉ đó đã được cài đặt: nó /etc/ssl/certs/GeoTrust_Global_CA.pemvà nếu thay vào đó tôi chạy

openssl s_client -connect the-pro Hiệu-site.com:443 -CAfile /etc/ssl/certs/GeoTrust_Global_CA.pem

sau đó mọi thứ hoạt động. Chứng chỉ cũng có mặt như một tệp có tên băm b0f3e76e.0và nó nằm trong ca-certificates.crt. Tuy nhiên, theo như tôi có thể thấy, cả curl và openssl đều không cố đọc bất kỳ chứng chỉ nào; nếu tôi là stracehọ thì không có nỗ lực đọc /usr/lib/ssl/certshoặc hoàn /etc/ssl/certstoàn, thậm chí không có lỗi. Nó không đọc openssl.cnf mặc dù. Chúng tôi đã chạy update-ca-certificates.

Đây là Ubuntu 10.04 với openssl 0.9.8k. Chúng tôi có thể tái tạo vấn đề trên hai bản cài đặt riêng biệt (mặc dù có thể là bản sao của bản kia từ bản quay lại). Nếu tôi thử kiểm tra tương tự trên máy ảo CentOS với openssl 0.9.8e thì nó hoạt động tốt và tôi có thể thấy nó đang đọc tệp chứng chỉ strace. Không có quyền truy cập tệp tương đương tại cùng một điểm trong các giai đoạn Ubuntu. Nếu tôi sao chép openssl.cnftệp từ máy ảo CentOS sang máy Ubuntu thì sẽ không có gì khác biệt. Không có gì rõ ràng trong môi trường hoặc tệp .rc có thể gây ra điều này.

Bất cứ ý tưởng những gì tôi đang làm sai? Điều này có nên hoạt động không, tức là openssl và curl tự động nhận các CA đã cài đặt từ dòng lệnh? Cái này được cấu hình như thế nào? Cảm ơn!

Một điểm dữ liệu khác: trên bản cài đặt sạch của 13 máy chủ, curlkhông nhận tệp chứng chỉ và hoạt động tốt. openssl s_clientvẫn không, mặc dù. Tại sao lại như vậy?

Có một số thư viện mật mã trên hệ thống của bạn:

• OpenSSL (tiêu chuẩn vàng, với giấy phép theo kiểu BSD (rất miễn phí) bao gồm một điều khoản có chút vấn đề (ngăn chặn khả năng tương thích GPL, nhưng không có gì là xấu Bad) giới hạn việc áp dụng nó trong thế giới GNU)
• GnuTLS (thay thế từ FSF; có hai loại, được cấp phép LGPLv2 (nhưng không rõ ràng) và được cấp phép LGPLv3 (và do đó không tương thích với các chương trình chỉ có GPLv2); quá, giúp tăng cường bảo mật)
• NSS (Thư viện của Netscape / Mozilla, hiếm khi được sử dụng bên ngoài; chậm chấp nhận các tiêu chuẩn mới)
• những thứ yếu như PolarSSL, MatrixSSL, NaCl / Salt

Tất cả chúng đều có những điểm tương đồng và khác biệt. Phần mềm sử dụng chúng (cho mục đích mã hóa hoặc sử dụng SSL / TLS) đôi khi hỗ trợ sử dụng nhiều hơn một trong các thư viện này (ví dụ Lynx, trình duyệt web, thường được liên kết với OpenSSL nhưng cũng hỗ trợ GnuTLS (không tốt bằng) để xoa dịu người GNU).

cURL cũng là một trong những dự án hỗ trợ sử dụng một trong ba thư viện tiền điện tử chính. Điều này chủ yếu là vì cURL là, chính, một thư viện dự định sẽ được sử dụng bởi các chương trình khác khi họ muốn tải xuống (hoặc thậm chí tải lên) những thứ bằng cách sử dụng các kết nối http, ftp, v.v. Công curlcụ dòng lệnh có thể đến từ một trong hai biến thể này.

Bây giờ, tôi khá chắc chắn rằng vấn đề bạn gặp phải với hệ thống không được cài đặt mới là như sau:

Cả OpenSSL và GnuTLS đều hỗ trợ sử dụng các /etc/ssl/certs/<hash>.<number>thư mục CA kiểu. Tuy nhiên, OpenSSL phiên bản 0.x và GnuTLS sử dụng một thuật toán khác để tính toán hàm băm nói trên so với phiên bản OpenSSL 1.x sử dụng. (Cả hai có thể cùng tồn tại trên một hệ thống, nếu chứng chỉ khác nhau có cùng băm bạn chỉ cần sử dụng một khác nhau số cho họ Nhưng đối với một số lý do, Debian / Ubuntu. ca-certificatesGói dường như không làm được điều này.) Ngoài ra, một số phiên bản của GnuTLS không hỗ trợ sử dụng thư mục, nhưng chỉ sử dụng một tệp /etc/ssl/certs/ca-certificates.crt(thường được quản lý bởi các ca-certificatestập lệnh bảo trì của gói, nhưng có thể sai lệch); bạn dường như đang sử dụng một phiên bản cũ hơn, vì vậy đây có thể là thứ bạn nhấn.

openssl s_clienttheo mặc định (tức là không có sự -CApathhoặc -CAfiletùy chọn) không giống bất cứ nơi nào cho chứng chỉ.

Của bạn curltừ cài đặt được nâng cấp rất có thể sử dụng một thư viện tiền điện tử khác với curlcài đặt mới.

Hãy thử openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443ngoài việc openssl s_client -CApath /etc/ssl/certs -connect the-problem-site.com:443bắt chước hành vi của các phiên bản GnuTLS cũ hơn.

Kiểm tra kỹ xem có OpenSSL 1.x ở bất kỳ đâu trên hệ thống của bạn không (Ubuntu được biết là đã lén cập nhật các bản cập nhật lớn ngay cả trong các phiên bản LTS) và nếu có, hãy kiểm tra hàm băm của tệp:

openssl x509 -noout -hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash_old -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem

Thông thường, lệnh thứ hai và thứ ba sẽ thất bại (OpenSSL 0.x) hoặc lệnh thứ nhất và thứ ba sẽ hiển thị cùng một hàm băm nhưng lệnh thứ hai sẽ hiển thị một hàm băm khác nhau (OpenSSL 1.x). GnuTLS sẽ sử dụng đầu ra từ lệnh thứ hai (nếu OpenSSL 1.x được cài đặt); nếu OpenSSL 0.x được cài đặt thì cùng một hàm băm. Bạn có thể tạo các liên kết tượng trưng bằng tay.

Tôi có thể cập nhật bài đăng này khi bạn cung cấp phản hồi gỡ lỗi.