Auch dieses Howto ist nicht allein auf meinem Mist gewachsen – ohne tatkräftige Hilfe von Marcus 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 <MC> in einem ssh-client – da kann ich copy & paste verwenden. Ausserdem kann ich zwei Verbindungen, also Fenster, gleichzeitig benutzen.

Ich gehe davon aus, dass das Abholen der Mails mittlerweile erfolgreich auf SSL umgestellt ist. Das Howto 'SSL-Mail – Empfang' und diverse Tipps zur grundsätzlichen Vorgehensweise dabei findet man für eisfair1 unter Fetchmail per SSL.

Zu Beginn sollte das certs-Paket auf Version 1.2.7 aktualisiert worden sein – hier wurden einige Fehler behoben. Wir benötigen für jeden Mail-Provider den zu benutzenden Postausgangsserver – diesen nennt uns der Provider. Die Zugangsdaten sollten wir sowieso schon haben. Unter http://www.patshaping.de/hilfen_ta/pop3_smtp.htm sind schon viele Daten zusammengetragen worden.

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 '_'.

Allerdings stellen sich manche Postausgangsserver quer – man kommt manchmal nicht so einfach an die Zertifikate wie bei den Posteingangsservern. Man erhält die Daten mit einem der folgenden Befehle - bitte ausprobieren, falls der jeweilige Postausgangsserver nicht in der Tabelle unten aufgeführt ist oder nicht den erwarteten Output mit der Zertifikatskette liefert:

openssl s_client -connect <servername>:465 -showcerts
openssl s_client -connect <servername>:25 -starttls smtp
openssl s_client -connect <servername>:587 -starttls smtp

Bitte <servername> durch den Namen des zu benutzenden Servers ersetzen – ohne die spitzen Klammern < und > !

Da dieser Befehl meistens auf eine Eingabe von uns wartet, beenden wir den Prozess mit ctrl + c . Für den Postausgangsserver von web.de sieht der Output folgendermassen aus:

...
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.

Wir kopieren also das Zertifikat inklusive der Trenner in eine Datei, die wir smtp.web.de.pem benennen.

Wie geht das ohne grossen Aufwand? Wir markieren in einem Fenster unseres ssh-client den gewünschten Text mit der Maus und kopieren ihn (unter z.B. Windows mit ctrl + c) in die Zwischenablage. Im anderen Fenster läuft der <MC> und wir wechseln ins Verzeichnis /usr/local/ssl/certs/. Dort legen wir die neue Datei an:

touch smtp.web.de.pem

Für Zertifikate die nur namentlich in der Kette aufgeführt sind (wie hier bei smtp.web.de) hilft uns google. Erst wenn wir bei einem Zertifikat angekommen sind wo Betreff (Subject) und Aussteller (Issuer) absolut identisch sind, haben wir die Zertifikatskette komplett aufgelöst und sind fertig mit diesem Schritt – aber die .pem-Datei muss natürlich existieren. Hier im Beispiel brauchen wir also noch die Zertifikate von TeleSec ServerPass DE-1 und Deutsche Telekom Root CA 2 ; dabei hilft uns wie gesagt google.

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.

Das hier als letztes heruntergeladene Zertifikat Deutsche Telekom Root CA 2 kommt auch in eine .pem-Datei (deutsche_telekom_root_ca_2 .pem) und da Subject und Issuer hier identisch sind, haben wir für smtp.web.de alle Zertifikate beisammen. Falls ein Zertifikat schon als .pem-Datei vorhanden ist, brauchen wir es nicht noch einmal anlegen – daher sollten die Namen der Dateien sehr sorgfältig vergeben werden, damit wir sie nicht doppelt anlegen (wäre kein Fehler - nur doppelte Arbeit). Falls wir bei einem Provider mehrere Postausgangsserver nutzen, muss nur dann für jeden einzelnen eine eigene .pem-Datei erstellt werden, wenn die Zertifikate nicht identisch sind.

Wenn wir alle Zertifikate der Zertifikatskette beisammen haben, wechseln wir ins Verzeichnis /usr/local/ssl/certs/ und rehashen:

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.

Falls wir unter /usr/local/ssl/certs/ eine oder mehrere (oder ganz viele) .pem-Dateien finden, die wir nicht selbst erzeugt haben und die einen wenig aussagekräftigen Namen haben wie z.B. 57bbd831.pem , dann belassen wir diese Dateien dort. Dies sind grundlegende Zertifikate, die wir ansonsten mühsam händisch selbst besorgen müssten – also besser Finger weg davon. Beim rehashen werden ausserdem haufenweise .0-Dateien angelegt – auch besser Finger weg.

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. Die Vorgehensweise habe ich in ein eigenes Howto Erstellung eines lokalen Zertifikates exim.pem ausgelagert.

Aus Faulheit hatte ich kurzerhand meine pureftpd.pem nach exim.pem kopiert und dann sicherheitshalber rehasht. Anfangs hat sich mein Server nicht über das eigentlich abgelaufene Gültigkeitsdatum in meiner exim.pem beschwert – aber 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 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 Pflicht. Daher korrigieren oder legen wir 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

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.

Ich habe auf diese Weise Konten bei web.de – gmx.de – gmx.net – t-online.de erfolgreich umgestellt. Bei Fragen oder Unklarheiten wendet Euch bitte an die Newsgroup – bitte nicht direkt an mich.

Dezember 2013

Stefan Puschek