dovecot 將網站憑證與郵件憑證混淆

dovecot 將網站憑證與郵件憑證混淆

我會盡量簡短。我希望 beta.example.com 使用我的伺服器作為郵件伺服器。我看到 dovecot 和 postfix 只有一行用於證書。所以我為 mail.example.com 製作了一個完全有效的證書。我嘗試使用 Thunderbird 連接到我的郵件伺服器 (beta.example.com),它給了我一個錯誤的網域警告,指出該憑證屬於 mail.example.com。我哪裡搞砸了? mx 記錄顯示 mail.example.com,那麼它不應該知道該憑證是針對 mail.example.com 的嗎?我添加了一個例外,但它仍然失敗(在提示我輸入密碼之後)。我查看了我的伺服器,看來 dovecot 拒絕連接,因為 Thunderbird 給它提供了錯誤的憑證資料。

答案1

您體驗到憑證的真正目的:防止意外連線到不是您期望的伺服器(mail.example.com而不是beta.example.com)。您必須設定為您連接到的網域所頒發的證書,即。如果郵件用戶端連接到beta.example.com,您需要 的憑證beta.example.com

要麼取得另一個憑證beta.example.com(或將其作為主題備用名稱),要麼mail.example.com指向 的 IP beta.example.com

答案2

客戶端配置為連接到mail.example.com.

它連接到的伺服器聲稱(在憑證中)是beta.example.com.

因為mail.example.com與 不是一回事beta.example.com,客戶抱怨不符。這完全是設計使然。

為了讓它發揮作用,您需要設定郵件伺服器以提供包含與用戶端指向的主機名稱相符的主題備用名稱的憑證。主機名稱最終如何解析為 IP 位址不是重點。

過去,您會將主機名稱放在憑證的公用名字段中,但這種做法已被棄用。如果您願意,您仍然可以將主機名稱作為憑證的 CN,但為了獲得最佳相容性,您需要把它當作一個SAN。我相信,如果您自己不在 CSR 中這樣做,大多數 CA 都會將 CN 作為 SAN 作為一項服務提供給您,但有些 CA 可能不會這樣做;檢查你的證書。

如果您必須使用相同的證書對於 Postfix 和 Dovecot,但出於某種原因你想要不同的主機名為兩者(例如smtp.example.compop.example.com)發布,那麼您需要一個對所涉及的兩個主機名稱都有效的憑證。這可以透過多主機名稱憑證或通配符 ( *.example.com) 憑證來完成。


也,MX(郵件交換器)DNS RR 實際上僅與處理特定網域郵件的郵件伺服器的傳入 SMTP 連線相關,其中遠端郵件伺服器最初只知道收件者網域。例如,這是完全有效的

example.com. MX 0 mail.example.com.
mail.example.com. CNAME beta.example.com.
beta.example.com. A 192.0.2.123

儘管並不真正推薦,因為將 RR 指向非規範 RR 可能會使某些解析器阻塞。但是,如果遠端系統的解析器接受它(大多數都接受),則上面的內容實際上與您擁有的相同

example.com. MX 0 mail.example.com.
mail.example.com. A 192.0.2.123

在這兩種情況下,遠端 MTA(郵件傳輸代理程式;在現代,郵件伺服器與其他郵件伺服器進行 SMTP 通訊)將連接到 mail.example.com(因為這是 MX 中給定的 MX 主機名稱) RR) ,因此需要一個對mail.example.com 有效的憑證。

您的 MUA 不會查詢 MX 記錄無論如何都不知道;它將查詢您指定為傳入 (POP/IMAP) 或傳出 (SMTP) 的任何主機名稱的位址(AAAAA在極少數情況下也可能;A6 RR 已棄用,但在IPv6 中使用了一段時間)記錄A6郵件伺服器。

相關內容