• Homepage
  • >
  • Software
  • >
  • Zertifikate: So harmonieren Let’s Encrypt und der Kerio Connect-Mailserver

Zertifikate: So harmonieren Let’s Encrypt und der Kerio Connect-Mailserver

Wer nicht zwingend auf den Exchange Server von Microsoft setzen möchte und auch für Cloud-Derivate wie Office 365 nichts übrig hat, wird die Augen nach Alternativen aufhalten. Hier kommt Kerio Connect ins Spiel, der zu einem tollen Preis-/Leistungsverhältnis viele Exchange-Features bietet und für kleine wie große Unternehmen geeignet ist. Knackpunkt einer jeden Installation: Die Zertifikate. Wie Ihr den Kerio Connect nun auch mit Let’s Encrypt erfolgreich ans Laufen bekommt, möchte ich nun nachfolgend zeigen.

Die Kür nach der Pflicht, den Mailserver aufgesetzt und konfiguriert zu haben, ist die Installation der SSL-Zertifikate, um intern wie extern eine verschlüsselte Verbindung zu seinen Diensten gewährleisten zu können. Beim Kerio Connect Mailserver war auch im Kundenbereich bisher immer der Standard, ein Zertifikat über die Administrationsoberfläche einzuspielen oder dort eine Zertifikatsanforderung zu generieren. Das Abbilden der Let’s Encrypt-Zertifikate und die Erneuerung dieser alle 90 Tage gehen mit Bordmitteln hier nicht. Mit ein wenig Eigeninitiative kann man hier aber Abhilfe schaffen, sofern Kerio Connect unter einem Linux-System – hier Debian 8 – installiert ist und auch das automatische Verlängern der Zertifikate ist dann via Cron-Eintrag auch möglich!

Der erste Schritt ist das Deaktivieren des HTTP-Dienstes und das Verlegen des HTTPS-Dienstes von Port 443 auf – beispielsweise – 8843. Grund hierfür ist die Tatsache, dass der CertBot, den wir für Let’s Encrypt benutzen wollen, freien Zugriff auf diese Ports braucht, um die Zertifikate generieren und später auch verlängern zu können. In der Kerio Connect-Verwaltung sieht das dann wie folgt aus, wobei die Startart bei „HTTP“ noch von „Automatisch“ auf „Manuell“ gestellt werden sollte:

Als Mittelweg für die Zertifikatsanfragen dient ein Nginx-Webserver, der hier als reverse Proxy fungiert und sich jetzt und in Zukunft um die Zertifikatsanfragen und die Weiterleitungen auf den neuen Management-Port 8843 kümmern soll. Ein weiterer Vorteil: Weitere Webdienste können bei Bedarf auch über Nginx bereitgestellt werden.

Erstellen wir also zunächst das Hauptdatenverzeichnis für Nginx und weisen dann dem www-data-Nutzer unter dem jeweiligen Linux-System die Rechte zu:

mkdir -p /var/www/mail
chown www-data:www-data /var/www/mail

Anschliessend installieren wir die Pakete für nginx und ssl-cert:

apt-get install nginx ssl-cert

Ist das erfolgt, legen wir nun nachfolgend eine Konfigurationsdatei /etc/nginx/sites-available/kerio-connect.conf an, die das weitere Verhalten von Nginx in Verbindung mit unserem gewünschten Einsatzzweck steuern soll. Der Inhalt dieser Datei sollte wie folgt aussehen, natürlich muss der Platzhalter name.euresmailservers.de mit dem richtigen Namen Eures Hosts ersetzt werden!

server {
listen 80;
server_name name.euresmailservers.de;
server_name_in_redirect off;
rewrite ^ https://$server_name$request_uri? permanent;
}

server {
listen 443 ssl;
server_name name.euresmailservers.de;

ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;

location /.well-known {
alias /var/www/mail/.well-known;
}

location / {
proxy_pass https://localhost:8843;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Remote-Port $remote_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
}
}

Ist dies erfolgt, haben wir die Basis für Nginx fast geschaffen. Nun müssen wir die just geschaffene Konfigurationsdatei noch als aktive Nginx-Webseite deklarieren – schaffen tun wir dies durch einen Link:

ln -s /etc/nginx/sites-available/kerio-connect.conf /etc/nginx/sites-enabled/kerio-connect.conf

Nun starten wir einen Testlauf durch Eingabe von nginx -t um zu schauen, ob die Konfigurationsdatei korrekt eingelesen werden kann und die Konfiguration gegebenenfalls noch Fehler enthält. Ist dies nicht der Fall, starten wir durch den Befehl systemctl restart nginx.service den Webdienst einmal neu und wenden uns nun dem CertBot zu.

Wir laden das Paket herunter und geben die passenden Rechte, um den CertBot auch ausführen zu können:

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto

Anschliessend starten wir ohne weitere Parameter das Tool, um etwaige Abhängigkeiten zu überprüfen.

./certbot-auto

Nun geben wir im folgenden Befehl unser unlängst erstelltes Webroot-Verzeichnis samt unseres Domain-Namens an

./certbot-auto certonly –webroot -w /var/www/mail -d name.euresmailservers.de

Beim ersten Ausführen werden wir noch nach einer E-Mail-Adresse gefragt. Diese wird für Recovery-Zwecke und Meldungen beim Zertifikatsablauf genutzt. Ist das erfolgt und auch Port 80 und 443 sind nur durch den Nginx-Webserver in Benutzung, sollten wir erfolgreich ein Zertifikat abgeholt haben.

Nun gilt es, der Nginx-Konfiguration dieses Zertifikat auch bekannt zu machen. Wir editieren also in der Datei /etc/nginx/sites-available/kerio-connect.conf die folgenden Zeilen

ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;

und ändern diese entsprechend unserer Pfade, in denen die frischen Zertifikate liegen

ssl_certificate /etc/letsencrypt/live/name.euresmailservers.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/name.euresmailservers.de/privkey.pem;

Nach einem Neustart des Nginx-Dienstes sollte auch das passen und wir vereinfachen die Zertifikats-Ablage für den Kerio Connect-Mailserver noch ein wenig: Zwei symbolische Links legen die Zertifikate sauber in die Ordner-Hierarchie von Kerio ab und nach einem Neustart des Kerio-Dienstes (entweder über das Webinterface oder den Befehl service kerio-connect restart)

ln -s /etc/letsencrypt/live/name.euresmailservers.de/fullchain.pem /opt/kerio/mailserver/sslcert/mail.crt
ln -s /etc/letsencrypt/live/name.euresmailservers.de/privkey.pem /opt/kerio/mailserver/sslcert/mail.key

sollte der Mailserver das Zertifikat nun korrekt anzeigen. Unter Konfiguration -> SSL-Zertifikate ist nun das neue Let’s Encrypt-Zertifikat zu finden, welches wir mit einem Rechtsklick noch als Standard festlegen.

Damit auch der Browser das Zertifikat versteht und Euch anschliessend die Administrations-Oberfläche als „sicher“ deklariert, heißt es nun: Abmelden und Browser schliessen, um das Admin-Interface noch einmal neu aufzurufen. Verbindungen via Exchange Active Sync via Port 443 werden dann nun – Nginx sei Dank – auf unseren sicheren Port 8843 weitergeleitet, so dass der Kerio Connect Mail-Server nun vollumfänglich via Let’s Encrypt-SSL abgesichert ist.

Wer – quasi als Sahnehäubchen – noch eine automatische Verlängerung des Zertifikates anstreben möchte, wird ein wenig mehr machen müssen, als zu gewünschten Zeitpunkten den Befehl ./certbot-auto renew in die Konsole zu hacken.

Kopiert zunächst das certbot-auto-Executable vom Pfad /etc/nginx/sites-available in einen allgemein geläufigen Pfad Eures Linux-Systems:

cp certbot-auto /usr/local/bin/

Anschliessend erstellen wir ein Skript, welches das Abholen der Zertifikatsverlängerung plus den notwendigen Neustart des Webservers regeln soll. Ich habe dies beispielsweise unter /root/certbot-post-hook.sh abgelegt und den folgenden Inhalt verwendet:

#!/bin/sh
systemctl restart nginx.service
systemctl restart kerio-connect.service

Das Ganze wurde dann noch ausführbar gemacht:

chmod 500 /root/certbot-post-hook.sh
chown root:root /root/certbot-post-hook.sh

Nun soll das Skript über den Cron-Dienst zu festgelegten Zeiten ausgeführt werden – dafür erstellen wir im Ordner /etc/cron.d die Datei certbot und geben ihr den folgenden Inhalt:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 3 * * * root perl -e ’sleep int(rand(3600))‘ && certbot-auto -q renew –post-hook „/root/certbot-post-hook.sh“

Dieser Eintrag sorgt dafür, dass das Skript jeden Tag um 03 Uhr morgens ausgeführt wird, ein wenig ruht und anschliessend das gerade angelegte Skript zur Erneuerung des Zertifikates aufruft. Da der Neustart eines Mailservers zu Produktivitätszeiten nicht wirklich sinnvoll ist und sowohl Webserver- als auch Kerio-Dienst neu gestartet werden, wurde das im vorliegenden Fall auf drei Uhr morgens verlegt.

CertBot selbst empfiehlt übrigens, das Verlängern des Zertifikates maximal zweimal pro Tag durchzuführen – bei 90 Tagen Zertifikatslaufzeit könnt Ihr den Update-Rhythmus auf Euren Systemen selbstverständlich frei und großzügiger wählen!

(via irulan.net)

 

 

  • facebook
  • googleplus
  • twitter
  • linkedin
  • linkedin
  • linkedin

Stolzer Familienvater. Digital Native und chronischer Device-Switcher. Multimedia-Freak. UK-Fan, auch mit Brexit. Blogger mit stets zu wenig Zeit. Hobbyphilosoph. Musik-Enthusiast. Querdenker. Zyniker. Hauptberuflicher IT-Consultant- & Vertriebler. Auch zu finden bei XING. Dieser Artikel hat einen Job oder zumindest Euren Seelenfrieden gerettet und gegebenfalls sogar für Kurzweil gesorgt? Die PayPal-Kaffeekasse freut sich - dankeschön!

  • facebook
  • twitter
  • googleplus
  • linkedIn
  • instagram
  • telegram

Kommentar verfassen