Điểm:0

Kết nối an toàn với web-/máy chủ thư không thành công trong MacOS/iOS

lá cờ am

Tôi tuyệt vọng: Tôi đã chuyển hai miền từ máy chủ này sang máy chủ khác đang chạy trơn tru. Tôi đã bảo mật cả hai miền (web & thư) bằng chứng chỉ Letsencrypt.Giờ đây, chủ sở hữu của các miền này đã phàn nàn về việc máy chủ thư không hoạt động. Nhưng điều này là không thể, bởi vì các miền khác có thể gửi và nhận e-mail. Trong khi khắc phục sự cố, tôi nhận thấy rằng không thể truy xuất trang web nào từ máy chủ của tôi trên macOS hoặc iOS. (Kết nối bị từ chối - Không thể thiết lập kết nối an toàn). Trong Windows/Linux/Android, tất cả điều này không có vấn đề gì và lưu lượng thư cũng hoạt động hoàn hảo. Vì vậy, wtf đang diễn ra? Có vẻ như Apple không thể làm việc với các chứng chỉ Letsencrypt đã tạo. Điều mà tôi không thể tưởng tượng nổi.

Có ai có bất kỳ ý tưởng về điều này? Cảm ơn bạn đã giúp đỡ.

Máy chủ: Ubuntu 20.04, Plesk quản lý

Khách hàng: macOS Catalina, Apple Mail

---[CHỈNH SỬA]--- tôi đã chạy

openssl s_client -kết nối maildomain.com:465

trên máy Windows VÀ máy Mac, để xem điều gì đang xảy ra khi kết nối với máy chủ thư của tôi. Kết quả trên PC:

    ĐÃ KẾT NỐI(00000003)
độ sâu=2 C = US, O = Nhóm nghiên cứu bảo mật Internet, CN = ISRG Root X1
xác minh trả lại: 1
độ sâu=1 C = US, O = Let's Encrypt, CN = R3
xác minh trả lại: 1
độ sâu=0 CN = maildomain.com
xác minh trả lại: 1
---
Chuỗi chứng chỉ
 0 s:CN = maildomain.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Nhóm nghiên cứu bảo mật Internet, CN = ISRG Root X1
 2 s:C = US, O = Nhóm nghiên cứu bảo mật Internet, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Chứng chỉ máy chủ
-----BẮT ĐẦU GIẤY CHỨNG NHẬN----
MIIFJzCCBA+gAwIBAgISBBHHETtspqio7t1ZKYQ36xHMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTEwMDUwNzQyMjVaFw0yMjAx...vv.
-----GIẤY CHỨNG NHẬN KẾT THÚC-----
chủ đề=CN = maildomain.com

nhà phát hành=C = US, O = Let's Encrypt, CN = R3

---
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: SHA256
Loại chữ ký ngang hàng: RSA-PSS
Khóa tạm thời máy chủ: X25519, 253 bit
---
Bắt tay SSL đã đọc 4676 byte và ghi 395 byte
Xác minh: OK
---
Mới, TLSv1.2, Mật mã là ECDHE-RSA-AES256-GCM-SHA384
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-AES256-GCM-SHA384
    ID phiên: DDE8ED4DBF7BD8E8F2D411EDE00C7522C0A15927E3D0C75F58F174B7464270D3
    Phiên-ID-ctx:
    Khóa chính: 6D3167E0283ED9BA1F6427841212C8BAF37FF75998B369DE4184618EF9BFBE9F8860809CC9B7xxxxxxxxxxxxxxxxxxxx
    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: 7200 (giây)
    Vé phiên TLS:
    0000 - 21 be ab 05 b8 95 30 14-cf c1 ff 7d 98 aa 3c 82 !.....0....}..<. ... vân vân...

    Thời gian bắt đầu: 1633683311
    Thời gian chờ: 7200 (giây)
    Xác minh mã trả về: 0 (ok)
    Bí mật tổng thể mở rộng: có
---
220 my.server.com Hậu tố ESMTP (Debian/GNU)
từ bỏ
221 2.0.0 Tạm biệt
đóng cửa

Và đây là phản hồi trên máy Mac:

ĐÃ KẾT NỐI(00000003)
341:error:1407742E:SSL thường trình:SSL23_GET_SERVER_HELLO:tlsv1 phiên bản giao thức cảnh báo:S23_clnt.c:596:

Vì vậy, có vẻ như Mac không thể xử lý TLS1.2/TLS1.3...

Bất cứ đề nghị phải làm gì?

lá cờ ph
macOS Catalina sẽ có thể xử lý cả TLS v1.2 và 1.3 (ít nhất là sử dụng thư viện TLS của hệ thống; không chắc chắn về lệnh `openssl`). Tôi muốn thử xóa chứng chỉ "ISRG Root X1" khỏi gói mà máy chủ sử dụng -- đó là chứng chỉ có chữ ký chéo từ "DST Root CA X3", vừa hết hạn và điều này có thể khiến khách hàng nhầm lẫn.
lá cờ am
Này, @Gordon Davisson! Cảm ơn câu trả lời của bạn. Làm thế nào để bạn biết rằng các chứng chỉ này đã hết hạn?
lá cờ ph
Xem [tin nhắn này tại LetsEncrypt](https://letsencrypt.org/2021/10/01/cert-chaining-help.html) và [tin nhắn này từ Scott Helme](https://scotthelme.co.uk/lets -encrypt-root-expiration-post-mortem/). Lưu ý rằng tài khoản trung gian bạn đang phân phát chưa hết hạn, nhưng tài khoản gốc mà nó được ký hợp đồng thì có. Điều này hơi kỳ lạ, nhưng đã được thực hiện để hỗ trợ các ứng dụng khách Android cũ hơn (cũ hơn 7.1.1). Bạn có cần hỗ trợ các phiên bản Android cũ hơn không? Nếu vậy, trung gian đó sẽ là cần thiết. Nhưng dù sao thì tôi cũng sẽ thử kiểm tra, vì vậy ít nhất bạn có thể biết liệu đó có phải là sản phẩm trung gian đang gây nhầm lẫn cho các máy khách Mac hay không.
lá cờ ph
Nhân tiện, một điều khác cần thử là thêm "ISRG Root X1" thực tế (bản tự ký, không phải bản trung gian có cùng tên), có sẵn [tại đây](https://letsencrypt.org/certificates/), vào chuôi. Nói chung, không cần thiết phải bao gồm các chứng chỉ gốc trong gói của máy chủ, nhưng trong trường hợp này, bạn nên thử xem liệu nó có gây nhầm lẫn cho các máy khách Mac hay không.
lá cờ am
Xin chào, @Gordon. Xin lỗi vì hồi âm muộn. Tôi đã xóa chứng chỉ qua dpkg nhưng có vẻ như nó vẫn ở đó. Khi kết nối với máy chủ thư của tôi, tôi vẫn thấy dòng đầu tiên sau CONNECT. (Bài đăng ban đầu, nhật ký đầu tiên).Tôi đang làm gì sai? Cảm ơn và trân trọng.
lá cờ ph
Tôi ngày càng nghi ngờ về phiên bản TLS -- hãy thử `openssl s_client -connect github.com:443
lá cờ am
Xin chào @Gordon. Cảm ơn rất nhiều cho mẹo của bạn. Tôi sẽ cho nó nó một cơ hội. Tuy nhiên, tôi đoán nhiều hơn là do sự cố máy chủ vì không thể truy cập trang web được mã hóa SSL nào từ máy chủ đó. Nhưng như tôi đã nói, chỉ từ thiết bị iOS và máy Mac. Bạn có bất cứ ý tưởng khác?
lá cờ ph
Net, tại thời điểm này, tôi chỉ đang tìm kiếm thêm thông tin để xác định nguyên nhân gây ra sự cố.
lá cờ am
Được chứ. Github đã trả lời bằng "Mới, TLSv1/SSLv3, Mật mã là..." Chứng chỉ là Chứng chỉ đảm bảo cao của DigCert.
lá cờ am
@Gordon, kể từ đó, tôi đã có thể sử dụng iPhone và iPad của con mình để truy cập các trang web được lưu trữ trên máy chủ này. Vì vậy, có vẻ như đã xảy ra sự cố với máy Mac của người dùng. Có khả năng máy tính của anh ấy bị nhiễm thứ gì đó không? Tôi không phải là người thích Apple .... xin lỗi.
lá cờ am
@GordonDavisson: Ngay cả sau khi cập nhật phần mềm của Mac, không có cách nào để nó hoạt động. Tôi đang nghĩ đến việc hỗ trợ phiên bản TLS/SSL cũ. Làm thế nào tôi có thể làm điều đó?
lá cờ am
Tôi cần hỏi, liệu tôi đã xóa chứng chỉ đã hết hạn khỏi máy chủ đúng cách hay chưa. Bởi vì, vẫn còn: ```depth=2 C = US, O = Nhóm nghiên cứu bảo mật Internet, CN = ISRG Root X1 xác minh trả lại: 1 độ sâu=1 C = US, O = Let's Encrypt, CN = R3 xác minh trả lại: 1 độ sâu=0 CN = maildomain.com xác minh trả lại: 1 ```
lá cờ am
Chuôi: `Chuỗi chứng chỉ 0 s:CN = maildomain.com i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Nhóm nghiên cứu bảo mật Internet, CN = ISRG Root X1 2 s:C = US, O = Nhóm nghiên cứu bảo mật Internet, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3` tôi không hiểu...
lá cờ ph
Ok, bây giờ tôi thực sự bối rối. Kết quả OpenSSL mới nhất trong nhận xét của bạn (có phải từ Windows không?) Cho thấy nó vẫn đang phục vụ trung gian được ký chéo. Tôi hoàn toàn không quen thuộc với Plesk, vì vậy tôi không có bất kỳ đề xuất nào về việc gỡ bỏ nó. Nhưng đối với thử nghiệm github, phần "Mới, TLSv1/SSLv3" dường như hoàn toàn sai, vì theo như tôi thấy thì không có máy chủ nào của họ hỗ trợ TLSv1 hoặc SSLv3 (xem [kết quả kiểm tra SSL Labs này](https://www .ssllabs.com/ssltest/analyze.html?d=github.com).Vì vậy, có thể có một số loại phần mềm độc hại/đánh chặn SSL/thứ gì đó tương tự đang diễn ra?
lá cờ am
Không. tôi đã chạy ```òpenssl s_client -kết nối maildomain.com:465 ```
lá cờ ph
Bạn có thể chia sẻ tên miền thực tế để tôi có thể chạy thử nghiệm trực tiếp không?
lá cờ am
Tất nhiên, nếu bạn cho tôi địa chỉ e-mail của bạn....;)
lá cờ am
Lỗi này vẫn tồn tại, ngay cả sau khi chuyển sang một máy chủ hoàn toàn mới. SSLLabs hiển thị màu xanh lá cây trên miền được bảo mật nhưng tôi không thể gọi trang web. Chỉ với Edge, bạn mới có thể lấy nội dung. Firefox và Chrome: Không! Và Safari đang phàn nàn về việc nó không thể thiết lập kết nối an toàn. Wtf đang diễn ra?

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.