curl: (60) xác minh chứng chỉ máy chủ không thành công CRLfile: không có

Tôi đang dần chuyển đổi từ vai trò nhà phát triển độc quyền sang vai trò DevOps kết hợp nhiều hơn tại công ty của mình. Điều đó có nghĩa là tôi chưa quen với nhiều thứ này, hãy dễ dàng với tôi ... :-p

Máy chủ của khách hàng của tôi đang chạy Ubuntu 16.04, với PHP 5.6.4 và có một chức năng trong cổng quản trị trang web của họ chạy một Xoăn lệnh (về cơ bản) quay lại chính nó để đồng bộ hóa một số loại tệp. Và nó đã bị lỗi trong một thời gian (vài tuần/tháng). Vấn đề (tôi nghĩ) có phải là việc xác minh chứng chỉ không thành công và do đó, chức năng này đang chết dần chết mòn.

Khi tôi ssh vào máy chủ, tôi có thể dễ dàng di chuyển đến bất kỳ đâu mà không gặp sự cố nào (Google, example.org, v.v.). Nhưng cố gắng chỉ cuộn tròn cơ bản vào url chính của trang web những người làm công ăn lương.

$ curl -v https://www.[my-site-name].com

* Đang thử [my-site-IP]...
* Đã kết nối với [my-site-name] ([my-site-IP]) cổng 443 (#0)
* đã tìm thấy 258 chứng chỉ trong /etc/ssl/certs/ca-certificates.crt
* đã tìm thấy 908 chứng chỉ trong /etc/ssl/certs/
* ALPN, cung cấp http/1.1
* Kết nối SSL sử dụng TLS1.2/ECDHE_RSA_AES_128_GCM_SHA256
* xác minh chứng chỉ máy chủ không thành công. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Đóng kết nối 0
curl: (60) xác minh chứng chỉ máy chủ không thành công. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Thêm chi tiết tại đây: http://curl.haxx.se/docs/sslcerts.html

curl thực hiện xác minh chứng chỉ SSL theo mặc định, sử dụng "gói"
 của khóa công khai của Tổ chức phát hành chứng chỉ (CA) (chứng chỉ CA). Nếu mặc định
 tệp bó không đầy đủ, bạn có thể chỉ định một tệp thay thế
 sử dụng tùy chọn --cacert.
Nếu máy chủ HTTPS này sử dụng chứng chỉ được ký bởi một CA được đại diện trong
 gói, xác minh chứng chỉ có thể không thành công do
 vấn đề với chứng chỉ (chứng chỉ có thể đã hết hạn hoặc tên có thể
 không khớp với tên miền trong URL).
Nếu bạn muốn tắt xác minh chứng chỉ của curl, hãy sử dụng
 tùy chọn -k (hoặc --insecure).

Tôi biết rằng tôi có thể chạy curl với -k vì nó không an toàn, nhưng tôi do dự khi làm như vậy. Tôi đoán câu hỏi đầu tiên là, tôi có nên lo lắng về việc chạy cái này với cờ không an toàn vì về mặt kỹ thuật, nó hoàn toàn không rời khỏi máy chủ? Tôi đã thử nghiệm chính xác lệnh cuộn tròn này trên một trong các hộp mới hơn của chúng tôi chạy Ubuntu 18.x và cả trên DigitalOcean chạy v20 mà không gặp sự cố nào -- cả cuộn tròn bên ngoài và bên trong đều hoạt động tốt.

Tôi thậm chí có thể ở trên một máy chủ khác và quay lại máy chủ đang gặp sự cố của mình và điều đó cũng hoạt động tốt.

Tôi đã thử mọi cách tôi có thể nghĩ ra (mà phải thừa nhận là không nhiều) và dường như không có gì hiệu quả.

• chạy các bản cập nhật cho các gói curl và certbot
• buộc cập nhật-ca-chứng chỉ
• thêm /etc/ssl/certs/cacert.pem cho cả hai quăn.cainfo và openssl.cafile vars trong php.ini

Tôi biết điều này có thể không thành vấn đề, nhưng để hoàn thiện, tôi cũng đã điều hành trang web thông qua các dịch vụ xác minh trực tuyến khác nhau:

• https://www.ssllabs.com/ssltest
• https://chainchecker.certifytheweb.com
• https://decoder.link/sslchecker

Tất cả đã trở lại với kết quả tích cực. Điều tiêu cực duy nhất (tôi đoán vậy) là SSLLabs đã xếp loại chúng tôi với điểm 'B' vì rõ ràng TLS 1.0 vẫn được bật.

Mọi sự trợ giúp sẽ rất được trân trọng. Tôi cảm thấy việc đọc các tài liệu được đề cập trong cảnh báo lỗi không thực sự hữu ích lắm.

Gợi ý/mẹo/thủ thuật??

1.000 cảm ơn bạn trước!

Meta: không phải là câu trả lời, ít nhất là chưa, nhưng một số thông tin và lời khuyên.

Được rồi, trường hợp dễ dàng không áp dụng. Như bạn đã gặp phải, Xoăn không cung cấp thông tin rất hữu ích khi gặp lỗi xác minh chứng chỉ từ ngăn xếp SSL/TLS cơ bản, ít nhất là khi sử dụng GnuTLS như bản dựng Ubuntu. Tuy nhiên, OpenSSL (sẽ có mặt vì curl có nó như một phần phụ thuộc, mặc dù tôi không hiểu tại sao) cung cấp một chương trình dòng lệnh có tên đơn giản opensl đó chủ yếu là một công cụ kiểm tra và rất dài dòng cũng như có khả năng chịu lỗi cao hơn. Ví dụ: trên một trang web cố ý xấu, trong phiên bản docker của Ubuntu 16.04:

# cuộn tròn -v https://untrusted-root.badssl.com/
* Đang thử 104.154.89.105...
* Đã kết nối với untrusted-root.badssl.com (104.154.89.105) cổng 443 (#0)
* đã tìm thấy 129 chứng chỉ trong /etc/ssl/certs/ca-certificates.crt
* đã tìm thấy 516 chứng chỉ trong /etc/ssl/certs
* ALPN, cung cấp http/1.1
* Kết nối SSL sử dụng TLS1.2/ECDHE_RSA_AES_128_GCM_SHA256
* xác minh chứng chỉ máy chủ không thành công. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Đóng kết nối 0
curl: (60) xác minh chứng chỉ máy chủ không thành công. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Thêm chi tiết tại đây: http://curl.haxx.se/docs/sslcerts.html

[cắt đoạn văn bản đóng hộp -- giống như của bạn]
# openssl s_client -kết nối không tin cậy-root.badssl.com:443 -tên máy chủ không tin cậy-root.badssl.com
ĐÃ KẾT NỐI(00000003)
depth=1 C = US, ST = California, L = San Francisco, O = BadSSL, CN = BadSSL Cơ quan cấp chứng chỉ gốc không đáng tin cậy
lỗi xác minh: num=19: chứng chỉ tự ký trong chuỗi chứng chỉ
---
Chuỗi chứng chỉ
 0 s:/C=US/ST=California/L=San Francisco/O=BadSSL/CN=*.badssl.com
   i:/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL Cơ quan cấp chứng chỉ gốc không đáng tin cậy
 1 s:/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL Cơ quan cấp chứng chỉ gốc không đáng tin cậy
   i:/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL Cơ quan cấp chứng chỉ gốc không đáng tin cậy
---
Chứng chỉ máy chủ
-----BẮT ĐẦU GIẤY CHỨNG NHẬN----
MIIIEmTCCAoGgAwIBAgIJAMJ1vCpOBAlkMA0GCSqGSIb3DQEBCwUAMIGBMQswCQYD
VQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5j
aXNjbzEPMA0GA1UECgwGQmFkU1NMMTQwMgYDVQQDDCtCYWRTU0wgVW50cnVzdGVk
IFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTIxMTIwNDawMDgxOVoXDTIz
MTIwnDawMDgxOVowYjELMAkGA1UEBhMCVVMxEzaARBgNVBAgMCkNhbGlmb3JuaWEx
FjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xDzANBgNVBAoMBkJhZFNTTDEVMBMGA1UE
AwwMKi5iYWRzc2wuY29tMIIBIJANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
wgTs+IzuBMKz2FDVcFjMkxjrXKhoSbAitfmVnrErLHY+bMBLYExM6rK0wA+AtrD5
csmGAvlcQV0TK39xxEu86ZQuUDemZxxhjPZBQsVG0xaHJ5906wqdEVImIXNshEx5
VeTRa+gGPUgVUq2zKNuq/27/YJVKd2s58STRMbbdTcDE/FO5bUKttXz+rvUV0jNI
5yJxx8IUemwo6jdK3+pstXK0flqiFtxpsVdE2woSq97DD0d0XEEi4Zr5G5PmrSIG
KS6xukkcDCeeo/uL90ByAKySCNmMV4RTgQXL5v5rVJhAJ4XHELtzcO9pGEEHRVV8
+WQ/PSzDqXzrkxpMhtHKhQIDAQABozIwMDAJBgNVHRMEAjAAMCMGA1UdEQQcMBqC
DCouYmFkc3NsLmNvbYIKYmFkc3NsLmNvbTANBgkqhkiG9w0BAQsFAAOCAgEADVgB
Ias+fb/Ckdnw5iSYsfRIcfhnTBNgvroorUQe09Psx0tAbjlIYqOCtloNhvCbJYa7
tQQOO65s7RKArpAA1qoapWfDti2aHuMNvGwImwX538RiLf4Rm4MEF6vuF6MZMH/u
Ts1iugB3+d7oSWl/K+RvA4NMRNrlxOLelBJwaTsExsQ5QalpPamongnyWXHZ2Sna
dsw9hBku9ZmlRqYOCE/TajsydqCIhCc2QC5xdd3fxXlcfq5h7G0oOuCYvW7BscTk
AQZYkwS+y3mTHF9wSlxJB4iEGC0NovdM5GsVgfvZ5+jtXGuDlsphAIFLxpIJi1bR
+NsAkEthHoQZDNttvtVJPFPp83PdRDmL6IwrbbXvAwZWWgYmS6HpbF5bxR09JIOA
KttGK1wnd6bh2d9Xy6kfoxZ1gz6i2y5OpxbMoi6z8o1Y2hSOv2kgnD2fxtR9X4OO
wrwWZWnhwsiq7pnZbZiA9GFR4tKZVcJ5ny5aul/MZ0wb5MST7wHW/7qhydfBpOy6
hZ5BSbwfmBao+CJ7NxNJb5c03W5+/Vf1uxXZhodpag6Z5p0rru0v7ea9nMk5dNUm
qR+2XGwzDk9n8jCWwfvSKCa77rf2HqKi8ZaQN/NRp7uVqfY++JVI+h3CLyMk8wTL
FifbLPKbSCW7PAFEfM3wh76VQg1CHpHOPVp/wno=
-----GIẤY CHỨNG NHẬN KẾT THÚC-----
chủ đề=/C=US/ST=California/L=San Francisco/O=BadSSL/CN=*.badssl.com
tổ chức phát hành=/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL Cơ quan cấp chứng chỉ gốc không đáng tin cậy
---
Không có tên CA chứng chỉ ứng dụng khách nào được gửi
Thông báo ký ngang hàng: SHA512
Khóa tạm thời máy chủ: ECDH, P-256, 256 bit
---
Bắt tay SSL đã đọc 3561 byte và ghi 425 byte
---
Mới, TLSv1/SSLv3, Mật mã là ECDHE-RSA-AES128-GCM-SHA256
Khóa công khai của máy chủ là 2048 bit
Đàm phán lại an toàn IS được hỗ trợ
Nén: KHÔNG CÓ
Mở rộng: KHÔNG CÓ
Không có ALPN nào được thương lượng
Phiên SSL:
    Giao thức: TLSv1.2
    Mã: ECDHE-RSA-AES128-GCM-SHA256
    ID phiên: AC5EB655FAEA1C1A320CA930E6A087FBFE020D3D9C451A72DD7CE77A8080AF0D
    Phiên-ID-ctx:
    Khóa chính: 419065F69901D74454A224DD22F9D459FA85E6EB4D6F043C649C8FDFA2E5E1FD9C168AC270087B88511B0939927F9A0A
    Key-Arg : Không có
    Danh tính PSK: Không có
    Gợi ý nhận dạng PSK: Không có
    Tên người dùng SRP: Không có
    Gợi ý thời gian tồn tại của vé phiên TLS: 300 (giây)
    Vé phiên TLS:
    0000 - cc 91 34 52 b1 ce c6 7c-8a 97 27 b0 b4 50 d6 9d ..4R...|..'..P..
    0010 - 27 b8 87 13 0b 70 92 e7-23 be 57 5c 00 31 f7 90 '....p..#.W\.1..
    0020 - 65 e3 08 d5 63 14 e9 cd-cc 50 59 3f 2a 98 31 d1 e...c....PY?*.1.
    0030 - ab f8 ca a8 09 aa 66 bf-7c ff b6 66 42 10 8b 6e ......f.|..fB..n
    0040 - c7 e8 7b f3 2b 35 b3 76-8c 95 b3 b5 37 85 09 42 ..{.+5.v....7..B
    0050 - 83 a9 c3 f7 54 f4 c5 f5-b2 0d d5 fa c6 24 a6 e2 ....T........$..
    0060 - fb 03 cf 35 9c 0d cc 48-e0 bc fc 43 11 3c 19 51 ...5...H...C.<.Q
    0070 - 0a 23 7d b2 6c ff 9b e2-bc 64 1d 74 34 cb 13 7b .#}.l....d.t4..{
    0080 - c8 55 47 95 71 9d 94 00-33 a0 a0 87 d4 4a fb 81 .UG.q...3....J..
    0090 - 34 36 28 2e ac ​​d7 22 36-36 5f 9c cb 3f 0d e7 00 46(..."66_..?...
    00a0 - e2 b7 d0 35 48 81 2f c7-9d a1 8a f6 52 a3 11 17 ...5H./.....R...
    00b0 - 67 89 94 d3 66 2b 5c c4-73 c5 72 1e 84 46 57 a5 g...f+\.s.r..FW.
    00c0 - 77 05 bc 49 a3 1a fe e6-da a8 0f 40 e2 17 f0 40 w..I.......@...@

    Thời gian bắt đầu: 1644060097
    Thời gian chờ: 300 (giây)
    Xác minh mã trả về: 19 (chứng chỉ tự ký trong chuỗi chứng chỉ)
---
Hỏi
XONG

Quan sát rằng đầu ra đầu tiên sau ĐÃ KẾT NỐI dòng: độ sâu=1 ... / xác minh lỗi:num=19:.... cho biết xác minh chứng chỉ không thành công; Tuy vậy opensl bỏ qua lỗi này và hoàn thành quá trình bắt tay, dẫn đến phần cuối cùng của đầu ra: Phiên SSL: / Giao thức: (hợp lệ) / Mật mã: (hợp lệ) / ... / Xác minh mã trả về: ... sau đó bạn phải gõ Hỏi và quay lại hoặc control-D (một mình) để thoát khỏi chương trình hoặc control-C để tắt, trừ khi bạn thêm </dev/null trên dòng lệnh có tác dụng tương tự như tự động gõ control-D. Hiện tại, bạn không cần phải hiểu các giá trị cụ thể của Giao thức và Mật mã, chỉ là chúng KHÔNG phải là những thứ như 'không' hoặc 'lỗi' hoặc 'thiếu'. Nhưng được cảnh báo rằng văn bản tin nhắn của OpenSSL cho verify=19 không đầy đủ đến mức khó hiểu; nói chung, việc chuỗi chứng chỉ từ máy chủ SSL/TLS bao gồm chứng chỉ gốc tự ký là điều hoàn toàn bình thường và nếu gốc đó nằm trong cửa hàng ủy thác cục bộ OpenSSL không (và curl/GnuTLS chắc chắn nên) chấp nhận một chuỗi như vậy. Chỉ khi thư mục gốc nằm trong chuỗi VÀ KHÔNG được tin cậy cục bộ thì bạn mới nhận được mã xác minh này. Các mã xác minh khác như 'đã hết hạn' hầu như có thông báo rõ ràng hơn.

Cũng lưu ý tôi đã sử dụng -tên máy chủ với tên máy chủ; điều này gọi SNI=Tên máy chủChỉ định mà nhiều máy chủ SSL/TLS hiện nay, bao gồm badssl.com, cần để cung cấp (các) chứng chỉ chính xác. Tuy nhiên, phiên bản curl trong Ubuntu16.04 KHÔNG gửi SNI; không có nghiên cứu, tôi không biết liệu điều này có phải là do phiên bản curl cũ hơn một chút (nhưng không nhiều lắm), việc sử dụng GnuTLS hay chỉ là một lỗi trong quá trình xây dựng. Nhưng dù sao như một bài kiểm tra thử các openssl s_client lệnh chống lại máy chủ của bạn cả khi có và không có -tên máy chủ lưu trữ một phần và lưu đầu ra (với chuyển hướng hoặc tee, tốt nhất là bao gồm thiết bị xuất chuẩn với &> hoặc |& áo phông hoặc tương đương) bởi vì chúng tôi có thể cần chúng. Nếu phiên bản có SNI hoạt động và phiên bản không có SNI gặp lỗi xác minh, thì đó là vấn đề của bạn -- thiếu SNI. (Có thể khó sửa, nhưng ít nhất bạn biết nó là gì.)

Nếu không, hãy nhìn vào kết quả không có SNI. Nếu OpenSSL báo cáo lỗi xác minh (đồng ý với curl/GnuTLS), hãy xem thông báo liên quan -- ít nhất nó phải chỉ ra hướng của vấn đề, nếu không chính xác là vấn đề. Nếu OpenSSL báo cáo không có lỗi xác minh (trong đó curl/GnuTLS có, cả hai đều sử dụng cùng một cửa hàng tin cậy do hệ thống cung cấp trong /etc/ssl) thì việc này sẽ phức tạp hơn, vì vậy tôi sẽ tạm dừng vấn đề đó và bổ sung sau nếu cần.