Welchen Namen im Zertifikat für Postfix

[Deleted member 17059]

Hallo

Ich hab ein Postfix auf Port 25 mit STARTLS. Dazu hab ich ein selbstgezeichnetes Zertifikat auf den Namen smtp.local.box hinterlegt.

Mit den Mail-Clients im Intranet versende ich auch direkt über die Adresse smtp.local.box.

Dabei fand ich es interessant, dass es Thunderbird egal ist, auf welchen Namen das Zertifikat ausgestellt ist, während TheBat reklamiert, wenn die SMTP Serveradresse nicht mit dem Namen im Zertifikat übereinstimmt.

Jetzt frag ich mich, wie das eigentlich externe Mailserver handhaben. Ganz offensichtlich ist für die meisten externen Server das selbstgezeichnete Zertifikat kein Problem. Die Mails werden verschlüsselt eingeliefert, was man im Mail Header als mit ESMTPS gekennzeichnet, sehen kann.

Aber was ist da normal? Was ist good practice ?

Der Server hat als SMTP Banner mail.firma.com und auch als HELO. Wäre es da nicht naheliegend auch damit das Zertifikat zu erstellen? Und wenn ja, selbstgezeichnet oder z.B. kostenlos mit Letsencrypt ? Oder ist das eh alles egal?

Kann es sein, dass externe Server Mails unverschlüsselt senden (was sehr oft noch der Fall ist, allerdings meistens von Spammern), wenn das hinterlegte Zertifikat gewissen Anforderungen nicht entspricht, wie eben die Selbstzeichnung ?

 

[danton]

Dabei fand ich es interessant, dass es Thunderbird egal ist, auf welchen Namen das Zertifikat ausgestellt ist, während TheBat reklamiert, wenn die SMTP Serveradresse nicht mit dem Namen im Zertifikat übereinstimmt.

Dann hast du aber was im Thunderbird eingestellt, dass er das nicht macht. Mein Thunderbird meckert sehr wohl, wenn ich ein selbstsigniertes Zertifikat verwende oder der FQDN nicht zum Zertifikat passt.

Jetzt frag ich mich, wie das eigentlich externe Mailserver handhaben. Ganz offensichtlich ist für die meisten externen Server das selbstgezeichnete Zertifikat kein Problem. Die Mails werden verschlüsselt eingeliefert, was man im Mail Header als mit ESMTPS gekennzeichnet, sehen kann.

Die meisten Mailserver machen AFAIK noch keinen Abgleich des FQDN im Zertifikat mit dem im MX-Record. Muß aber nicht so bleiben...

Der Server hat als SMTP Banner mail.firma.com und auch als HELO. Wäre es da nicht naheliegend auch damit das Zertifikat zu erstellen? Und wenn ja, selbstgezeichnet oder z.B. kostenlos mit Letsencrypt ? Oder ist das eh alles egal?

Sinnvoll ist meiner Meinung nach ein Zertifikat von einer Zertifizierungsstelle, die allgemein anerkannt wird (also in den CA-Paketen der gängigen Linux-Distris drin ist bzw. von den gängigen Browsern/MUAs als vertrauenswürdig anerkannt wird) - da gehört LetsEncrypt zu. Als FQDN bietet sich sowas wie mail.hauptdomain.tld an - die man dann auch direkt bei allen anderen Domains, für die der Mailserver zuständig ist, im MX-Record einträgt. (also nicht für jede Domain eine eigene mail-Subdomain).

Kann es sein, dass externe Server Mails unverschlüsselt senden (was sehr oft noch der Fall ist, allerdings meistens von Spammern), wenn das hinterlegte Zertifikat gewissen Anforderungen nicht entspricht, wie eben die Selbstzeichnung ?

Prinzipiell ja, es kommt immer auf den jeweiligen Mailserver-Admin an. Da spielen aber auch andere Dinge eine Rolle, z.B. Verschlüsselungsparameter wie Bitlänge, Cipher usw. Massen-Mailversender (egal ob legitim oder Spammer) wägen da auch ggfl. den Sicherheitsgewinn gegen die zusätzliche Rechenleistung für die Verschlüsselung ab (und nein, ich möchte hier keine Diskussion zum Thema Sicherheit vs. Rechenaufwand lostreten).

 

[gunnarh]

1. Mail-Empfang auf SMTP/25 wird über den MX-Record von den anliefernden Servern ermittelt. MX-Record lautet z.B. auf mx1.deinedomain.com => das Zertifikat muss hierauf ausgestellt sein.

2. Mail-Anlieferung von Clients sollte eigentlich über Submission/587 erfolgen. Mancherorts wird das immer noch über 25/smtp erledigt - ist aber aus diversen Gründen unzweckmäßig und verpönt.
Angenommen Du hast Den Anwendern mitgeteilt sie sollen mail.deinedomain.com als Postausgangsserver eintragen, dann muss das Zertifikat hierauf lauten.

Wenn nun 1+2 verschieden lauten, benötigst Du entweder getrennte Zertifikate auf 25/smtp und 587/submission, oder ein Zertifikat mit SubjectAlternativeNames.

Dass der Hello-String möglichst dem MX-Record entsprechen sollte wurde glaube ich schon genannt.


Was das "Server prüfen die Zertifikate eh nicht" Thema angeht: DANE ist eine Lösung, siehe mein HowTo https://hitco.at/blog/sicherer-e-mail-dienste-anbieter-dnssec-dane/

 

[danton]

Was das "Server prüfen die Zertifikate eh nicht" Thema angeht: DANE ist eine Lösung, siehe mein HowTo https://hitco.at/blog/sicherer-e-mail-dienste-anbieter-dnssec-dane/

Ersteres wird meines Wissens nur ganz selten gemacht und auch DANE ist leider derzeit noch nicht sehr verbreitet. Das bedeutet aber eben nicht, dass es so bleibt. Daher empfiehlt es sich direkt, beim Zertifikat, HELO und MX-Record ein paar Sachen zu beachten und es direkt sauber zu machen (siehe mein Post oben).

 

[Deleted member 17059]

Danke für die Kommentare.

So wie es aussieht, ist es externen MTAs egal, ob das Zertifikat selbst oder durch eine öffentlich bekannte CA gezeichnet ist.

Ich hab das selbst gezeichnete Zertifikat jetzt jedoch durch ein Zertifikat von Let's encrypt, ausgestellt auf den Namen des Mailservers (mail.example.com), ersetzt. Denke, das macht mehr Sinn, auch wenn man selber von extern mit Mail-Clients zugreifen möchte.

NB: Thunderbird reklamiert übrigens auch, wenn das Zertifikat nicht auf den Namen des Server ausgestellt ist, genauso wie TheBat. Allerdings bietet er die Möglichkeit an, das 'falsche' Zertifikat zu akzeptieren. Ev. hatte ich das auch früher mal so gemacht.

 

[danton]

So wie es aussieht, ist es externen MTAs egal, ob das Zertifikat selbst oder durch eine öffentlich bekannte CA gezeichnet ist.

Das habe ich oben schon geschrieben und sage dazu noch mal: Das muß nicht so bleiben und daher sollte man es von Anfang an ordentlich machen. Auch sollte der Eintrag im MX-Record daher zum Zertifikat passen.

NB: Thunderbird reklamiert übrigens auch, wenn das Zertifikat nicht auf den Namen des Server ausgestellt ist, genauso wie TheBat. Allerdings bietet er die Möglichkeit an, das 'falsche' Zertifikat zu akzeptieren. Ev. hatte ich das auch früher mal so gemacht.

Das ist eine Krücke und im Falle von Lets Encrypt wird dich die Meldung spätestend nach 90 Tagen wieder heimsuchen, wenn du dein Zertifikat erneuerst. Auch kann sich hier das Verhalten der MUAs irgendwann ändern und sie lassen solche Ausnahmen nicht mehr zu.

 

[mr_brain]

Das ist eine Krücke und im Falle von Lets Encrypt wird dich die Meldung spätestend nach 90 Tagen wieder heimsuchen, wenn du dein Zertifikat erneuerst. Auch kann sich hier das Verhalten der MUAs irgendwann ändern und sie lassen solche Ausnahmen nicht mehr zu.

Die Erneuerung des Let´s Encrypt läuft, wenn ein mal eingerichtet, doch automatisch.

 

[danton]

Ja, das Zertifikat wird, sofern passend eingerichtet, auf dem Server automatisch erneuert. Ich meinte aber die Meldung im Client, falls das Zertifikat nicht zum im Thunderbird eingetragenen FQDN der Mailservers passt: Die Ausnahme gilt immer nur für das jeweilige Zertifikat und wenn man auf zukünftig ignorieren klickt, gilt das nur für dieses eine Zertifikat - nachdem der Server es erneuert hat, sieht der Client das neue und meldet sich wieder mit einem ungültigen Zertifikat.

 

[Deleted member 17059]

Ich glaube, ich habe mich da bez. Thunderbird missverständlich ausgedrückt.

Im Eingangsposting hab ich vermutet, dass der Thunderbird im Gegensatz zu TheBat bei nicht passenden Zertifikaten NICHT reklamiert. Dem ist aber definitiv NICHT so. Der Grund lag wohl bei mir darin, dass ich 'irrtümlicherweise' das nicht passende Zertifikat im Thunderbird akzeptiert hatte und es nachher vergessen habe. Leider ist bei Thunderbird (wie auch bei Firefox) dummerweise immer auch noch die Voreinstellung 'Entscheidung merken'. Einmal zu schnell geklickt und schon ist es gespeichert.


Ansonsten sehe mit Let's encrypt Certs keine Probleme.