☰

sendmail: Server zeigt Fehler aufgrund eines fehlerhaften Client-Zertifikats

tag-icon • tag-icon ssl email sendmail
sendmail: Server zeigt Fehler aufgrund eines fehlerhaften Client-Zertifikats

Mein Sendmail-Server (FreeBSD, kompiliert mit OpenSSL) weigert sich, TLS mit einer bestimmten Gruppe von Clients auszuhandeln.

Protokollmeldungen sehen folgendermaßen aus:

sm-mta[92474]: STARTTLS=Server, Fehler: Annahme fehlgeschlagen=-1, Grund=sslv3-Warnung, ungültiges Zertifikat, SSL_error=1, errno=0, Wiederholung=-1, Relay=xx.example.com [XX.XX.XX.XX]

Abgesehen von diesen Störungen, die ihren Ursprung in der Mail-Infrastruktur eines namhaften Internetanbieters haben, funktioniert alles einwandfrei; das Zertifikat auf dem Server selbst ist aktuell und gültig.

Zwei Fragen, eine Antwort auf eine der beiden wäre hilfreich:

  1. Wie kann ich das diagnostizieren? Kann ich insbesondere aus der Sendmail-Umgebung heraus eine Kopie des fehlerhaften Zertifikats abrufen?
  2. Kann ich meine Sendmail-Konfiguration aktualisieren, um den Clients entweder mitzuteilen, dass sie kein Zertifikat bereitstellen sollen, oder um Sendmail anzuweisen, ein gefälschtes Client-Zertifikat zu akzeptieren?

Danke!

EDIT: Ich habe das Problem hier gefunden, nämlich dass das Zertifikat meines Servers nicht mit dem DANE TLSA-Eintrag meines Servers übereinstimmte. Ein Blick auf eine Wireshark-Dekodierung der Transaktion zeigte, dass der ISP (Comcast) mein gültiges Zertifikat zwar empfing, es aber trotzdem ablehnte, und es stellte sich heraus, dass der TLSA-Eintrag nicht synchronisiert war. Es sieht so aus, als ob Comcast einer der wenigen E-Mail-Absender im Internet sein könnte, der nach einem DANE-Verifizierungsfehler den Versand verweigert.

Antwort1

Sie können OpenSSL verwenden, um den Remote-Server abzufragen. So können Sie beispielsweise das Zertifikat auf einem der Mailserver von Google anzeigen:

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

sollte ungefähr Folgendes anzeigen:

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

Sie können -showcertsalle Zertifikate in der Kette hinzufügen, um sie abzurufen.

Antwort2

Meine allgemeine Vorgehensweise beim Problem der Zertifikatsvalidierung ist:

  1. Machen Sie eine Netzwerkaufzeichnung mit tcpdump oder ähnlichem
  2. Öffnen Sie die Aufnahme in Wireshark und klicken Sie mit der rechten Maustaste aufSSL/TLS-ALARMPaket und wähle Follow->TCP stream
  3. Überprüfen Sie das X509-Zertifikat:
    • Daten (liegt das aktuelle Datum zwischen Ausstellungsdatum und Ablaufdatum?)
    • Betreff (ist der vom Client verwendete Hostname derselbe wie im Feld „CN=“?)
    • Alternativer Betreffname (ähnlich wie Betreff)
    • Einschränkungen
    • Zwischenzertifikate (werden alle Zwischenzertifikate nach dem Host-Zertifikat vorgelegt? Sind diese gültig?)

Normalerweise wird dieses Problem durch ein fehlendes Zwischenzertifikat verursacht (einige Clients validieren das Zertifikat Ihres Servers nicht).

Antwort3

Es stellte sich heraus, dass das Erfassen und Analysieren der TLS-Aushandlung in Wireshark hier der Schlüssel war, und so fand ich heraus, dass der ISP (Comcast) mein Domänenzertifikat ablehnte, obwohl fast jeder andere Absender im Internet es akzeptierte.

Weitere Untersuchungen ergaben, dass der TLSA-Eintrag für den betreffenden Mailserver veraltet war und dass Comcast das Zertifikat aufgrund einer TLSA-Nichtübereinstimmung ablehnte.

Leider bieten die Fehlermechanismen bei der TLS-Aushandlung dem Absender keine Möglichkeit, dem Empfänger mitzuteilen, warum das Zertifikat abgelehnt wurde. Vielleicht kann TLS 1.4 einen speziellen Alarm für DANE-Zertifikatskonflikte definieren.

verwandte Informationen