24
Email Fehler: SSL verify error: certificate name mismatch: DN CN H
Hallo zusammen,
in unserem Email-Log sehen wir folgende Einträge:
Fehler: 2024-08-26 19:18:12 [<IP>] SSL verify error: certificate name mismatch: DN="/CN=*.your-server.de"
Wir selbst hosten bei Hetzner und können ansonsten problemlos mit allen Kunden und Lieferanten per Email kommunizieren.
Kann es sein, dass das SSL-Problem eher beim Absender dieser Email liegt?
Die Webseite seiner Domain verwendet ein gültiges Let's Encrypt - Zertifikat und funktioniert tadellos. Wie kann es dann sein, dass angeblich sein SSL-Zertifikat nicht stimmen soll?
Inwiefern kann er sein SSL-Zertifikat überprüfen und korrigieren? Wenn ich ihm nur sage "... dein Zertifikat ist ungültig, erneuere es", dann versteht er nur Bahnhof. Es wäre gut, wenn ich das etwas genauer und technischer ausdrücken könnte, so dass er weiß, wo er schauen muss.
Danke für jeden hilfreichen Tipp!
in unserem Email-Log sehen wir folgende Einträge:
Fehler: 2024-08-26 19:18:12 [<IP>] SSL verify error: certificate name mismatch: DN="/CN=*.your-server.de"
Wir selbst hosten bei Hetzner und können ansonsten problemlos mit allen Kunden und Lieferanten per Email kommunizieren.
Kann es sein, dass das SSL-Problem eher beim Absender dieser Email liegt?
Die Webseite seiner Domain verwendet ein gültiges Let's Encrypt - Zertifikat und funktioniert tadellos. Wie kann es dann sein, dass angeblich sein SSL-Zertifikat nicht stimmen soll?
Inwiefern kann er sein SSL-Zertifikat überprüfen und korrigieren? Wenn ich ihm nur sage "... dein Zertifikat ist ungültig, erneuere es", dann versteht er nur Bahnhof. Es wäre gut, wenn ich das etwas genauer und technischer ausdrücken könnte, so dass er weiß, wo er schauen muss.
Danke für jeden hilfreichen Tipp!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667664
Url: https://administrator.de/contentid/667664
Ausgedruckt am: 19.10.2024 um 15:10 Uhr
24 Kommentare
Neuester Kommentar
Ich verstehe gerade auch nur Bahnhof und ich administriere Mailserver...
Ihr sendet eine E-Mail an einen bestimmten Empfänger und...
Dann kommt die nicht an? Ihr bekommt die als unzustellbar zurück? Die kommen an, aber es gibt Fehlermeldungen? Was sehe ich da überhaupt im Screenshot? Was passiert?
Ihr sendet eine E-Mail an einen bestimmten Empfänger und...
Dann kommt die nicht an? Ihr bekommt die als unzustellbar zurück? Die kommen an, aber es gibt Fehlermeldungen? Was sehe ich da überhaupt im Screenshot? Was passiert?
4
Einer unserer Lieferant behauptet uns Emails geschickt zu haben, die wir nie bekamen. Im Email-Log sieht man tatsächlich, dass er uns welche geschickt hat mit dem erwähnten Fehler.
Er selbst bekam keinen Fehler zurück. Theoretisch ist es nur eine Warnung, aber offensichtlich geht sie bei dem Dovecot-System bei Hetzner nicht weiter.
Wenn man nach dem Fehler googelt findet man etwas wie
Es ist ein allgemeiner Fehler und ich vermute dass mit dem SSL-Zertifikat bei unserem Lieferanten was nicht stimmt. Aber es geht doch nicht um dessen Webseite sondern um Emails?
Wie kommt man nun an die Ursache, wo muss man hin?
Er selbst bekam keinen Fehler zurück. Theoretisch ist es nur eine Warnung, aber offensichtlich geht sie bei dem Dovecot-System bei Hetzner nicht weiter.
Wenn man nach dem Fehler googelt findet man etwas wie
Falls der Domänenname (FQDN) im TLS/SSL-Zertifikat nicht mit dem Domänenname in der Adresszeile des Browsers übereinstimmt, bricht der Browser die Verbindung mit der Website ab und meldet einen Namensfehler
Es ist ein allgemeiner Fehler und ich vermute dass mit dem SSL-Zertifikat bei unserem Lieferanten was nicht stimmt. Aber es geht doch nicht um dessen Webseite sondern um Emails?
Wie kommt man nun an die Ursache, wo muss man hin?
Moin,
Wie @LordGurke schon schrieb: es fehlen Infos.
Was mir aber spontan einfällt:
Ferner: im Screenshot steht: your-Server.de
Die Domain gibt es zwar, aber etwas unbedarft würde ich behaupten, dass man beim erstellen des Zertifikats ein 1:1 Copy & Paste einer Anleitung gemacht hat, ohne die relevanten Stellen anzupassen.
Wie @LordGurke schon schrieb: es fehlen Infos.
Was mir aber spontan einfällt:
Die Webseite seiner Domain verwendet ein gültiges Let's Encrypt - Zertifikat
Das ist zwar schön, aber welches Zertifikat nutzt der Mail-Server?Ferner: im Screenshot steht: your-Server.de
Die Domain gibt es zwar, aber etwas unbedarft würde ich behaupten, dass man beim erstellen des Zertifikats ein 1:1 Copy & Paste einer Anleitung gemacht hat, ohne die relevanten Stellen anzupassen.
1
Moin @em-pie,
ich bin nicht der Admin des Webhosting unseres Lieferanten, aber wir möchten ihm einen technischen Hinweis geben, warum seine Emails nicht zu uns durchkommen.
Sehe ich es richtig, dass der Fehler in unserem Email-Log
Welche Infos fehlen, damit ihr mir in der Sache weiterhelfen könnt?
your-server.de ist Hetzner, wo wir gehostet haben. Kann es sein, dass unser Lieferant ebenfalls dort hostet?
Könnt ihr mir mit den Daten in der Fehlermeldung weiterhelfen?
DN=Distinguished Name?
CN=Common Name?
H=?
Was bedeutet das genau?
In den weichgezeichneten Feldern stehen die Domains und IPs, möchte ich nur ungern hier posten (wenn's weiterhilft per private Message?)
ich bin nicht der Admin des Webhosting unseres Lieferanten, aber wir möchten ihm einen technischen Hinweis geben, warum seine Emails nicht zu uns durchkommen.
Sehe ich es richtig, dass der Fehler in unserem Email-Log
2024-08-26 19:18:12 [<IP>] SSL verify error: certificate name mismatch: DN="/CN=*.your-server.de"
jedoch im SSL-Zertifikat seines Email-Servers liegt?Welche Infos fehlen, damit ihr mir in der Sache weiterhelfen könnt?
your-server.de ist Hetzner, wo wir gehostet haben. Kann es sein, dass unser Lieferant ebenfalls dort hostet?
Könnt ihr mir mit den Daten in der Fehlermeldung weiterhelfen?
DN=Distinguished Name?
CN=Common Name?
H=?
Was bedeutet das genau?
In den weichgezeichneten Feldern stehen die Domains und IPs, möchte ich nur ungern hier posten (wenn's weiterhilft per private Message?)
Das Zertifikat eures Lieferanten hat da nichts mit zu tun. Wenn man euch eine E-Mail schickt muss nur euer Mailserver ein Zertifikat zeigen.
Wie lautet denn euer MX-Record? Auch auf irgendwas unter "your-server.de" oder habt ihr da eure eigene Domain drin stehen?
Wie lautet denn euer MX-Record? Auch auf irgendwas unter "your-server.de" oder habt ihr da eure eigene Domain drin stehen?
Ich würde mal behaupten im MX Record eurer Firma steht sowas wie mail.diefirma.de. Aber der SMTP-Server liefert ein Zertifikat auf *.your-server.de.
Das ist der Mismatch.
Einige MTAs ignorieren das. Andere halt nicht.
Hier gibt es einen sehr detailierten Test für Mail-Server mit Zertifikatsprüfung: https://www.checktls.com/
Aber Achtung: Diese Tests lösen normalerweise bei öfterem Gebrauch Fehlermeldungen auf dem Mailserver aus und diese führen dann zu einer IP-Sperre. Also nicht wundern, wenn nach einer Weile die Tests nicht mehr gehen. Ich muss für solche Tests jeweils Fail2Ban ausschalten.
Das ist der Mismatch.
Einige MTAs ignorieren das. Andere halt nicht.
Hier gibt es einen sehr detailierten Test für Mail-Server mit Zertifikatsprüfung: https://www.checktls.com/
Aber Achtung: Diese Tests lösen normalerweise bei öfterem Gebrauch Fehlermeldungen auf dem Mailserver aus und diese führen dann zu einer IP-Sperre. Also nicht wundern, wenn nach einer Weile die Tests nicht mehr gehen. Ich muss für solche Tests jeweils Fail2Ban ausschalten.
Hi @LordGurke und @HansFenner,
es ist alles ein wenig anders
Im Screenshot oben vom Maillog geht der blaue Pfeil von sslproxy04.your-server.de nach links, d.h. es wurde eine Email von uns rausgeschickt an unseren Lieferanten. Und dabei tritt immer der SSL verify - Fehler auf. Jedoch passiert das zu anderen Kunden oder Lieferanten nicht.
Dennoch geht die Email durch, es ist eine Warnung und er bekommt sie. Wäre schön wenn wir das trotzdem irgendwie beheben können. In unserem Hetzner Account kann man nur für die Domains/Subdomains SSL-Zertifikate einstellen. Bei den Emails nicht, dort ist lediglich was mit DKIM und alles gemacht und grün.
Unser MX-Record ist auf "www<bla>.your-server.de." (das <bla> ist eine Zahl...) gesetzt, was unser eigener managed Server ist. Sollte alles passen, weil mit anderen Kunden keinerlei Probleme auftreten.
Daher ist die Vermutung leider falsch, dass im MX-Record unsere eigene Domain steht. Weitere Ideen?
Habt Ihr eine Idee, an welcher Stelle etwas mit dem SSL-Zertifikat nicht stimmen könnte? Wo schaut man da nach, wo findet man was zu dem "Email"-SSL-Zertifikat wo angeblich der Domainname nicht stimmen soll?
Die Ursache des Ursprungsproblems, dass die Email unseres Lieferanten nicht zu uns durchkommt ist wie folgt:
Sowohl unser Lieferant als auch wir waren bis vor einem Monat auf dem gleichen Dedicated-Server von Hetzner gehostet. Jetzt sind wir umgezogen, jedoch läuft das Mailsystem und der ganze Account von uns auf dem Dedicated - Server noch weiter. Es wird gewarnt, dass z.B. der MX-Record woanders hinzeigt, jedoch die interne Mailzustellung noch funktioniert.
D.h. wenn uns unser Lieferant eine Email sendet, denkt der Dedicated-Server es ist eine interne Zustellung (gleicher Server, gleiches Hosting...) und stellt es dort zu. Wir kommen aber nicht mehr in dieses Email-System rein, weil man sich bei Hetzner nur allgemein in webmail.your-server.de/login.php einloggen kann und wir damit in unserem aktuellen Webmail-Emailsystem landen. (Mit IMAP, POP3 nicht anders, da gleiche Domains).
Mein Weg, die Emails aus dem alten Mailsystem herauszubekommen war, mich per FTP dort einzuloggen (das sind zum Glück andere Zugangsdaten als unser aktueller FTP-Login), ins vmail/-Verzeichnis reinzugehen und dort in den Postfix-Dovecot-Ordners die Emaildateien runterzuladen und in unserem aktuellen FTP die Dovecot-Dateien wieder hochzuladen.
Eine ziemlich verzwickte Sache, aber das wird sich bald lösen, denn zum einen wird unser Lieferant das Hosting wechseln und zum anderen sind wir dran, unseren Account und auch das alte Emailsystem im erwähnten Dedicated-Server zu deaktiveren und zu löschen.
Würde mich sehr freuen, wenn noch jemand eine Idee zu der SSL-Warnung hat. Darf ich noch weitere Infos liefern, die hilfreich sind?
@HansFenner: Traue mich nicht so recht, den checktls-Test zu machen. Der MTA müsste doch der gleiche sein, wenn unser Lieferant ebenfalls auf einem Dedicated-Server von Hetzner ist? Hast Du eine Idee, wo man dem falschen SSL-Zertifikat nachgehen und einsehen/ändern kann?
es ist alles ein wenig anders
Im Screenshot oben vom Maillog geht der blaue Pfeil von sslproxy04.your-server.de nach links, d.h. es wurde eine Email von uns rausgeschickt an unseren Lieferanten. Und dabei tritt immer der SSL verify - Fehler auf. Jedoch passiert das zu anderen Kunden oder Lieferanten nicht.
Dennoch geht die Email durch, es ist eine Warnung und er bekommt sie. Wäre schön wenn wir das trotzdem irgendwie beheben können. In unserem Hetzner Account kann man nur für die Domains/Subdomains SSL-Zertifikate einstellen. Bei den Emails nicht, dort ist lediglich was mit DKIM und alles gemacht und grün.
Unser MX-Record ist auf "www<bla>.your-server.de." (das <bla> ist eine Zahl...) gesetzt, was unser eigener managed Server ist. Sollte alles passen, weil mit anderen Kunden keinerlei Probleme auftreten.
Daher ist die Vermutung leider falsch, dass im MX-Record unsere eigene Domain steht. Weitere Ideen?
Habt Ihr eine Idee, an welcher Stelle etwas mit dem SSL-Zertifikat nicht stimmen könnte? Wo schaut man da nach, wo findet man was zu dem "Email"-SSL-Zertifikat wo angeblich der Domainname nicht stimmen soll?
Die Ursache des Ursprungsproblems, dass die Email unseres Lieferanten nicht zu uns durchkommt ist wie folgt:
Sowohl unser Lieferant als auch wir waren bis vor einem Monat auf dem gleichen Dedicated-Server von Hetzner gehostet. Jetzt sind wir umgezogen, jedoch läuft das Mailsystem und der ganze Account von uns auf dem Dedicated - Server noch weiter. Es wird gewarnt, dass z.B. der MX-Record woanders hinzeigt, jedoch die interne Mailzustellung noch funktioniert.
D.h. wenn uns unser Lieferant eine Email sendet, denkt der Dedicated-Server es ist eine interne Zustellung (gleicher Server, gleiches Hosting...) und stellt es dort zu. Wir kommen aber nicht mehr in dieses Email-System rein, weil man sich bei Hetzner nur allgemein in webmail.your-server.de/login.php einloggen kann und wir damit in unserem aktuellen Webmail-Emailsystem landen. (Mit IMAP, POP3 nicht anders, da gleiche Domains).
Mein Weg, die Emails aus dem alten Mailsystem herauszubekommen war, mich per FTP dort einzuloggen (das sind zum Glück andere Zugangsdaten als unser aktueller FTP-Login), ins vmail/-Verzeichnis reinzugehen und dort in den Postfix-Dovecot-Ordners die Emaildateien runterzuladen und in unserem aktuellen FTP die Dovecot-Dateien wieder hochzuladen.
Eine ziemlich verzwickte Sache, aber das wird sich bald lösen, denn zum einen wird unser Lieferant das Hosting wechseln und zum anderen sind wir dran, unseren Account und auch das alte Emailsystem im erwähnten Dedicated-Server zu deaktiveren und zu löschen.
Würde mich sehr freuen, wenn noch jemand eine Idee zu der SSL-Warnung hat. Darf ich noch weitere Infos liefern, die hilfreich sind?
@HansFenner: Traue mich nicht so recht, den checktls-Test zu machen. Der MTA müsste doch der gleiche sein, wenn unser Lieferant ebenfalls auf einem Dedicated-Server von Hetzner ist? Hast Du eine Idee, wo man dem falschen SSL-Zertifikat nachgehen und einsehen/ändern kann?
Moin,
Gruß,
Dani
Im Screenshot oben vom Maillog geht der blaue Pfeil von sslproxy04.your-server.de nach links, d.h. es wurde eine Email von uns rausgeschickt an unseren Lieferanten. Und dabei tritt immer der SSL verify - Fehler auf.
kann es sein, dass euere Mail-/SMTP Proxy nicht mit einem Wildcard SSL-Zertifikat klar kommt?!Gruß,
Dani
Hi @Dani,
weiß ich nicht, weil das sind nur sehr wenige ausgehende Emails, wo der Fehler auftritt.
Du meinst, weil da *.your-server.de steht?
Woher kommt das SSL-Zertifikat und wer erstellt es?
Bei unserem Hetzner-Account kann man nur für die Webseite das SSL-Zertifikat erstellen, was ja nichts mit Email zu tun hat. Und bei Email gibt's nur sowas wie DKIM, was auch nichts mit SSL zu tun hat?
Oder sind das Zertifikate, die die Server unter sich ausmachen und man gar kein Einfluss darauf hat?
weiß ich nicht, weil das sind nur sehr wenige ausgehende Emails, wo der Fehler auftritt.
Du meinst, weil da *.your-server.de steht?
Woher kommt das SSL-Zertifikat und wer erstellt es?
Bei unserem Hetzner-Account kann man nur für die Webseite das SSL-Zertifikat erstellen, was ja nichts mit Email zu tun hat. Und bei Email gibt's nur sowas wie DKIM, was auch nichts mit SSL zu tun hat?
Oder sind das Zertifikate, die die Server unter sich ausmachen und man gar kein Einfluss darauf hat?
Im ersten Post hast du DN/CN mit *.your-server.de angegeben und H ist ausgegraut, trotzdem kann man es noch ein bisschen lesen. Das H hat ein Format mail.?????.de.
Beides passt aber nicht zusammen. Die ????? müssten your-server sein, das ist, soweit ich das erkenne, nicht der Fall.
Das ist der Mismatch Fehler = Es match/passt nicht zusammen.
Ist die ausgegraute H Domain diejenige des Lieferanten? Wenn der Lieferant auch bei Hetzner hostet hat er ev. was falsch eingestellt. Im allgemeinen ignorieren MTA aber solche Fehler, schlicht, weil falsch eingestellte Mail-Server und Zertifikate zu oft vorkommen ;) Man könnte aber von Warnung auf Fehler einstellen.
Nachtrag:
Wieso nicht den Test auf https://www.checktls.com/ machen? Es kommt aber schon drauf an, ob ihr eure Domain oder die Domain vom Lieferanten beim Test einsetzt, auch wenn beide bei Hetzner sind. Am besten mal beides prüfen. Das Resultat ist wirklich sehr detailliert.
Und noch ein Nachtrag:
https://support.cpanel.net/hc/en-us/articles/360050811693-Exim-logs-erro ...
Man kann es also ignorieren. Trotzdem denke ich, es ist unschön
Beides passt aber nicht zusammen. Die ????? müssten your-server sein, das ist, soweit ich das erkenne, nicht der Fall.
Das ist der Mismatch Fehler = Es match/passt nicht zusammen.
Ist die ausgegraute H Domain diejenige des Lieferanten? Wenn der Lieferant auch bei Hetzner hostet hat er ev. was falsch eingestellt. Im allgemeinen ignorieren MTA aber solche Fehler, schlicht, weil falsch eingestellte Mail-Server und Zertifikate zu oft vorkommen ;) Man könnte aber von Warnung auf Fehler einstellen.
Nachtrag:
Wieso nicht den Test auf https://www.checktls.com/ machen? Es kommt aber schon drauf an, ob ihr eure Domain oder die Domain vom Lieferanten beim Test einsetzt, auch wenn beide bei Hetzner sind. Am besten mal beides prüfen. Das Resultat ist wirklich sehr detailliert.
Und noch ein Nachtrag:
https://support.cpanel.net/hc/en-us/articles/360050811693-Exim-logs-erro ...
Man kann es also ignorieren. Trotzdem denke ich, es ist unschön
In H= steht der Email-Server unseres Lieferanten: "mail.<seine-domain>.de"
Warum muss in H= die gleiche Domain stehen wie in DN/CN?
Ist es nicht völlig normal, dass wir eine andere Email-Domain haben als unser Lieferant (und überhaupt alle externen Email-Kontakte?)
Ja, unser Lieferant ist auch bei Hetzner. Inwiefern hat er was falsch eingestellt? Soll er etwa die gleiche Domain wie wir nutzen?
Als Antwort auf meine Email an test@testsender.checktls.com bekam ich:
Alles super, und trotzdem der SSL-Fehler?
Oder heißt das, bei uns stimmt alles, sondern beim anderen Email-Server passt was nicht?
Es gibt übrigens noch weitere Kunden, bei denen das gleiche ist, daher nicht ganz unwichtig das Thema.
Warum muss in H= die gleiche Domain stehen wie in DN/CN?
Ist es nicht völlig normal, dass wir eine andere Email-Domain haben als unser Lieferant (und überhaupt alle externen Email-Kontakte?)
Ja, unser Lieferant ist auch bei Hetzner. Inwiefern hat er was falsch eingestellt? Soll er etwa die gleiche Domain wie wir nutzen?
Als Antwort auf meine Email an test@testsender.checktls.com bekam ich:
Just a reminder that CheckTLS.com (and these tests) are NOT free. Please support us, thank you.
SUCCESSFUL //email/test From:
Your email was sent securely using TLS.
SUCCESSFUL //email/test From:
Your email was sent securely using TLS.
Alles super, und trotzdem der SSL-Fehler?
Oder heißt das, bei uns stimmt alles, sondern beim anderen Email-Server passt was nicht?
Es gibt übrigens noch weitere Kunden, bei denen das gleiche ist, daher nicht ganz unwichtig das Thema.
Bei checktls.com kannst du hier eine Mailserver-Domain prüfen: Check How You Get Email (Receiver Test)
Das ist das obere Eingabe Feld und dann Check it klicken. Ich würde mal <seine-domain>.de testen.
Und jetzt ist halt auch die Frage, ob es eine Warnung oder ein Fehler ist.
Das H sollte der Hostname des Mailserver sein. Ggf. sollte auch die HELO- Domain und die Reverse PTR Domain die gleiche sein. Dieser Domainname muss mit der Domain CN im Zertifikat übereinstimmen, sonst macht das Ganze ja gar keinen Sinn.
Aber ein Mailserver kann natürlich beliebig viele Domain-Postfächer hosten. Diese müssen nicht im Server-Zertifikat sein.
Ich bin nicht sicher, ob im MX Record von seine-domain.de explizit mail.seine-domain.de oder irgendwas.your-server.de stehen muss. Meine Meinung nach ist das unwichtig, wenn beides zur richtigen IP auflösen. Aber sicher bin ich mir nicht.
Ansonsten ist es halt doch nur eine Warnung, dass boss@seine-domain.de nicht mit dem Mailservernamen im Zertifikat von your-server.de übereinstimmt. Finde ich halt sehr seltsam, weil das ja meistens der Fall ist.
NACHTRAG:
Ok, habs grad getested. Wenn im MX Record nicht die Domain eingetragen ist, welche im Zertifikat angegeben ist, kommt es genau zu diesem Fehler.
-> Cert Hostname DOES NOT VERIFY
Eurer Lieferant muss im MX Record eine ???.your-server.de Domain eintragen und nicht mail.seine-domain.de, auch wenn beide auf die gleiche IP zeigen.
Wenn man ein bisschen länger darüber nachdenkt, macht das sogar Sinn
Noch ein Nachtrag:
Alternativ kann der Lieferant auch dafür sorgen, dass der Mailserver ein korrektes Zertifikat auf seine Firmendomain liefert. Mailserver können das passende Zertifikat über SNI auswählen (was ich bis heute auch nicht wusste).
https://medium.com/better-coder/postfix-multiple-domain-ssl-certificates ...
Das ist das obere Eingabe Feld und dann Check it klicken. Ich würde mal <seine-domain>.de testen.
Und jetzt ist halt auch die Frage, ob es eine Warnung oder ein Fehler ist.
Das H sollte der Hostname des Mailserver sein. Ggf. sollte auch die HELO- Domain und die Reverse PTR Domain die gleiche sein. Dieser Domainname muss mit der Domain CN im Zertifikat übereinstimmen, sonst macht das Ganze ja gar keinen Sinn.
Aber ein Mailserver kann natürlich beliebig viele Domain-Postfächer hosten. Diese müssen nicht im Server-Zertifikat sein.
Ich bin nicht sicher, ob im MX Record von seine-domain.de explizit mail.seine-domain.de oder irgendwas.your-server.de stehen muss. Meine Meinung nach ist das unwichtig, wenn beides zur richtigen IP auflösen. Aber sicher bin ich mir nicht.
Ansonsten ist es halt doch nur eine Warnung, dass boss@seine-domain.de nicht mit dem Mailservernamen im Zertifikat von your-server.de übereinstimmt. Finde ich halt sehr seltsam, weil das ja meistens der Fall ist.
NACHTRAG:
Ok, habs grad getested. Wenn im MX Record nicht die Domain eingetragen ist, welche im Zertifikat angegeben ist, kommt es genau zu diesem Fehler.
-> Cert Hostname DOES NOT VERIFY
Eurer Lieferant muss im MX Record eine ???.your-server.de Domain eintragen und nicht mail.seine-domain.de, auch wenn beide auf die gleiche IP zeigen.
Wenn man ein bisschen länger darüber nachdenkt, macht das sogar Sinn
Noch ein Nachtrag:
Alternativ kann der Lieferant auch dafür sorgen, dass der Mailserver ein korrektes Zertifikat auf seine Firmendomain liefert. Mailserver können das passende Zertifikat über SNI auswählen (was ich bis heute auch nicht wusste).
https://medium.com/better-coder/postfix-multiple-domain-ssl-certificates ...
Hey, danke für die ausführliche Antwort.
Wenn ich bei checktls.com unsere Domain (natürlich der MX-Record) teste, sieht alles gut aus:
Bei der Domain unseres Lieferanten dagegen kommt genau der Fehler:
Daher eindeutig das SSL-Zertifikat auf dem Emailserver unseres Lieferanten falsch, weil seine Domain drinsteht, aber die Hetzner-Adresse mit your-server.de drinstehen sollten?
Danke für den Hinweis mit "Postfix — Multiple domain SSL certificates". Leider ist das zu technisch, unser Lieferant wird allenfalls das KonsoleH von Hetzner bedienen können. Bei postfix versteht er nur Bahnhof.
Bleibt die Frage, inwiefern er mit einem Hetzner-Account überhaupt das SSL-Zertifikat für seinen Emailserver ändern kann?
Wir sind auch bei Hetzner und wie erwähnt finde ich das nur für die Webseite ("SSL Manager", dort nur Domains und Subdomains). Bei den Emaileinstellungen allenfalls etwas mit DKIM, SPF oder DMARC.
Ebenfalls gibt es weitere Kunden mit der gleichen Warnung. Da wir nicht die IT unserer Email-Partner administrieren, werden wir wohl mit der Warnung leben müssen
Wenn ich bei checktls.com unsere Domain (natürlich der MX-Record) teste, sieht alles gut aus:
Bei der Domain unseres Lieferanten dagegen kommt genau der Fehler:
Daher eindeutig das SSL-Zertifikat auf dem Emailserver unseres Lieferanten falsch, weil seine Domain drinsteht, aber die Hetzner-Adresse mit your-server.de drinstehen sollten?
Danke für den Hinweis mit "Postfix — Multiple domain SSL certificates". Leider ist das zu technisch, unser Lieferant wird allenfalls das KonsoleH von Hetzner bedienen können. Bei postfix versteht er nur Bahnhof.
Bleibt die Frage, inwiefern er mit einem Hetzner-Account überhaupt das SSL-Zertifikat für seinen Emailserver ändern kann?
Wir sind auch bei Hetzner und wie erwähnt finde ich das nur für die Webseite ("SSL Manager", dort nur Domains und Subdomains). Bei den Emaileinstellungen allenfalls etwas mit DKIM, SPF oder DMARC.
Ebenfalls gibt es weitere Kunden mit der gleichen Warnung. Da wir nicht die IT unserer Email-Partner administrieren, werden wir wohl mit der Warnung leben müssen
Der Link zu Postfix war eigentlich mehr ein Beweis, dass es SNI auch für Mail-Server gibt und nicht nur für Webserver. Das war mir nicht bewusst. In der Zwischenzeit hab ich das aber auch ausprobiert und nun liefert mein Mailserver für jede Domain ein eigenes Let's encrypt Zertifikat aus
Aber das funktioniert natürlich nur, wenn man einen eigenen Server betreibt. Bei einem Hoster muss man nehmen, was angeboten wird. Ich würde mal den Suport von Hetzner ansprechen und danach fragen.
Im Prinzip hat man nun 3 Möglichkeiten:
1. Im MX Record vom DNS die Domain des Mailservers eintragen. Also hier etwas mit your-server.de.
2. Will man im MX eine eigene Domain lautend auf den Firmennamen, z.B. smtp.firma.de, muss der Mail Server ein passendes Zertifikat liefern. Wie das geht, muss der Anbieter/Admin des Mailserver mitteilen.
3. Man ignoriert diese Warnung einfach. Tatsächlich funktionieren die meisten MTAs auch bei Zertifikatsfehlern und versenden die Mail trotzdem. Der Grund ist simpel: Ich vermute, wenn die MTAs auf korrekte Zertifikate beharren würden, würde gefühlt die Hälfte der E-Mails nicht verschickt. Zertifikatsfehler gibt's doch recht häufig, als da wären: Selbstgezeichnete Zertifikate, abgelaufene Zertifikate oder eben Fehler im CN etc.
Aber das funktioniert natürlich nur, wenn man einen eigenen Server betreibt. Bei einem Hoster muss man nehmen, was angeboten wird. Ich würde mal den Suport von Hetzner ansprechen und danach fragen.
Im Prinzip hat man nun 3 Möglichkeiten:
1. Im MX Record vom DNS die Domain des Mailservers eintragen. Also hier etwas mit your-server.de.
2. Will man im MX eine eigene Domain lautend auf den Firmennamen, z.B. smtp.firma.de, muss der Mail Server ein passendes Zertifikat liefern. Wie das geht, muss der Anbieter/Admin des Mailserver mitteilen.
3. Man ignoriert diese Warnung einfach. Tatsächlich funktionieren die meisten MTAs auch bei Zertifikatsfehlern und versenden die Mail trotzdem. Der Grund ist simpel: Ich vermute, wenn die MTAs auf korrekte Zertifikate beharren würden, würde gefühlt die Hälfte der E-Mails nicht verschickt. Zertifikatsfehler gibt's doch recht häufig, als da wären: Selbstgezeichnete Zertifikate, abgelaufene Zertifikate oder eben Fehler im CN etc.
Der Zertifikatsfehler liegt also am Emailsystem unseres Lieferanten/Kunden. Bei dem erwähnten Lieferanten weiß ich, dass er ebenfalls bei Hetzner hostet und ich habe die Frage bereits an den Support geschrieben. Ist ziemlich zäh und dauert.
Aber sicherlich bin ich nicht der IT-Admin unseres Lieferanten und es ist nicht meine Aufgabe das für ihn zu korrigieren. Darauf hingewiesen habe ich bereits, aber solange es wie Du in Möglichkeit 3 schreibst trotzdem funktioniert, ignorieren wir einfach die Warnings.
Wo bleibt dann der Sinn der Zertifikate? Sie stimmen zwar nicht, aber die Email wird trotzdem zugestellt. Könnte man dann nicht gleich auf die ganzen Zertifikate verzichten?
Vielleicht kann man es so wenigsten loggen und kontrollieren und je nachdem doch einmal blockieren, wenn das in Zukunft kommen sollte. Bzw. aus dem Warning einen Error machen oder umgekehrt.
Bei einer Webseite ist es offensichtlich wenn der Browser ein Sicherheits(Zertifikats) - Problem meldet.
Bei Emails jedoch schaut doch niemand regelmäßig in die Logs beim Hoster solange alles läuft und alle Emails ankommen?
Aber sicherlich bin ich nicht der IT-Admin unseres Lieferanten und es ist nicht meine Aufgabe das für ihn zu korrigieren. Darauf hingewiesen habe ich bereits, aber solange es wie Du in Möglichkeit 3 schreibst trotzdem funktioniert, ignorieren wir einfach die Warnings.
Wo bleibt dann der Sinn der Zertifikate? Sie stimmen zwar nicht, aber die Email wird trotzdem zugestellt. Könnte man dann nicht gleich auf die ganzen Zertifikate verzichten?
Vielleicht kann man es so wenigsten loggen und kontrollieren und je nachdem doch einmal blockieren, wenn das in Zukunft kommen sollte. Bzw. aus dem Warning einen Error machen oder umgekehrt.
Bei einer Webseite ist es offensichtlich wenn der Browser ein Sicherheits(Zertifikats) - Problem meldet.
Bei Emails jedoch schaut doch niemand regelmäßig in die Logs beim Hoster solange alles läuft und alle Emails ankommen?
Dank des Schlüssels im Zertifikates wird aber die Mail trotzdem kryptografisch verschlüsselt übertragen. Der Empfänger ist lediglich nicht überprüfbar. (Steht da sogar in dem gelben Text, unterste Zeile.) Beziehungsweise in deinem Fall war er ja schon überprüfbar, nur hat er nicht übereingestimmt mit dem was im MX-Record stand.
Allerdings könntest du das auch ändern und deinen Mailserver so konfigurieren, dass eben ein Error und nicht eine Warnung ausgeworfen wird. Dann wird die Mail nicht weitergeleitet und du bekommt eine Fehlermeldung in deinem E-Mail Client. Bedingt natürlich ein konfigurierbarer MTA.
Allerdings könntest du das auch ändern und deinen Mailserver so konfigurieren, dass eben ein Error und nicht eine Warnung ausgeworfen wird. Dann wird die Mail nicht weitergeleitet und du bekommt eine Fehlermeldung in deinem E-Mail Client. Bedingt natürlich ein konfigurierbarer MTA.
Allerdings könntest du das auch ändern und deinen Mailserver so konfigurieren, dass eben ein Error und nicht eine Warnung ausgeworfen wird. Dann wird die Mail nicht weitergeleitet und du bekommt eine Fehlermeldung in deinem E-Mail Client. Bedingt natürlich ein konfigurierbarer MTA.
Was ist der Standard? Klar, könnte ich, falls möglich, Warnungen verschärfen, müsste dann allerdings mit mehr Versandproblemen rechnen.
Wenn der Konsens so ist, dass man den "certificate name mismatch" getrost ignorieren kann, dann würde ich als MTA-Admin das doch auch so einstellen?
Mal schauen, was mir der Hetzner-Support zu der Thematik sagt.
Der Standard dürfte wohl sein -> ignorieren.
Oder willst du dieses Theater mit jedem Geschäftspartner haben, z.B. auch im Ausland? Das Problem ist doch, dass wohl die meisten deiner Mail-Empfänger nicht mal wissen, von was man spricht.
Aber es gibt Unternehmen, die arbeiten im sicherheitskritischen Bereich, z.B. Militär, Banken etc. Die sehen das dann vielleicht nicht mehr so locker.
Oder willst du dieses Theater mit jedem Geschäftspartner haben, z.B. auch im Ausland? Das Problem ist doch, dass wohl die meisten deiner Mail-Empfänger nicht mal wissen, von was man spricht.
Aber es gibt Unternehmen, die arbeiten im sicherheitskritischen Bereich, z.B. Militär, Banken etc. Die sehen das dann vielleicht nicht mehr so locker.
Entschuldige, ich habe mich nur gefragt, wann es sinnvoll sein könnte, den erwähnten Zertifikatsfehler als echten Fehler zu sehen und den Versand zu blockieren. Aber ein Beispiel hast Du mir genannt, danke.
Hetzner schrieb mir, dass man lediglich in der DNS-Konsole den MX-Eintrag ändern muss.
In dem Fall müsste unser Lieferant, der seine Emails auch bei Hetzner hostet, den Eintrag von
"mail.xxx.de." (seine Domain)
zu
"dedixxx.your-server.de." (die Domain seinen Dedicated Servers)
ändern. (die xxx'e sind vertraulich, daher hier verschleiert).
Bin positiv überrascht von der konkreten Lösung vom Support.
Allerdings schrieben sie mir danach wie man die Ende-zu-Ende Verschlüsselung im Email - Client einstellt, was ich überhaupt nicht gefragt habe und auch nicht wissen wollte. Naja, wahrscheinlich noch einen unnötigen Textbaustein hinzugefügt...
Danke soweit, wieder mal was dazugelernt
Hetzner schrieb mir, dass man lediglich in der DNS-Konsole den MX-Eintrag ändern muss.
In dem Fall müsste unser Lieferant, der seine Emails auch bei Hetzner hostet, den Eintrag von
"mail.xxx.de." (seine Domain)
zu
"dedixxx.your-server.de." (die Domain seinen Dedicated Servers)
ändern. (die xxx'e sind vertraulich, daher hier verschleiert).
Bin positiv überrascht von der konkreten Lösung vom Support.
Allerdings schrieben sie mir danach wie man die Ende-zu-Ende Verschlüsselung im Email - Client einstellt, was ich überhaupt nicht gefragt habe und auch nicht wissen wollte. Naja, wahrscheinlich noch einen unnötigen Textbaustein hinzugefügt...
Danke soweit, wieder mal was dazugelernt
Eine zustäzliche Info von Hetzner:
Ist das tatsächlich so, dass in unseren ausgehenden Emails in den Mailheader die Adresse mail.xxx.de des Empfängers reingeschrieben wird?
Wenn ich mir unsere versendeten Emails anschaue, steht da nur der minimale 9-zeilige Header drin ohne jegliche Informationen vom Empfänger. D.h. der nicht-zusammenpassende Mailheader mit dem SSL-Zertifikat passiert alles erst auf der Empfängerseite, was ich bei uns nicht mehr nachvollziehen kann?
Der Fehler "certificate name mismatch" kommt schlicht daher, dass unsere Mail-Server das Zertifikat "*.your-server.de" ausliefern, bei den besagten Mails im Mail-Header jedoch als Mail-Host Domain "mail.xxx.de" angegeben ist/war, weshalb dies nicht übereinstimmt.
Darum sollte der MX-Record entsprechend angepasst werden. Es könnte auch sein, dass dieser Absender selbst z.B. via seinem Mail-Client (oder wenn diese Mails über die Webseite versendet werden, das CMS) den Mail-Header sozusagen "manipuliert" und "mail.xxx.de" als Mail-Host setzt.
Darum sollte der MX-Record entsprechend angepasst werden. Es könnte auch sein, dass dieser Absender selbst z.B. via seinem Mail-Client (oder wenn diese Mails über die Webseite versendet werden, das CMS) den Mail-Header sozusagen "manipuliert" und "mail.xxx.de" als Mail-Host setzt.
Ist das tatsächlich so, dass in unseren ausgehenden Emails in den Mailheader die Adresse mail.xxx.de des Empfängers reingeschrieben wird?
Wenn ich mir unsere versendeten Emails anschaue, steht da nur der minimale 9-zeilige Header drin ohne jegliche Informationen vom Empfänger. D.h. der nicht-zusammenpassende Mailheader mit dem SSL-Zertifikat passiert alles erst auf der Empfängerseite, was ich bei uns nicht mehr nachvollziehen kann?
Moin,
Gruß,
Dani
st das tatsächlich so, dass in unseren ausgehenden Emails in den Mailheader die Adresse mail.xxx.de des Empfängers reingeschrieben wird?
ja. Ist doch anders herum genauso. Lass dir von dem Empfänger eine E-Mail zu schicken. Wenn diese da ist, schau in den Header. Da wirst du die Infos von eurer E-Mail Plattform finden.Gruß,
Dani
1
Warum wird es dann in unseren Email-Logs als Fehler aufgeführt, obwohl der Fehler erst auf Empfängerseite auftritt?
Vermutlich weil unserer Emailserver sich mit dem Empfangsserver austauscht und dann eben "ein Fehler" auftritt, was sowohl Sender als auch Empfänger betrifft?
Hetzner ergänzte und erklärte sehr verständlich ("a" ist unsere Domain, "b" die vom Empfänger):
Vermutlich weil unserer Emailserver sich mit dem Empfangsserver austauscht und dann eben "ein Fehler" auftritt, was sowohl Sender als auch Empfänger betrifft?
Hetzner ergänzte und erklärte sehr verständlich ("a" ist unsere Domain, "b" die vom Empfänger):
Beim TLS/SSL Verbindungsaufbau Ihres Mail-Servers "aaa.com" (wwwaaa.your-server.de) zum Mail-Server der "bbb.de" (mail.bbb.de auf dedibbb.your-server.de) tauschen die Mail-Server entsprechend das SSL-Zertifikat aus.
Ihr Mail-Server sendet das Zertifikat "*.your-server.de" und meldet sich aufgrund Ihres MX-Records mit dem Host "wwwaaa.your-server.de", wodurch die Domain im Zertifikat mit der Domain im Host übereinstimmt.
Der Mail-Server der "bbb.de" sendet das "*.your-server.de" Zertifikat (da dies auch ein Server/Kunde bei uns ist), meldet sich jedoch mit dem Host-Namen "mail.bbb.de" (MX-Record der "bbb.de"), welcher mit dem Domain des Zertifikats nicht übereinstimmt, deshalb die Warnmeldung dass dies nicht passt.
Das Zertifikat ist dennoch gültig und kann auch für den Verbindungs-Aufbau zum Versand der Mail verwendet werden, weshalb die Mail auch zugestellt wird.
Um diese Warnmeldungen zu verhindern, sozusagen um dieses "Problem" zu beheben, müsste "bbb.de" als Ziel Ihres MX-Record nicht "mail.bbb.de." verwenden, sondern "dedibbb.your-server.de.".
Ihr Mail-Server sendet das Zertifikat "*.your-server.de" und meldet sich aufgrund Ihres MX-Records mit dem Host "wwwaaa.your-server.de", wodurch die Domain im Zertifikat mit der Domain im Host übereinstimmt.
Der Mail-Server der "bbb.de" sendet das "*.your-server.de" Zertifikat (da dies auch ein Server/Kunde bei uns ist), meldet sich jedoch mit dem Host-Namen "mail.bbb.de" (MX-Record der "bbb.de"), welcher mit dem Domain des Zertifikats nicht übereinstimmt, deshalb die Warnmeldung dass dies nicht passt.
Das Zertifikat ist dennoch gültig und kann auch für den Verbindungs-Aufbau zum Versand der Mail verwendet werden, weshalb die Mail auch zugestellt wird.
Um diese Warnmeldungen zu verhindern, sozusagen um dieses "Problem" zu beheben, müsste "bbb.de" als Ziel Ihres MX-Record nicht "mail.bbb.de." verwenden, sondern "dedibbb.your-server.de.".
Was Hetzner schreibt, ist genau das, was ich oben erklärt habe.
Dein Empfänger hat sein System nicht gut eingerichtet. Dein Server merkt das und macht eine entsprechende Meldung in sein Log.
Dein Empfänger hat sein System nicht gut eingerichtet. Dein Server merkt das und macht eine entsprechende Meldung in sein Log.
Ist das tatsächlich so, dass in unseren ausgehenden Emails in den Mailheader die Adresse mail.xxx.de des Empfängers reingeschrieben wird?
Wenn ich mir unsere versendeten Emails anschaue, steht da nur der minimale 9-zeilige Header drin ohne jegliche Informationen vom Empfänger. D.h. der nicht-zusammenpassende Mailheader mit dem SSL-Zertifikat passiert alles erst auf der Empfängerseite, was ich bei uns nicht mehr nachvollziehen kann?
Wenn ich mir unsere versendeten Emails anschaue, steht da nur der minimale 9-zeilige Header drin ohne jegliche Informationen vom Empfänger. D.h. der nicht-zusammenpassende Mailheader mit dem SSL-Zertifikat passiert alles erst auf der Empfängerseite, was ich bei uns nicht mehr nachvollziehen kann?
Nicht im E-Mail Header, aber wenn dein MTA die Mail versendet, schaut er erstmal nach dem MX Record des Empfängers, dann löst er diesen auf eine IP-Adresse auf, dann verbindet er sich mit dieser IP-Adresse und DANN übermittelt er beim Verbindungsaufbau (HELO/EHLO) die gewünschte Domain. Unterstützt der Empfänger-Mailserver SNI, kann er sich nun unter mehreren Zertifikaten das passende aussuchen (genau wie es ein Webserver auch macht).
Nachtrag:
War ich zu voreilig. Nicht im HELO/EHLO Handshake passiert das, sondern später im TLS-Handshake.
https://www.cloudflare.com/de-de/learning/ssl/what-is-sni/
