Springe zum Inhalt

Let’s Encrypt Zertifikate für Dovecot und Postfix

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

10 Gedanken zu „Let’s Encrypt Zertifikate für Dovecot und Postfix

  1. Tony

    Hi, netter Guide :)
    Beim Befehl zum Checken der Postfix-Zertifikateinbindung fehlt ein "t" bei -startTls

  2. Mathias

    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 ;-)

  3. Peter Münstermann

    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,"

  4. Flo

    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

    1. Flo

      ... Hat sich erledigt - war ein Wurstfingerproblem meinerseits: Tippfehler in der main.cf.
      Du kannst also meinen Beitrag gestrost löschen... Sorry.

    1. Jens Tautenhahn

      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!

  5. Timo Antweiler

    Vielen Dank für die tolle Anleitung! Hat alles super geklappt mit Gentoo+Postfix+Dovecot+Certbot.

Kommentare sind geschlossen.