Page Comparison

Auch dieses Howto ist nicht allein auf meinem Mist gewachsen – ohne tatkräftige Hilfe von Marcus Roeckrath Röckrath und Holger Bruenjes in der Newsgroup spline.eisfair auf news.spline.de wäre ich ziemlich aufgeschmissen gewesen. Ich habe hier nun meine Erfahrungen und Probleme und die Lösungsansätze einfliessen lassen.

Damit ich mir viel Tipparbeit und natürlich Tippfehler erspare, arbeite ich nicht direkt auf der Konsole des Servers, sondern benutze den Midnight-commander Commander <MC> in einem ssh-client – da kann ich copy & paste verwenden. Ausserdem kann ich zwei Verbindungen, also Fenster, gleichzeitig benutzen.

...

http://www.patshaping.de/hilfen_ta/pop3_smtp.htm

Für den verschlüsselten Mailversand sind die folgenden Schritte nicht erforderlich, wenn der smtp-Server des Providers von sich aus eine Verschlüsselung anbietet. Dann wird beim Versand automatisch auch die Verschlüsselung mit der Gegenstelle vereinbart. Dieses reicht aber nicht, um Man-in-the-Middle-Attacken vorzubeugen.

Damit wir sicher sein können, dass wir unsere Mails auch dem richtigen Postausgangsserver übergeben (alles andere wäre fatal), besorgen wir uns die einzelnen Zertifikate der Zertifikatskette von ihm. Diese kommen alle – sofern sie noch nicht vorhanden sind - nach

/usr/local/ssl/certs/

und sollten als Namen (damit wir die Datei später auch wiedererkennen) den Namen des Servers bzw. des Eigentümers bekommen und auf .pem enden. Bei den Namen verwende ich grundsätzlich Kleinbuchstaben und ersetze Leerzeichen durch den Unterstrich '_'.

...

...
Certificate chain
0 s:/C=DE/O=1&1 Mail & Media GmbH/OU=WEB.DE/ST=Rhineland-Palatinate/L=Montabaur/emailAddress=server-certs@1und1.de/CN=smtp.web.de
i:/C=DE/O=T-Systems International GmbH/OU=T-Systems Trust Center/ST=NRW/postalCode=57250/L=Netphen/street=Untere Industriestr. 20/CN=TeleSec ServerPass DE-1
1 s:/C=DE/O=T-Systems International GmbH/OU=T-Systems Trust Center/ST=NRW/postalCode=57250/L=Netphen/street=Untere Industriestr. 20/CN=TeleSec ServerPass DE-1
i:/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
2 s:/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
i:/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHUzCCBjugAwIBAgIJAKaEwtMgQ2s5MA0GCSqGSIb3DQEBBQUAMIHJMQswCQYD
...
Ulc/sMvd/LPX0f60pSQr9tkZgU4f8Jvx9EvPUCFTRXlXqkBIhgJhgCadZC+wKB1P
eQMS8rksXw==
-----END CERTIFICATE-----

In diesem Output finden wir die Zertifikatskette beginnend bei 0 s:/C=DE/O=1&1 Mail & Media GmbH/OU=WEB.DE/ST=Rhineland-Palatinate... - hier also 3 Elemente (0, 1 und 2) der Kette und dann das eigentliche Zertifikat des Servers smtp.web.de, eingeschlossen zwischen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- . Diese beiden Trenner gehören jeweils mit zum Zertifikat, also mit in die .pem-Datei. Manchmal sind die Zertifikatsdaten auch gleich mit in der Kette aufgeführt – dann steht vor dem Zertifikat hinter s: (Subject) bei CN= (Common Name) der Betreff, also der Server oder Eigentümer, dem das Zertifikat gehört. Hinter i: steht dann bei CN= der Aussteller (Issuer) des Zertifikats.

...

touch smtp.web.de.pem

an. Nun öffnen wir die noch leere Datei mit der Taste F4 im Editor vom <MC> und können den Inhalt aus der Zwischenablage einfügen (unter z.B. Windows mit ctrl + v) und mit F2 die Datei speichern. Falls unsere Zertifikatskette weitere Zertifikate enthält (bei smtp.web.de ist dies leider nicht der Fall), fügen wir diese – sofern noch nicht vorhanden – auf die gleiche Weise in eine .pem-Datei im Verzeichnis /usr/local/ssl/certs/ ein.

...

Mit den Suchbegriffen TeleSec ServerPass DE-1 ist der erste Treffer mit passendem Domainnamen momentan (Mitte Dezember 2013) 

http://www.telesec.de/serverpass/support_rootca_akzeptanz.html

...

Mit den Suchbegriffen Deutsche Telekom Root CA 2 ist der erste Treffer mit passenden Domainnamen momentan (Mitte Dezember 2013) 

http://www.telesec.de/pki/roots.html

Hier finden sich meist diverse Zertifikate zum Download. Man muss darauf achten, dass man genau das mit dem richtigen Namen als .pem oder ascii-kodiert herunterlädt – es gibt hier meist viele ähnlich lautende Namen, die sich nur minimal unterscheiden. Auch Namenszusätze wie z.B. G5 machen hier einen enormen Unterschied aus.

...

cd /usr/local/ssl/certs/
/usr/bin/ssl/c_rehash

Nun prüfen wir, ob wir auch wirklich für die .pem-Datei des Postausgangsservers alle Zertifikate haben:

/var/install/bin/certs-show-chain <Name des Servers>.pem

Wenn die Kette bis +-> end of chain! aufgelöst wird, kommt der nächste Postausgangsserver dran, ansonsten sehen wir das letzte gefundene Zertifikat, ab dem wir uns in der Kette weiterhangeln müssen. Wichtig ist immer, dass alle Zertifikatsdateien .pem heissen, in usr/local/ssl/certs/ liegen und dass wir auch nach allen Änderungen neu rehasht haben. Also die gleiche Vorgehensweise wie bei den Posteingangsservern.

...

Nun muss unser Mailserver auch Listen von gesperrten und oder widerrufenen Zertifikaten haben. Ohne diese bricht er den Versand ab, da er so nicht feststellen kann, ob alle Zertifikate in der Kette noch gültig sind.

Gegenüber dem im folgenden beschriebenen Vorgehen, gilt bei Verwendung von certs >= 1.2.8: Aktivierung von atd in der Base-Konfiguration und Aufruf von "Update revocation list(s) im certs-Menü. Dieser Punkt ist auch aufzurufen, wenn sich im Exim-Log (/var/spool/exim/log/mainlog) folgende Fehlermeldung beim Mailversand findet:

SSL verify error: depth=0 error=CRL has expired cert=/C=DE/O=... 

Die Widerrufslisten (CRL) besorgt er sich durch

/var/install/bin/certs-update-crl -grepuri

und

/var/install/bin/certs-update-crl -quiet

Beide Befehle können einige Minuten an Zeit beanspruchen (ich habe schon mal 20 Minuten gewartet) und liefern vermutlich Fehlermeldungen. Hier werden die oben schon erwähnten wenig aussagekräftigen .pem-Dateien heruntergeladen und es wird dann rehasht. Die Fehlermeldungen betreffen nur .cer-Dateien die wir nicht benötigen und können daher ignoriert werden.

Zum Schluss will unser Mailserver unbedingt eine eigene exim.pem-Datei haben – ohne diese klappte der SSL-verschlüsselte Versand bei mir nicht. Mir erschliesst sich der Sinn der Datei / des Zertifikats zwar nicht, aber ohne gings partout nicht. Entweder hat man Glück und findet unter /usr/local/ssl/certs/ bereits eine apache.pem oder eine pureftpd.pem oder man erstellt sich mit dem certs-Paket selbst eine exim.pem. Da ich hieran gescheitert bin, habe Die Vorgehensweise habe ich in ein eigenes Howto ausgelagert unter

https://ssl.nettworks.org/wiki/display/e/Erstellung+eines+lokalen+Zertifikates+exim.pem

Aus Faulheit hatte ich kurzerhand meine pureftpd.pem nach exim.pem kopiert und dann sicherheitshalber rehasht. Eigenartigerweise Anfangs hat sich mein Server nicht über das eigentlich abgelaufene Gültigkeitsdatum in meiner exim.pem beschwert – aber wenigstens läuft er damit.wenn man das Mailpaket richtig konfiguriert, wird auf abgelaufene / ablaufende Zertifikate geprüft. Daher habe ich die Prüfung momentan zu Testzwecken 'etwas' öfter eingeplant - nicht nur alle zwei Wochen mitten in der Nacht.

MAIL_CERTS_WARNING = yes
MAIL_CERTS_WARNING_SUBJECT = TLS certificates warning
MAIL_CERTS_WARNING_CRON_SCHEDULE = 30 * * * *

Mit dieser Einstellung wird jetzt stündlich um 30 Minuten nach der vollen Stunde geprüft. Jetzt müssen wir noch in der Konfiguration des Mailpaketes die Postausgangsserver für verschlüsselten Versand eintragen (sind meist andere als ohne SSL) und dann SSL aktivieren.

SMTP_SMARTHOST_x_HOST = <Servername> # -- der Postausgangsserver
SMTP_SMARTHOST_x_AUTH_TYPE = plain
SMTP_SMARTHOST_x_ADDR = <Mailadresse>
SMTP_SMARTHOST_x_DOMAIN =
SMTP_SMARTHOST_x_USER = <geheim>
SMTP_SMARTHOST_x_PASS = <auch geheim>
SMTP_SMARTHOST_x_FORCE_AUTH = no
SMTP_SMARTHOST_x_FORCE_TLS = yes # -- SSL aktivieren
SMTP_SMARTHOST_x_PORT =

Ich habe bei gmx.de, gmx.net, t-online.de und web.de keinen Port angeben müssen, aber dies kann bei anderen Providern durchaus abweichen.

Dies wiederholen wir für alle Mailkonten, die wir auf Versand mit SSL umstellen wollen. Wir speichern die Konfiguration mit F2, verlassen den Konfigurationseditor mit F10 und aktivieren die neue Konfiguration.

Da die Provider auf unserer Seite vom Mailversende-Programm nur gültige Widerufszertifikate akzeptiert werden, jedoch manche Provider (z. B. web.de und gmx - möglicherweise auch andere - ) nur Widerufszertifikate bereitstellen, die nur eine kurze Gültigkeit (ca. einen Tag) haben, ist die regelmässige Aktualisierung der Widerrufslisten benötigen, Pflicht. Daher korrigieren oder legen wir uns im certs-Paket noch einen cron-Job dafür an.

setup
4. Service administration
4. Certs Service <--- diese Nummer ist von Eurer Installation abhängig und selten identisch mit meiner...
2. Edit configuration

Und hier tragen wir folgende Werte ein:

CERTS_CRL_CRON = yes
CERTS_CRL_CRON_SCHEDULE = 11 2,14 * * *

Wir speichern die Konfiguration mit F2, verlassen den Konfigurationseditor mit F10 und aktivieren die neue Konfiguration.

Jetzt sollte bei allen auf SSL umgestellten Konten nur noch verschlüsselt an die Postausgangsserver geschickt werden. Überprüfen können wir dies im Logfile des Mailpaketes:

10. Goto mail tools
13. View main log file

Wenn hier nach (!!!) dem Versand einer Mail über ein auf SSL-Versand umgestelltes Konto keine Fehlermeldungen erscheinen (ganz nach unten scrollen) und die Mail auch beim Empfänger ankommt, hat die Umstellung geklappt.

...

Dezember 2013

Stefan Puschek

...

Verwandte Artikel