Welchen Hostnamen sollte das SSL-Zertifikat für einen SMTP-Server enthalten?

Ich habe einen Server foo.example.com bei 192.0.2.1

Es wird exim ausgeführt, um E-Mails für mehrere meiner Domains zu erhalten.

Meine Domains haben jeweils einen MX-Eintrag, der auf mx.example.com verweist und in 192.0.2.1 aufgelöst wird

Wenn ich möchte, dass exim TLS-Verschlüsselung für eingehende E-Mail-Verbindungen anbietet, welchen Hostnamen sollte ich in das SSL-Zertifikat einfügen?

• foo.example.com weil das der Server im HELO sagt?
• mx.example.com, weil dies der Hostname ist, mit dem die Clients verbunden sind?

http://www.checktls.com schlägt vor, dass letzteres korrekt ist, aber ich kann keine endgültige Antwort finden.

Dies ist eigentlich nirgends explizit definiert, und ob der Server "vertrauenswürdig" sein soll oder nicht, hängt vom Client ab (der natürlich auch ein anderer Mailserver sein kann), der eine Verbindung zu ihm herstellt. Zitat aus dem relevanten RFC ( RFC 2487 ):

Wenn der SMTP-Client feststellt, dass die Authentifizierungs- oder
Datenschutzstufe nicht hoch genug ist, um fortzufahren,
MUSS er unmittelbar nach Abschluss der TLS-Aushandlung einen SMTP-QUIT-Befehl ausgeben.
Wenn der SMTP-Server feststellt, dass die Authentifizierungs- oder
Datenschutzstufe nicht hoch genug ist, um fortzufahren, MUSS er auf
jeden SMTP-Befehl des Clients (außer auf einen QUIT-Befehl) mit
dem Antwortcode 554 antworten (mit einer möglichen Textzeichenfolge, z als "Befehl
wegen mangelnder Sicherheit abgelehnt").

Die Entscheidung, ob die Authentizität der
anderen Partei in einer TLS-Verhandlung berücksichtigt werden soll oder nicht, ist eine lokale Angelegenheit. Einige
allgemeine Regeln für die Entscheidungen sind jedoch:

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

Wenn der Server eine TLS-Verschlüsselung unter Verwendung eines bestimmten Zertifikats anbietet, hängt die Entscheidung über das Akzeptieren oder Ablehnen der TLS-Verschlüsselung im Wesentlichen von dem anderen Teil ab, bei dem der Name des Zertifikats wahrscheinlich der gleiche sein soll, mit dem es verbunden ist, aber dies kann Akzeptiere es sehr gut, auch wenn es nicht passt.

Aber warte, es gibt noch mehr. Nochmals zitieren aus demselben RFC:

Nach Abschluss des TLS-Handshakes wird das SMTP-Protokoll auf
den Anfangszustand zurückgesetzt (der Zustand in SMTP, nachdem ein Server eine
Begrüßung für den 220- Dienst ausgegeben hat). Der Server MUSS alle
vom Client erhaltenen Informationen verwerfen , z. B. das Argument für den EHLO-Befehl,
das nicht aus der TLS-Aushandlung selbst stammt. Der Client
MUSS alle vom Server erhaltenen Informationen verwerfen, z. B. die Liste
der SMTP-Diensterweiterungen, die nicht aus der TLS-
Aushandlung selbst stammen. Der Client SOLLTE
nach einer erfolgreichen TLS-Aushandlung einen EHLO-Befehl als ersten Befehl senden .

Was der Server als Antwort auf HELO / EHLO vor dem TLS-Handshake sagt, scheint also überhaupt keine Rolle zu spielen.

Nach meiner Erfahrung funktionieren selbstsignierte Zertifikate auf Mail-Servern mit Internet-Zugang ziemlich gut, was bedeutet, dass die anderen Mail-Server sich nicht einmal die Mühe machen, sie zu validieren. Sie akzeptieren einfach alles, was TLS-Verschlüsselung bieten kann, unabhängig von der Ausgabe Name der Behörde oder des Subjekts.

Ein MTA, der E-Mails an Ihre Domain übermittelt, sucht nach dem MX-Eintrag (der einen Hostnamen ergibt) und anschließend nach einem A-Eintrag für diesen Hostnamen. Der Hostname, mit dem die Verbindung hergestellt wird, ist daher der MX-Hostname. Dies wird anhand des allgemeinen Namens des SSL-Zertifikats überprüft. Die Überprüfung des HELO-Hostnamens ist nicht sinnvoll, da der Server einen beliebigen HELO-Hostnamen bereitstellen kann, der keine zusätzliche Sicherheit bietet.

Die strikte Überprüfung von SSL-Zertifikaten bei der Zustellung von E-Mails ist im Moment jedoch nicht besonders nützlich, da MTAs (fast immer) auf die Zustellung ohne SSL zurückgreifen, da SMTP im Moment so funktioniert. Es ist daher sinnvoll, SSL zu verwenden, wenn der MX-Server dies anbietet, unabhängig davon, ob das SSL-Zertifikat überprüft wird oder nicht (da Verschlüsselung ohne Authentifizierung besser ist als keine Verschlüsselung und keine Authentifizierung). Sie können daher auch ein selbstsigniertes Zertifikat für diesen Zweck verwenden.

Die Aufgabe, das Serverzertifikat zu überprüfen und sicherzustellen, dass es mit dem Hostnamen des Servers übereinstimmt, ist bei allen Protokollen, die SSL / TLS verwenden, ausschließlich die Rolle des Clients.

Daher sollte der Hostname im Zertifikat mit dem Namen übereinstimmen, auf den der Client zugreifen möchte.

Wenn die SSL / TLS-Verbindung im Voraus initiiert wird (SMTPS), kann der Server nicht sehen, was die HELO-Nachricht sagt, bevor die Verbindung hergestellt wird, und muss daher diejenige verwenden, mit der er die Anfrage gestellt hat.

Wenn Sie danach SSL / TLS verwenden STARTTLS, beabsichtigt der Client weiterhin, mit dem Server zu kommunizieren, mit dem er konfiguriert wurde. Daher sollte er dies weiterhin überprüfen. Andernfalls wären MITM-Angriffe möglich:

• C-> S: Hallo, ich bin Alice, ich möchte mit Bob sprechen.
• S-> C: Hi, ich bin Chuck, hier ist mein Zertifikat für Chuck.
• C-> S: Oh ja, dein Zertifikat ist in der Tat für Chuck gültig. Lass uns weitermachen.
• ... Da gibt es natürlich einen Fehler, da Alice eine sichere Kommunikation mit Bob haben wollte.

In beiden Fällen sollte die MX-Adresse verwendet werden.

Die Regeln für die Zuordnung von Hostnamen wurden kürzlich in RFC 6125 protokollübergreifend erfasst , aber nur wenige Clients implementieren sie vollständig (es handelt sich eher um eine bewährte RFC-Methode als um eine vollständige Änderung, und sie ist noch recht neu.).

In ihrem Anhang fasst sie zusammen, was früher über SMTP existierte (entnommen aus RFC 3207 und RFC 4954 ). Insbesondere " Der Client DARF KEINE Form des Server-Hostnamens verwenden, der von einer unsicheren Remote-Quelle stammt (z. B. unsichere DNS-Suche). " (Dies gilt natürlich für das Banner des Servers.) Abgesehen davon waren die SMTP-Legacy-Regeln in Bezug auf alternative Antragstellernamen etwas lockerer als HTTPS ( sollten statt müssen verwendet werden).

Die moderne Art ist definitiv, den Hostnamen in einen DNS-Eintrag für den alternativen Antragstellernamen einzufügen. Von der Verwendung von Platzhaltern wird ebenfalls abgeraten .

Ich denke, das Beste wäre, zu kopieren, was in der Praxis gemacht wird. Ich habe eine yahoo.com-E-Mail-Adresse mit http://checktls.com überprüft. Hoffentlich haben sie bei yahoo eine andere Domain für ihren Hostnamen und für ihre MX-Domain verwendet. Ihr Hostname ist also yahoo.com und ihre MX-Domain endet mit yahoodns.net

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

Ergebnis der Überprüfungen: die SSL-Zertifikat-CN = MX-Domain (* .yahoodns.net)

Ich habe das gleiche mit Cisco gemacht und ich hatte das gleiche Ergebnis.

Bei der SSL / TLS-Verschlüsselung überprüft der Client immer die Übereinstimmung zwischen dem "echten" / "deklarierten" Hostnamen auf dem entfernten Rechner und den im Zertifikat enthaltenen Informationen.

Also solltest du wahrscheinlich foo.example.com setzen oder ein Wildcard-Zertifikat generieren ;-)