Primär ist der Einsatz der kostenlosen Let's Encrypt Zertifikate für Webseiten vorgesehen. Wie erzeugt man nun aber ein Zertifikat für einen Mail- bzw. IMAP-Server, auf dem vielleicht gar kein Webserver läuft? Auch das ist in wenigen Schritten möglich. Ich verwende hier certbot zur Kommunikation mit Let's Encrypt, da er für Debian in den Jessie-Backports enthalten ist.
In der Beschreibung hier verwende ich <Domain-Name> für alle Stellen, an der die Domain des eigenen Mailservers eingetragen werden muss.
certbot installieren
Zuerst einmal muss das Jessie-Backport-Repository für die Paketverwaltung bekannt gemacht werden. Dazu legt man am einfachsten unter /etc/apt/sources.list.d eine neue Datei mit dem Namen jessi-backports.list und folgendem Inhalt an:
deb http://ftp.debian.org/debian jessie-backports main
Danach muss die lokale Kopie des Repository-Verzeichnisses aktualisiert werden und anschließend kann certbot wie gewohnt installiert werden:
apt-get update apt-get install certbot -t jessie-backports
Zertifikat anfordern
Danach ist es ganz einfach, ein Zertifikat für den Mailserver anzufordern:
certbot certonly --standalone -d <Domain-Name>
Mit diesem Kommando wird ein temporärer Webserver gestartet über welchen Let's Encrypt mit dem lokalen System kommuniziert. Dadurch wird sichergestellt, dass die zu registrierende Domain auch unter der entsprechenden Adresse erreichbar und damit für den Domainnamen im Zertifikat berechtigt ist.
Nach der erfolgreichen Generierung der Zertifikate werden diese unter /etc/letsencrypt/live/<Domain-Name>/ abgelegt.
Zertifikat in Dovecot einbinden
Unter /etc/dovecot/conf.d/10-ssl.conf trägt man die Pfade zum neuen Zertifikat ein:
ssl = required ssl_cert = </etc/letsencrypt/live/<Domain-Name>/fullchain.pem ssl_key = </etc/letsencrypt/live/<Domain-Name>/privkey.pem
Nach einem Neustart von Dovecot ist nun der IMAPS-Zugang mit dem neuen Let's Encrypt Zertifikat gesichert. Leider bietet z.B. Thunderbird keine Möglichkeit, ein gültiges Zertifikat zum Mailserver anzuzeigen (nur bei einem ungültigen Zertifikat kann es angezeigt werden). Mit Hilfe von openssl läßt sich jedoch einfach überprüfen, ob Dovecot das korrekte Zertifikat liefert (hier für meinen eigenen Mailserver mail.tausys.de):
$ echo QUIT | openssl s_client -connect mail.tausys.de:993 -CApath /etc/ssl/certs depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = mail.tausys.de verify return:1 CONNECTED(00000003) --- Certificate chain 0 s:/CN=mail.tausys.de i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- MIIFADCCA+igAwIBAgISA/75c4QDGDZgs1OK4vBX3gD3MA0GCSqGSIb3DQEBCwUA ... -----END CERTIFICATE----- subject=/CN=mail.tausys.de issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent --- SSL handshake has read 3152 bytes and written 453 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: D48D4AA295B4F5E4186BDBCC2157577400368E634FBB923710C4EFCE9D3561B2 Session-ID-ctx: Master-Key: 42FF58355ECEBD6CAEE26DAC22853F901AFD86C5F1C12F5815F16B98A3864D34EE8D15720E7F107F8C58D62F7CEC4C00 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - fa 36 66 54 b8 d1 8a da-cd 5d f2 f6 7d 60 7e 68 .6fT.....]..}`~h 0010 - c1 9d 8e fb fc e0 13 3e-e8 9f 46 7a 99 c5 b1 e0 .......>..Fz.... 0020 - 5a 49 01 1b 17 a7 43 c5-f3 6f f8 e4 ff a1 d1 6c ZI....C..o.....l 0030 - df d1 07 e5 db 74 e3 02-c7 d9 54 40 32 78 97 a9 .....t....T@2x.. 0040 - 8c b4 1f b5 e2 cd e9 cc-af 3d d3 1c 31 05 41 7b .........=..1.A{ 0050 - 06 f2 b6 fe e5 ca 8e d0-a3 6a 36 9e 11 6e a8 6a .........j6..n.j 0060 - 80 0d c2 ac fc 7b 16 86-e0 12 e6 47 9f 73 ae 37 .....{.....G.s.7 0070 - 5b e6 ea 52 bf c2 42 59-99 6d 47 07 0f 69 c8 01 [..R..BY.mG..i.. 0080 - 65 1a 3f b5 52 23 fa 74-44 00 1f c9 96 4d fc bb e.?.R#.tD....M.. 0090 - d2 7e e0 ab fc 4c cf c5-dc 23 85 8f 04 d3 1f ed .~...L...#...... Start Time: 1468434962 Timeout : 300 (sec) Verify return code: 0 (ok) --- DONE
Oben sieht man die Zertifikatskette und unten die erfolgreiche Verifizierung des Zertifikats.
Zertifikat in Postfix einbinden
Zwar ist es für SMTP nicht erforderlich, dass die Zertifikate gültig sind (viele SMTP-Server laufen mit selbst signierten Zertifikaten), da eine Überprüfung nicht vorgeschrieben ist. Warum jedoch sollte man das Let's Encrypt Zertifikat nicht verwenden, wenn man schon ein gültiges vorliegen hat? Große Anbieter benutzen selbst bei Mailservern ein von einer CA signiertes Zertifikat.
Das Zertifikat wird für Postfix in /etc/postfix/main.cf eingetragen:
# TLS parameters smtpd_tls_cert_file=/etc/letsencrypt/live/<Domain-Name>/fullchain.pem smtpd_tls_key_file=/etc/letsencrypt/live/<Domain-Name>/privkey.pem smtpd_tls_loglevel=1 smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
Nach einem Neustart von Postfix kann man die korrekte Verwendung des Zertifikats in Postfix wiederrum mit openssl überprüfen. Da hier zuerst von einer ungesicherten Verbindung (SMTP über Port 25) mit STARTTLS auf eine gesicherte Verbindung umgeschaltet werden muss, müssen die Parameter für openssl entsprechend angepasst werden:
$ echo QUIT | openssl s_client -connect mail.tausys.de:25 -CApath /etc/ssl/certs -starttls smtp
Zertifikate automatisch erneuern
Edit: Bei der Installation von certbot aus den Debian-Repositories wird automatisch ein Cron-Job unter /etc/cron.d/certbot angelegt. Dieser kann mit nachfolgenden Informationen entsprechend angepasst werden.
Mit Cron kann certbot periodisch aufgerufen werden und erneuert die demnächst ablaufenden Zertifikate automatisch. Ebenfalls bietet certbot die Möglichkeit bei erneuerten Zertifikaten ein Kommando auszuführen, damit z.B. die Mailservices (hier Dovecot und Postfix) zum Einlesen der neuen Zertifikate neu gestartet werden. Dazu legt man sich als erstes ein Skript z.B. unter /usr/local/sbin/restart_mailservices mit folgendem Inhalt an:
#!/bin/sh
systemctl restart postfix.service
systemctl restart dovecot.service
Das Skript muss nun noch ausführbar gemacht werden:
chmod +x /usr/local/sbin/restart_mailservices
Anschließend kann ein Cron-Job erstellt werden, welcher das folgende Kommando periodisch aufruft:
certbot renew --post-hook /usr/local/sbin/restart_mailservices
Update: neuere Versionen von certbot sollten deploy-hook statt post-hook verwenden (Danke an Andi).
Hi, netter Guide :)
Beim Befehl zum Checken der Postfix-Zertifikateinbindung fehlt ein "t" bei -startTls
Vielen Dank! Schon korrigiert.
Hallo,
Danke für die schöne Anleitung. Hat super funktioniert.
Ein paar Anmerkungen:
Für ubuntu Nutzer gibt es ein ppa: https://launchpad.net/~certbot/+archive/ubuntu/certbot
Für den Posthook gibt es mittlerweile ein dediziertes Verzeichnis:
/etc/letsencrypt/post-hook.d/
Das Verzeichnis wir mit dem automatisch kreierten cron Befehl automatisch eingebunden.
das t von startls fehlt übrigens immer noch ;-)
Danke für die tolle Anleitung!!
bei SuSE Leap (und möglicherweise auch schon früher) spuckt einem bei der Installation der Zertifikate für dovecot noch der AppArmor-Dienst in die Suppe:
"Can't open file /etc/letsencrypt/live//fullchain.pem: Permission denied"
Man kann entweder AppArmor deaktivieren, oder den folgende Zeile in den Dateien /etc/apparmor.d/abstractions/ssl_certs und /etc/apparmor.d/abstractions/ssl_keys ergänzen:
"/etc/letsencrypt/** r,"
Guter Hinweis, für acmetool gab es in den beiden Dateien schon Einträge. Ich habe einen patch mit request im obs eingestellt. Vielleicht kommts upstream: https://build.opensuse.org/request/show/533380
Vielen Dank für die Anleitung!
Bei meinem Dovecot Server funktioniert alles bestens. Beim Testen der PostFix-Einbindung (Debian 4.8.4-1 (Jessie), Postfix 2.11.3, openssl 1.0.1t) bekomme ich einen Fehler:
CONNECTED(00000003)
140121485764240:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:782:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 282 bytes and written 324 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1509817994
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Es scheit allerdings trotzdem alles zu funktionieren, vermutlich wegen dem ja schon von Dir bemerkten Umstand dass es eh' kein verifiziertes Zertifikat für SMTP braucht...
Ich wäre natürlich trotzdem dankbar wenn das richtige Zertifikat verwendet würde und alles so funktionieren würde wie gedacht.
Hast Du eine Idee warum es bei mir nicht geht?
Viele Grüße
Flo
... Hat sich erledigt - war ein Wurstfingerproblem meinerseits: Tippfehler in der main.cf.
Du kannst also meinen Beitrag gestrost löschen... Sorry.
Wenn ich die Doku unter https://certbot.eff.org/docs/using.html#renewing-certificates richtig lese, möchte man zum Neustart der Services keinen post-hook sondern einen deploy-hook nutzen.
In den von mir verwendeten Jessie-Backports ist leider nur die certbot Version 0.10.2 enthalten. Diese kannte deploy-hook noch nicht. Ich habe den Artikel entsprechend angepasst. Danke!
Vielen Dank für die tolle Anleitung! Hat alles super geklappt mit Gentoo+Postfix+Dovecot+Certbot.