☰

sendmail：由於客戶端憑證錯誤，伺服器顯示失敗

tag-icon • tag-icon ssl email sendmail
sendmail：由於客戶端憑證錯誤，伺服器顯示失敗

我的 sendmail 伺服器（FreeBSD，針對 OpenSSL 編譯）拒絕與一組特定的客戶端協商 TLS。

日誌訊息如下所示：

sm-mta[92474]：STARTTLS=伺服器，錯誤：接受失敗=-1，原因=sslv3警報錯誤證書，SSL_error=1，errno=0，重試=-1，中繼=xx.example.com [XX .XX .XX.XX]

除了這些源自知名 ISP 郵件基礎設施的故障之外，一切都運作良好；伺服器本身的憑證是最新且有效的。

有兩個問題，回答其中任何一個都會有幫助：

  1. 我該如何診斷這個問題？特別是，我可以從 sendmail 環境中取得錯誤憑證的副本嗎？
  2. 我可以更新我的 sendmail 設定以告訴客戶端不要提供證書，或告訴 sendmail 接受偽造的客戶端證書嗎？

謝謝！

編輯：我在這裡發現了問題，即我的伺服器的證書與我的伺服器的 DANE TLSA 記錄不符。查看交易的 Wireshark 解碼顯示，ISP（康卡斯特）正在接收我的有效證書，但無論如何都拒絕了它，結果發現 TLSA 記錄未同步。看來康卡斯特可能是網路上為數不多的在 DANE 驗證失敗後拒絕發送的電子郵件發送者之一。

答案1

您可以使用 OpenSSL 查詢遠端伺服器。例如，要查看 Google 郵件伺服器之一上的憑證：

echo quit | openssl s_client -connect aspmx.l.google.com:25 -starttls smtp

應顯示類似以下內容：

CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
verify return:1
depth=0 CN = mx.google.com
verify return:1
---
Certificate chain
 0 s:CN = mx.google.com
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIG9DCCBdygAwIBAgIQdfcJTB0GgVsKbOXnm+OJmTANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzETMBEGA1UEAxMKR1RTIENBIDFDMzAeFw0yMzA0MDMwODIzNTRaFw0yMzA2MjYw
ODIzNTNaMBgxFjAUBgNVBAMTDW14Lmdvb2dsZS5jb20wWTATBgcqhkjOPQIBBggq
hkjOPQMBBwNCAASHHjjoYwgwyC6/DYMfRij2+kZyiywt8lVwAyy90RasYt3tDcmD
kqUhLf8Mv527u0akQVq00cpcRg9W1tFgSKl9o4IE1TCCBNEwDgYDVR0PAQH/BAQD
AgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYE
FBneGLCbQL6PsUCbmin+e8j25tSYMB8GA1UdIwQYMBaAFIp0f6+Fze6VzT2c0OJG
FPNxNR0nMGoGCCsGAQUFBwEBBF4wXDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au
cGtpLmdvb2cvZ3RzMWMzMDEGCCsGAQUFBzAChiVodHRwOi8vcGtpLmdvb2cvcmVw
by9jZXJ0cy9ndHMxYzMuZGVyMIIChgYDVR0RBIICfTCCAnmCDW14Lmdvb2dsZS5j
b22CD3NtdHAuZ29vZ2xlLmNvbYISYXNwbXgubC5nb29nbGUuY29tghdhbHQxLmFz
cG14LmwuZ29vZ2xlLmNvbYIXYWx0Mi5hc3BteC5sLmdvb2dsZS5jb22CF2FsdDMu
YXNwbXgubC5nb29nbGUuY29tghdhbHQ0LmFzcG14LmwuZ29vZ2xlLmNvbYIaZ21h
aWwtc210cC1pbi5sLmdvb2dsZS5jb22CH2FsdDEuZ21haWwtc210cC1pbi5sLmdv
b2dsZS5jb22CH2FsdDIuZ21haWwtc210cC1pbi5sLmdvb2dsZS5jb22CH2FsdDMu
Z21haWwtc210cC1pbi5sLmdvb2dsZS5jb22CH2FsdDQuZ21haWwtc210cC1pbi5s
Lmdvb2dsZS5jb22CGGdtci1zbXRwLWluLmwuZ29vZ2xlLmNvbYIdYWx0MS5nbXIt
c210cC1pbi5sLmdvb2dsZS5jb22CHWFsdDIuZ21yLXNtdHAtaW4ubC5nb29nbGUu
Y29tgh1hbHQzLmdtci1zbXRwLWluLmwuZ29vZ2xlLmNvbYIdYWx0NC5nbXItc210
cC1pbi5sLmdvb2dsZS5jb22CDW14MS5zbXRwLmdvb2eCDW14Mi5zbXRwLmdvb2eC
DW14My5zbXRwLmdvb2eCDW14NC5zbXRwLmdvb2eCFWFzcG14Mi5nb29nbGVtYWls
LmNvbYIVYXNwbXgzLmdvb2dsZW1haWwuY29tghVhc3BteDQuZ29vZ2xlbWFpbC5j
b22CFWFzcG14NS5nb29nbGVtYWlsLmNvbYIRZ21yLW14Lmdvb2dsZS5jb20wIQYD
VR0gBBowGDAIBgZngQwBAgEwDAYKKwYBBAHWeQIFAzA8BgNVHR8ENTAzMDGgL6At
hitodHRwOi8vY3Jscy5wa2kuZ29vZy9ndHMxYzMvUU92SjBOMXNUMkEuY3JsMIIB
AwYKKwYBBAHWeQIEAgSB9ASB8QDvAHUAejKMVNi3LbYg6jjgUh7phBZwMhOFTTvS
K8E6V6NS61IAAAGHRm4lhwAABAMARjBEAiAbFYSOoxVgUmcJ//sPa+hYjV4DrVfp
I3BK/Z6oBCwARQIgKKWKSA17g7eWZarLagY5oG4P+UxzBZd5uJHM+nj379IAdgDo
PtDaPvUGNTLnVyi8iWvJA9PL0RFr7Otp4Xd9bQa9bgAAAYdGbiVNAAAEAwBHMEUC
IQDINMfMYnK9vpptQYj9Ve6EOYa26GZV2TaM4Sw7J30ZkwIgSB8GtydIcaC+2pgJ
EifKh9ZkJvY/o6L24amB1gFUxIswDQYJKoZIhvcNAQELBQADggEBAAnbG+WzOmkA
FqJGasrOMQGIcLwfHSwEAeAjuQOCVxZ8I0e3bKV3+4jLMDEXz9SkhTCXq57p9pWu
YorP5fPlR9+5Z2cCCCbFU5sHXRsZ3olFqVIbTqtN0pxAOFSKah85KnEq2cMSeQ6j
fhhFT41nLvd+QotH5vYh0IUnSgEOGnOxNfgc/Ixk75ENZ7GBZopWzIQ75J+X8RE6
j/SC42wunfCeR6xywhlpDg70mwjLP6QslX/JHfsR6pg+MLyTgmrTincbWeStauvN
G2JZkth9MeorZoTmyx+vooeKQgIV8PKRs5Llc+lSjA4b9wlJNHA9hMd5mBRZL291
oMYlrLxMli8=
-----END CERTIFICATE-----
subject=CN = mx.google.com

issuer=C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5201 bytes and written 423 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 SMTPUTF8
DONE

您可以新增-showcerts以取得鏈中的所有憑證。

答案2

我處理證書驗證問題的通用方法是：

  1. 使用 tcpdump 或類似工具進行網路捕獲
  2. 在 Wireshark 中開啟擷取並右鍵單擊SSL/TLS 警報資料包並選擇Follow->TCP stream
  3. 檢查X509證書：
    • 日期（目前日期是在簽發日期和到期日期之間嗎？）
    • 主題（客戶端使用的主機名稱與 CN= 欄位相同？）
    • 主題備用名稱（類似主題）
    • 約束條件
    • 中間證書（所有中間證書都在主機證書之後提供嗎？它們有效嗎？）

通常是缺少中間憑證導致此類問題（某些客戶端不驗證伺服器的憑證）。

答案3

事實證明，在 Wireshark 中捕獲和分析 TLS 協商是這裡的關鍵，它讓我發現 ISP (Comcast) 拒絕了我的網域證書，儘管事實上互聯網上幾乎所有其他發件人都接受它。

進一步調查發現，相關郵件伺服器的 TLSA 記錄已過期，且 Comcast 由於 TLSA 不符而拒絕該證書。

不幸的是，TLS 協商中可用的錯誤機制沒有為發送者提供一種方法來告訴接收者憑證被拒絕的原因。也許 TLS 1.4 可以針對 DANE 憑證不符定義特定警報。

相關內容