Làm cách nào để khiến Gnu / Linux tin tưởng một chứng chỉ được Windows tin cậy?

Có một máy chủ với chuỗi SSL bị hỏng, như báo cáo của kiểm tra SSL này :

Tôi biết đây là một vấn đề cần được giải quyết trên chính máy chủ, nhưng đôi khi điều này khó khắc phục (tôi không phải là quản trị viên của máy chủ).

Vấn đề là, Chrome / Mozilla / Edge trên Windows vẫn tin tưởng chứng chỉ trang web :

Tuy nhiên, trong triển khai Gnu / Linux (Ubuntu 18.04 trong Docker), chứng chỉ không được tin cậy:

curl: (60) SSL certificate problem: unable to get local issuer certificate

Tôi đã thử update-ca-certificatesvà thậm chí nhập chứng chỉ Globalsign Root. update-ca-certificatesbáo cáo một chứng chỉ trùng lặp trong trường hợp đó. Dù sao, không có gì hoạt động.

Cách sinh sản

Sử dụng Docker:

docker run -it ubuntu:18.04

# within container:
apt-get update
apt-get -y install curl
curl https://betriebsheft.vog.it  # <---- "unable to get local issuer certificate"

Làm cách nào tôi có thể khiến Gnu / Linux tin tưởng chứng chỉ này?

PS: Chứng chỉ tương tự được triển khai chính xác trên máy chủ khác .

— Udo G
nguồn

Tại sao các downvote?

— Udo G

Tôi đang bỏ phiếu để đóng câu hỏi này ngoài chủ đề vì OP đang hỏi điều gì đó mà anh ta không thể ảnh hưởng đến mình. Anh ấy nói anh ấy không thể sửa đổi bất cứ thứ gì phía máy chủ , vì vậy đây có lẽ thuộc về siêu người dùng, vì nó mô tả một vấn đề không có phía khách hàng giải pháp.

— LinuxSecurityFreak

Tôi đặc biệt yêu cầu một giải pháp phía khách hàng . Tôi không thể ảnh hưởng đến máy chủ, nhưng tôi có toàn quyền kiểm soát O / S của khách hàng (Ubuntu) và tôi muốn cài đặt O / S cụ thể này tin tưởng vào chứng chỉ giống như các O / S (Windows) khác. Đây không phải là về việc sửa trang web HTTPS cho người khác.

— Udo G

Câu hỏi là về việc sử dụng / quản trị hệ thống * nix và các ứng dụng được đóng gói trong đó

— Udo G

Bạn không kiểm soát máy chủ, nhưng bạn vẫn có thể báo cáo sự cố cho người kiểm soát máy chủ.

— Michael Hampton

Cách khắc phục thực sự cho việc này là đảm bảo rằng máy chủ của bạn xuất trình tất cả các chứng chỉ trong chuỗi chứ không chỉ chứng chỉ thực thể cuối (máy chủ).

Trỏ quản trị viên máy chủ của bạn tới RFC 5246 Mục 7.4.2 , trong đó nêu rõ rằng Thông báo này truyền chuỗi chứng chỉ của máy chủ cho khách hàng.

Nếu quản trị viên của bạn từ chối / không thể làm điều này vì một số lý do, tùy chọn thay thế của bạn là thử và bắt curlđầu làm việc với cái bắt tay không đúng định dạng.

Theo một tin nhắn trong danh sách gửi thư Curl:

Ai đó có thể xác nhận nếu cURL hỗ trợ (hoặc không) chứng chỉ trung gian không?

Có nó làm. Tất cả các chứng chỉ ca có một chuỗi chứng chỉ đi lên đến gốc. Các gói ca bạn sử dụng với curl cần bao gồm các certs cho toàn bộ chuỗi.

/ daniel.haxx.se

Bạn sẽ có thể thêm Root CA và tất cả các chứng chỉ trung gian vào một gói và trỏ curlđến nó bằng --cacert <file>tùy chọn.

Khi trình duyệt của bạn hoạt động, bạn có thể truy cập các chứng chỉ CA chính xác từ đó. Trên tab chứng chỉ (khác nhau cho từng trình duyệt, nhưng tôi chắc chắn bạn sẽ tìm ra cái đó), xem chuỗi chứng chỉ. Nhấp đúp vào Root CA đầu tiên GlobalSign Root CA - G1 và trên chi tiết tab, bấm vào Sao chép tập tin ... . Lưu nó như root.cer. Làm tương tự với AlphaSSL CA - SHA256 - G2 và lưu nó dưới dạng issuing.cer. Kết hợp cả hai lại với nhau trong một tệp duy nhất (ví dụ chain.cer) và sử dụng nó làm đối số -cacert.

Như @AB chỉ ra, chứng chỉ còn thiếu cũng có thể được tìm thấy ở đây .

Trình duyệt của bạn hoạt động vì chúng lưu trữ chứng chỉ CA. Nếu bạn đã điều hướng đến một trang web được định cấu hình chính xác tại một thời điểm trước đây, chứng chỉ được cấp bởi cùng một CA với chứng chỉ của máy chủ của bạn, nó sẽ được trình duyệt lưu vào bộ nhớ cache. Sau đó, khi bạn truy cập trang web được cấu hình không chính xác, trình duyệt của bạn sẽ sử dụng chứng chỉ CA trong bộ đệm của nó để xây dựng chuỗi. Đối với bạn, có vẻ như mọi thứ đều ổn, mặc dù đằng sau hậu trường, máy chủ bị cấu hình sai.

Lưu ý rằng trên Windows, IE / Edge và Chrome có chung bộ đệm, trong khi Firefox sử dụng riêng.

Ngoài các cách trên, IE / Edge và Chrome (vì chúng có chung ngăn xếp tiền điện tử) sẽ sử dụng một tiện ích mở rộng trong các chứng chỉ được gọi là AuthorIn informationAccess . Điều này có một tùy chọn caIssuer cung cấp một URL mà từ đó chứng chỉ CA của chứng chỉ thực thể cuối có thể được tải xuống. Do đó, ngay cả khi một trong những trình duyệt này không lưu các chứng chỉ bị thiếu từ trình duyệt trước đó, nó có thể tìm nạp nó nếu cần. Lưu ý rằng Firefox không làm điều này, đó là lý do tại sao đôi khi Firefox có thể hiển thị lỗi chứng chỉ khi IE / Edge và Chrome dường như hoạt động.

— garethTheRed
nguồn

Đó không phải là máy chủ của tôi, vì vậy không thể sửa đổi bất kỳ thứ gì phía máy chủ. Tôi đã thử sử dụng gói CA từ curl.haxx.se/docs/caextract.html (vì Firefox tin tưởng chứng chỉ) và chuyển nó bằng cách sử dụng --cacert cacert.pemnhưng CURL vẫn không chấp nhận chứng chỉ.

— Udo G

Đây là máy chủ của bạn. Chạy echo q | openssl s_client -showcerts -connect betriebsheft.vog.it:443và bạn sẽ chỉ thấy một chứng chỉ được trình bày bởi máy chủ của bạn. Cần có hai - chứng chỉ thực thể cuối (được trình bày) và CA phát hành - chứng chỉ Alpha SSL - SHA256 - G2. Cái sau không được gửi bởi máy chủ, nhưng nên.

— garethTheRed 23/12/18

@garethTheRed: Tôi hiểu rằng máy chủ không xuất hiện tất cả các chứng chỉ, nhưng máy chủ không thuộc quyền kiểm soát của tôi (đó là ý của tôi với "không phải máy chủ của tôi"). Tôi chỉ đang cố gắng truy cập API trên máy chủ nước ngoài. Trong Windows, không có trình duyệt nào của tôi phàn nàn về chứng chỉ, chỉ có Linux / Debian / Ubuntu.

— Udo G

@AB: cảm ơn rất nhiều! Cài đặt tất cả các chứng chỉ gốc từ trang đó đã giải quyết vấn đề . Tuy nhiên, tôi muốn hiểu tại sao bước thủ công đó lại cần thiết.

— Udo G

Chứng chỉ trung gian bị thiếu (như được đề cập bởi @garethTheRed) có thể được tìm thấy ở đó: support.globalsign.com/customer/portal/articles/ Lỗi . OP ban đầu chỉ cố gắng thêm chứng chỉ gốc có lẽ đã có, do đó không đạt được gì.

— AB