Đàm phán Exchange Hybrid TLS không thành công do lỗi NoCredentials
Gần đây tôi đã chạy Trình hướng dẫn cấu hình kết hợp trong môi trường Exchange 2016 và Exchange 2019. Ngoài ra còn có hai máy chủ Edge Transport trong môi trường này. Một máy chủ Exchange 2016 CU12 Edge Transport được sử dụng để liên lạc qua internet, một máy chủ Exchange 2019 CU1 Edge Transport (chạy trên Windows 2019 Server Core) được sử dụng để liên lạc kết hợp. Máy chủ này đã được chọn trong Trình hướng dẫn Cấu hình Kết hợp, chứng chỉ thích hợp đã được chọn, v.v. và Trình hướng dẫn Cấu hình Kết hợp đã hoàn tất thành công.
Khi trình hướng dẫn hoàn tất, Trình kết nối Nhận trên máy chủ Edge Transport đã được sửa đổi cho luồng thư kết hợp. Việc xác thực Trình kết nối Gửi từ Exchange Online sang Exchange tại chỗ không có vấn đề gì, thông báo kiểm tra đã được gửi và nhận thành công trong hộp thư của tôi.
Tuy nhiên, luồng tin nhắn từ Exchange tại chỗ đến Exchange Online không hoạt động và thư bị kẹt trong Hàng đợi trên máy chủ Edge Transport. Nhìn vào Hàng đợi, có vẻ như đã xảy ra sự cố hết thời gian chờ vì nó cho biết:
LastError : [{LED=451 4.4.395 Máy chủ đích đã phản hồi có lỗi. -> 421 4.4.1 Đã hết thời gian kết nối};{MSG=};{FQDN=exchangelabsnl-mail-onmicrosoft-com.mail.protection.outlook.com}; {IP=104.47.10.36};{LRT=2/5/2019 6:32:14 sáng}]
Đây không phải là sự cố tường lửa, tôi có thể sử dụng Telnet để kết nối trên cổng 25 và gửi tin nhắn cho chính mình (tin nhắn này đến trong thư mục thư rác nhưng nó đã đến nơi).
Việc mở tệp nhật ký giao thức Gửi Trình kết nối (bật đầu nối đi trước) sẽ hiển thị một lỗi khác. Khi cố gắng thực hiện bắt tay TLS, việc đàm phán TLS không thành công với lỗi NoCredentials.
Điều này thật lạ vì cùng một chứng chỉ được sử dụng bởi Trình kết nối nhận (bạn có thể kiểm tra điều này bằng cách sử dụng https://checktls.com và nhập FQDN của máy chủ Exchange đang giữ Trình kết nối nhận).
“Thương lượng TLS không thành công với lỗi NoCredentials ” có vẻ như là sự cố khóa riêng với chứng chỉ (theo bài viết kb của Microsoft KB4495258) nhưng PowerShell cho thấy nó có khóa riêng:
Khi quay lại tệp nhật ký giao thức, bạn có thể thấy dấu vân tay của chứng chỉ trong trường dữ liệu và dấu vân tay này không khớp với dấu vân tay của chứng chỉ mà Get-ExchangeCertificate trả về.
Tuy nhiên, Get-ExchangeCertificate chỉ trả về các chứng chỉ có khóa riêng, nếu không có khóa riêng thì sẽ không có gì được trả lại.
Khi mở kho chứng chỉ bằng PowerShell bằng các lệnh sau:
Chứng chỉ CD:
Cd LocalMachine
Đặt-Vị trí của tôi
Nhận-ConItem
Tất cả các chứng chỉ trong cửa hàng đều được hiển thị và khi kiểm tra chứng chỉ bằng dấu vân tay mà chúng tôi nhận được từ nhật ký giao thức, chứng chỉ này không có khóa riêng:
Điều đó giải thích các thông báo lỗi NoCredentials. Sử dụng lệnh sau để xóa chứng chỉ sai:
Nhận-ChildItem | ?{$_.Thumbprint -like “B79*”} | Loại bỏ mục
Sau khi khởi động lại luồng thư xuyên cơ sở của Dịch vụ vận chuyển sẽ hoạt động trở lại.
Tất nhiên, câu hỏi chính là làm thế nào điều này xảy ra. Tôi không chắc chắn, nhưng tôi nhớ đã yêu cầu nhiều chứng chỉ cùng lúc (vài tuần trước) và đã xảy ra một số lỗi. Tôi không chú ý quá nhiều đến điều này vì mọi thứ dường như đều ổn. Nhưng cuối cùng thì hóa ra không phải vậy, và ngay từ đầu tôi đã không để ý vì SMTP gửi đến hoạt động tốt. Thở dài…. ?