☰

sendmail: クライアント証明書が不正なためサーバーが失敗を表示する

tag-icon • tag-icon ssl email sendmail
sendmail: クライアント証明書が不正なためサーバーが失敗を表示する

私の sendmail サーバー (FreeBSD、OpenSSL に対してコンパイル) は、特定のクライアント セットとの TLS ネゴシエーションを拒否しています。

ログメッセージは次のようになります。

sm-mta[92474]: STARTTLS=server、エラー: 受け入れ失敗=-1、理由=sslv3 アラート不正証明書、SSL_error=1、errno=0、再試行=-1、リレー=xx.example.com [XX.XX.XX.XX]

よく知られている ISP のメール インフラストラクチャに起因するこれらの障害以外はすべて正常に動作しており、サーバー自体の証明書は最新かつ有効です。

2 つの質問があり、どちらかの回答が役立つと思います。

  1. これを診断するにはどうすればよいでしょうか? 特に、sendmail 環境内から不正な証明書のコピーを取得できますか?
  2. sendmail の設定を更新して、クライアントに証明書を提供しないように指示するか、または sendmail に偽のクライアント証明書を受け入れるように指示できますか?

ありがとう！

編集: ここで問題を見つけました。サーバーの証明書がサーバーの DANE TLSA レコードと一致しないという問題です。トランザクションの Wireshark デコードを見ると、ISP (Comcast) が有効な証明書を受信して​​いるものの、とにかく拒否していることがわかり、TLSA レコードが同期されていないことが判明しました。Comcast は、DANE 検証の失敗後に送信を拒否するインターネット上の数少ない電子メール送信者の 1 つである可能性があります。

答え1

OpenSSL を使用してリモート サーバーを照会できます。たとえば、Google のメール サーバーの 1 つにある証明書を表示するには、次のようにします。

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 証明書の不一致に関する特定のアラートを定義できるでしょう。

関連情報