RFC 7817: Kiểm tra danh tính máy chủ TLS cập nhật cho email

Current Standard Transport Security Published March 2026

ELI5: Khi bạn kết nối với một trang web qua HTTPS, trình duyệt của bạn sẽ kiểm tra xem chứng chỉ có khớp với tên miền hay không. Các máy chủ email cần làm điều tương tự khi chúng kết nối với nhau qua TLS — nhưng định tuyến email thông qua các bản ghi MX làm cho vấn đề trở nên phức tạp hơn. RFC này xác định chính xác tên nào mà máy chủ gửi nên kiểm tra chứng chỉ dựa vào.

Tại Sao Điều Này Tồn Tại

Khi một SMTP client bắt đầu kết nối TLS đến máy chủ mail từ xa (thông qua STARTTLS theo RFC 3207 hoặc TLS ngầm định theo RFC 8314), nó nhận được một chứng chỉ. Nhưng tên máy chủ nào sẽ xuất hiện trong chứng chỉ đó?

Trong email, bạn không kết nối trực tiếp đến miền của người nhận. Bạn tra cứu bản ghi MX cho example.com, có thể chỉ đến mail.hosting-provider.net. Chứng chỉ có nên nói example.com hay mail.hosting-provider.net? Câu trả lời rất quan trọng vì:

Kiểm tra tên sai có nghĩa là các chứng chỉ hợp pháp bị từ chối
Không kiểm tra cũng có nghĩa là TLS chỉ cung cấp mã hóa nhưng không xác thực — kẻ tấn công trung gian có thể trình bày bất kỳ chứng chỉ nào
Nhà cung cấp dịch vụ email phục vụ hàng ngàn miền từ các máy chủ tương tự và không thể nhận được chứng chỉ cho mọi miền của khách hàng

Cách Hoạt Động

RFC 7817 định nghĩa một cấp bậc rõ ràng về các định danh tham chiếu mà client nên kiểm tra so với chứng chỉ của máy chủ, tùy thuộc vào cách máy chủ được phát hiện:

Thứ Tự Kiểm Tra Danh Tính

Tên máy chủ MX — nếu máy chủ được tìm thấy qua tra cứu MX, hãy kiểm tra chứng chỉ so với tên máy chủ MX (ví dụ: mail.hosting-provider.net), không phải miền người nhận.
Miền người nhận — nếu không có bản ghi MX và client quay lại bản ghi A/AAAA cho chính miền đó, hãy kiểm tra so với miền người nhận.
Cấu hình rõ ràng — nếu máy chủ được cấu hình thủ công (ví dụ: máy chủ gửi), hãy kiểm tra so với tên máy chủ được cấu hình.

Quy Trình Kết Nối TLS

; Bước 1: Phân giải MX cho miền người nhận
dig example.com MX
example.com.  IN  MX  10 mail.provider.net.

; Bước 2: Kết nối đến máy chủ MX, bắt đầu SMTP
220 mail.provider.net ESMTP sẵn sàng
EHLO sender.example.org
250-mail.provider.net
250-STARTTLS
STARTTLS
220 Tiếp tục

; Bước 3: Bắt tay TLS — kiểm tra chứng chỉ so với "mail.provider.net"
; Chứng chỉ SAN: DNS:mail.provider.net, DNS:*.provider.net
; Tìm thấy kết quả trùng khớp → danh tính được xác minh

Chi Tiết Kỹ Thuật Chính

Quy Tắc Khớp Chứng Chỉ

Trường	Kiểm Tra	Ghi Chú
Tên Thay Thế Chủ Đề (SAN)	Ưu Tiên	Kiểm tra các mục DNS-ID trong phần mở rộng SAN trước tiên
Tên Chung (CN)	Dự Phòng	Chỉ nếu không có mục DNS-ID SAN (thực hành không dùng nữa)
Ký Tự Đại Diện	Nhãn ngoài cùng bên trái	`*.provider.net` khớp `mail.provider.net` nhưng không khớp `a.b.provider.net`

Định Danh Tham Chiếu Theo Phương Pháp Phát Hiện

Phương Pháp Phát Hiện	Kiểm Tra Chứng Chỉ So Với	Ví Dụ
Tra cứu MX	Tên máy chủ MX	Chứng chỉ phải khớp `mail.provider.net`
Dự phòng A/AAAA (không có MX)	Miền người nhận	Chứng chỉ phải khớp `example.com`
Bản ghi SRV (RFC 6186)	Tên máy chủ đích SRV	Chứng chỉ phải khớp đích SRV
Cấu hình thủ công	Tên máy chủ được cấu hình	Chứng chỉ phải khớp những gì quản trị viên đặt
Chính sách MTA-STS (RFC 8461)	Tên máy chủ MX trong chính sách	Chính sách giới hạn tên MX nào được chấp nhận

Tương Tác Với DANE

Khi DANE (RFC 7672) được triển khai, bản ghi TLSA trong DNS sẽ ghim chứng chỉ hoặc khóa công khai cho tên máy chủ MX. DANE cung cấp bảo đảm danh tính mạnh hơn so với xác minh dựa trên CA truyền thống vì nó không phụ thuộc vào việc tin tưởng một cơ quan chứng chỉ — chủ sở hữu miền xuất bản dữ liệu chứng chỉ dự kiến trực tiếp trong DNS được ký bằng DNSSEC.

Những Lỗi Phổ Biến

Kiểm tra chứng chỉ so với miền người nhận. Nếu MX cho example.com chỉ đến mail.google.com, chứng chỉ sẽ nói mail.google.com, không phải example.com. Kiểm tra tên sai gây ra lỗi TLS hoặc buộc bạn phải bỏ qua xác minh hoàn toàn.
Quay lại TLS không xác thực một cách âm thầm. Nhiều MTA sử dụng "TLS cơ hội" — chúng mã hóa nếu có thể nhưng không xác minh chứng chỉ. Điều này bảo vệ chống lại eavesdropping thụ động nhưng không chống lại các cuộc tấn công chủ động. Sử dụng MTA-STS hoặc DANE để yêu cầu kết nối được xác thực.
Cấu hình chứng chỉ sai trên các máy chủ MX. Nếu bản ghi MX của bạn chỉ đến mx.yourdomain.com nhưng chứng chỉ của bạn chỉ bao phủ yourdomain.com, người gửi xác minh chứng chỉ sẽ không thành công. Đảm bảo SAN của chứng chỉ của bạn bao gồm tên máy chủ MX của bạn.
Bỏ qua xác minh chuỗi chứng chỉ. Xác minh tên máy chủ là cần thiết nhưng không đủ. Toàn bộ chuỗi chứng chỉ phải xác minh được đối với một CA gốc được tin tưởng. Chứng chỉ hết hạn hoặc tự ký sẽ vẫn không thành công ngay cả khi tên khớp.
Không gia hạn chứng chỉ trước khi hết hạn. Chứng chỉ hết hạn trên các máy chủ MX của bạn gây ra lỗi bắt tay TLS. Người gửi thực thi MTA-STS sẽ từ chối gửi mail đến máy chủ có chứng chỉ hết hạn.

Tác Động Đến Khả Năng Gửi Thư

Thực thi MTA-STS phụ thuộc vào điều này. Khi một miền nhận xuất bản chính sách MTA-STS, các máy chủ gửi phải xác minh chứng chỉ MX theo RFC 7817. Nếu chứng chỉ MX của bạn được cấu hình sai, người gửi thực thi MTA-STS (bao gồm Gmail) sẽ không gửi thư đến bạn.
Google và Microsoft xác minh chứng chỉ. Các nhà cung cấp lớn ngày càng thực hiện xác minh chứng chỉ cho thư gửi đi. Chứng chỉ được cấu hình sai trên cơ sở hạ tầng nhận của bạn có thể gây ra lỗi gửi thư từ những người gửi này.
DANE/TLSA cung cấp bảo đảm mạnh nhất. DANE liên kết chứng chỉ với DNSSEC, loại bỏ hoàn toàn sự phụ thuộc vào CA. Kết hợp với kiểm tra danh tính RFC 7817, nó cung cấp vận chuyển email được xác thực và mã hóa.
Báo cáo TLS tiết lộ các vấn đề. Báo cáo TLS SMTP (RFC 8460) gửi cho bạn báo cáo khi người gửi gặp lỗi TLS kết nối đến máy chủ của bạn, bao gồm các lỗi xác minh chứng chỉ. Xuất bản bản ghi TLSRPT và giám sát các báo cáo này.