Điểm:1

Đã cập nhật EXIM4, hiện không sử dụng TLS do lỗi xác thực

lá cờ gb

Tôi có một máy chủ gia đình và đã cập nhật ổ đĩa hệ thống lên ổ SSD như trước đây trên sự kết hợp giữa USB và HDD cho/home và/var. Vì USB nằm trên phiên bản Debian trước nên tôi đã thực hiện cài đặt mới, phiên bản này cũng đã nâng cấp tôi lên phiên bản 4.95 của EXIM, trước đây tôi dùng 4.94.2.

Mặc dù có cùng cấu hình máy chủ thông minh, nhưng để sử dụng máy chủ SMTP của ISP của tôi, nó không còn sử dụng TLS nữa và đưa ra lỗi xác thực.

/var/log/exim4/mainlog:

2022-04-12 03:30:25 1ne6I7-000AHw-MF Phiên TLS: (xác minh chứng chỉ không thành công): gửi không được mã hóa tới H=<DOMAIN> [<IP>] (không có trong hosts_require_tls)

Thư vẫn được chấp nhận không được mã hóa, nhưng hiện tại thư từ các công việc định kỳ đang bị I.S.P. như thư rác. Thay đổi duy nhất là tin nhắn là một Nhận tiêu đề đã đi từ với esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) chỉ với esmtp (Exim 4.95). Vì vậy, có lẽ sự khác biệt đó là thứ đang đánh dấu nó cần được chú ý thêm.

Tôi đã sử dụng cùng một khóa và chứng chỉ tự ký (có dấu thời gian 2013) như lần cài đặt trước. Tôi cũng đã thử tạo một cặp mới với hiệu ứng tương tự.

Sau khi tìm kiếm lời khuyên trực tuyến, chúng tôi khuyên bạn nên sử dụng cấu hình letsencrypt để có thể xác thực cấu hình đó. Tôi đã sử dụng nó, nhưng nó gây ra hành vi tương tự trong EXIM.

Đây là cấu hình của tôi

/etc/exim4/update-exim4.conf.conf:

dc_eximconfig_configtype='máy chủ thông minh'
dc_other_hostnames='<MIỀN ĐỊA PHƯƠNG>'
dc_local_interfaces='127.0.0.1; ::1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='sai'
dc_relay_nets=''
dc_smarthost='<MIỀN ISP>:587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'

/etc/exim4/etc/exim4/conf.d/main/00_local_settings:

MAIN_TLS_ENABLE = có
MAIN_TLS_CERTIFICATE = /etc/letsencrypt/live/<MIỀN ĐỊA PHƯƠNG>/fullchain.pem
MAIN_TLS_PRIVATEKEY = /etc/letsencrypt/live/<MIỀN ĐỊA PHƯƠNG>/privkey.pem

/etc/letsencrypt/archive/<MIỀN ĐỊA PHƯƠNG>/*15.*

-rw-r--r-- 1 root Debian-exim 1870 28 tháng 3 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/cert15.pem
-rw-r--r-- 1 root Debian-exim 3749 28 tháng 3 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/chain15.pem
-rw-r--r-- 1 root Debian-exim 5619 28 tháng 3 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/fullchain15.pem
-rw------- 1 root Debian-exim 1708 28 tháng 3 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/privkey15.pem

tôi cũng có /etc/exim4/passwd.client tệp có chi tiết đăng nhập SMTP của tôi và tệp này rõ ràng là đang hoạt động để gửi thư.

là một tên miền trỏ đến địa chỉ IP nhà của tôi.

Các mục nhập khóa letencrypt trong 00_local_settings trỏ đến các liên kết tượng trưng của nó dẫn đến các phiên bản hiện tại. Trên những cái đó, tôi đã thay đổi quyền sở hữu nhóm để EXIM có thể thấy khóa riêng tư, nhưng không để lại quyền.

Cấu hình làm việc trước đây của tôi cũng vậy, nhưng với cấu hình tự ký exim.crtexim.key tập tin trong /etc/exim4và do đó không có hai dòng sau trong tệp 00_local_settings của tôi.

Tôi cũng đã thử sao chép các tệp letsencrypt vào /etc/exim4 và đặt tên cho chúng exim.certexim.key với cùng quyền của 640 và không có gì trong 00_local_settings nhưng nó không thay đổi gì cả.

Điều đặc biệt khó chịu là trong lần kiểm tra cuối cùng, tôi chỉ xóa các phím mà không có cấu hình nào để xem điều gì sẽ xảy ra. Tôi cũng gặp lỗi tương tự, vì vậy tôi không thể biết liệu có vấn đề với các phím tôi đã sử dụng hay thậm chí không nhìn thấy chúng.

lá cờ us
tìm manh mối trong /var/log/exim4/mainlog và /var/log/exim4/paniclog
lá cờ gb
Thật không may, không có `paniclog` và dòng tôi đưa ra là đầu mối duy nhất trong `mainlog`. Các mục trước và sau giống như một trong hệ thống Debian cũ, để xác nhận kết nối và thư đã được chấp nhận. Nhưng đối với lỗi TLS, tôi đã bao gồm mọi thứ có vẻ bình thường. Thậm chí không có lỗi cấu hình nào được ghi lại ở bất kỳ đâu khi khởi chạy Exim. Tôi hoàn toàn không biết phải làm gì.
Điểm:2
lá cờ gb

Tôi đã tiếp tục nghiên cứu và tôi đã tìm thấy một câu trả lời. Tôi không rõ chứng chỉ của ai đang được xác minh, tôi đã giả sử chứng chỉ của mình nhưng nhận ra đó có thể là một trong những máy chủ SMTP từ xa.

Thêm mục bên dưới vào /etc/exim4/etc/exim4/conf.d/main/00_local_settings vô hiệu hóa xác minh, cho phép sử dụng TLS.

REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = !*

Điều này có thể được xác nhận trong tiêu đề thư hiện cho thấy nó đang được nhận với esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)

Tôi cho rằng đây là những gì đã xảy ra trước đó và Debian hoặc Exim đã thay đổi mặc định thành yêu cầu xác minh kể từ cấu hình ban đầu của tôi.

Có lẽ nếu máy chủ từ xa sử dụng chứng chỉ tự tạo thì không thể xác minh được?

lá cờ us
khi đọc lại dòng nhật ký tôi sắp đề xuất nguyên nhân tương tự.
lá cờ gb
Có một chút mơ hồ về việc ai là người xác minh ai vì nó không đưa ra gợi ý máy chủ nào đã tạo ra lỗi. Vì tôi đã tìm kiếm rất nhiều để tìm ra câu trả lời nhưng không thành công, hy vọng rằng việc đăng nó ở đây có nghĩa là bất kỳ ai khác trong tình huống tương tự sẽ tìm ra giải pháp đơn giản. Cảm ơn đã xem xét câu hỏi mặc dù.

Đă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.