Heute zeige ich euch, wie Ihr mit ISPConfig und gratis Zertifikaten von Let´s Ecrypt eure Serverdienste damit absichert.

Eines vorweg, Ihr solltet nicht einfach blind den Anweisungen folgen, sondern diese überdenken, verstehen und bei Bedarf an eure Gegebenheiten anpassen!
Ich kann keinerlei Verwantwortung oder Garantien für Schäden oder gar Datenverlust übernehmen!

Die folgenden Schritte sind sicherlich nur eine Möglichkeit von vielen. Gerne könnt Ihr mir eure eigenen Erfahrungen oder schönere Lösungen zukommen lassen, welche ich bei Bedarf hier auch aktualisieren kann.

Voraussetzungen

Ich gehe hier von einem identischen oder ähnlichen Serversetup aus:
https://www.howtoforge.com/tutorial/perfect-server-debian-8-4-jessie-apache-bind-dovecot-ispconfig-3-1/
oder
https://www.howtoforge.com/perfect-server-debian-wheezy-apache2-bind-dovecot-ispconfig-3

In jeden Fall sollten für sämtliche Konfigurationsdateien, welche verändert werden, eine Sicherung existieren, um schnell die Schritte wieder rückgängig machen zu können!

Ich gehe hier davon aus, dass der Hostname des Servers z.B. server1.example.com lautet, dieser auch als FTP sowie Mail Server eingetragen ist. Als Randnotiz waren die bisherigen Zertifikate bei StartSSL.

Start mit dem ISPConfig Control Panel

Davon ausgehend, dass das Control Panel z.B. mit ispconfig1.example.com aufgerufen werden kann, kann ein Administrator im ISPConfig ein entsprechendes Web anlegen:

• Webseiten → Neue Webseite hinzufügen
• Domain: ispconfig1.example.com
• Auto Subdomain: Keine
• SSL: aktiv
• Let´s Enrcypt SSL: aktiv

Nach wenigen Minuten sollte das Web angelegt sein und das Zertifikat mit eingebunden.
Im Ordner /etc/apache2/sites-available sollten also eine ispconfig.vhost sowie eine ispconfig1.example.com.vhost existieren!

Aus der letzteren Datei kann ca. im unteren Drittel der Bereich mit dem SSL Zertifikat herauskopiert werden. Es sieht ähnlich wie folgt aus:

<IfModule mod_ssl.c>
	SSLEngine on
	SSLProtocol All -SSLv2 -SSLv3
	# SSLCipherSuite          ...
	SSLHonorCipherOrder     on
	# <IfModule mod_headers.c>
	# Header always add Strict-Transport-Security "max-age=15768000"
	# </IfModule>
	SSLCertificateFile /var/www/clients/clientX/webX/ssl/ispconfig1.example.com-le.crt
	SSLCertificateKeyFile /var/www/clients/clientX/webX/ssl/ispconfig1.example.com-le.key
	SSLCertificateChainFile /var/www/clients/clientX/webX/ssl/ispconfig1.example.com-le.bundle
	SSLUseStapling on
	SSLStaplingResponderTimeout 5
	SSLStaplingReturnResponderErrors off
</IfModule

Mit diesem Code können wir nun den Teil für das alte Zertifikat überschreiben, welches z.B. wie folgt aussehen könnte:

# SSL Configuration
SSLEngine On
SSLProtocol All -SSLv3
SSLCertificateFile /etc/ssl/meincert/meincert.de.crt
SSLCertificateKeyFile /etc/ssl/meincert/meincert.de.key
SSLCACertificateFile /etc/ssl/meincert/startssl.chain.class2.server.crt

Nun kann der Apache2 neu gestartet werden und ISPConfig sollte dann auch schon mit Let´s Encrypt ausgeliefert werden:

service apache2 restart

Als kleine Erklärung, wie das funktionieren kann, der ispconfig.vhost hat eine höhere Priorität als der ispconfig.example.com.vhost. Dies kann man erkennen, wenn man in /etc/apache2/sites-enabled blickt. Der erstere hat drei 000 davor, der letztere eine 100.

phpMyAdmin & Roundcube & Andere Dienste

Ganz ähnlich funktioniert es mit phpMyAdmin, Roundcube oder auch anderen Diensten. Ihr legt ein entsprechendes Web an, erstellt einen neuen vHost mit höherer Prio und kopiert das neu angelegte Zertifikat in den gültigen vHost.

Die alten vHost Dateien können wie folgt kopiert und aktiviert werden. Sicherheitshalber deaktiviere ich hier auch den alten, nicht mehr notwendigen vHost, entferne ihn oder benenne ihn um:
Hier gehe ich davon aus: phpmyadmin1.example.com & roundcube1.example.com

cp /etc/apache2/sites-available/phpmyadmin.conf /etc/apache2/sites-available/000-phpmyadmin.conf
cp /etc/apache2/sites-available/roundcube.conf /etc/apache2/sites-available/000-roundcube.conf

a2dissite phpmyadmin.conf
a2ensite 000-phpmyadmin.conf

a2dissite roundcube.conf
a2ensite 000-roundcube.conf

mv /etc/apache2/sites-available/phpmyadmin.conf /etc/apache2/sites-available/phpmyadmin.confBACKUP
mv /etc/apache2/sites-available/roundcube.conf /etc/apache2/sites-available/roundcube.confBACKUP

Nun noch wie bei ISPConfig auch den Zertifikatsteil einbinden und dann den Apache2 neu Starten.

Munin & Monit zur Analyse & Überwachung

Mit Munin könnt Ihr genauso vorgehen, wie mit den Anderen. Bei Monit läufts etwas anders, da Monit bisher nur über einen Port erreichbar war z.B. server1.example.com:12345

Grundsätzlich legt Ihr auch hier erstmal ein Web wie gehabt an, damit wir an ein Zertifikat kommen. z.B. monit1.example.com

Hier ist dann noch ein eigener vHost nötig, z.B. /etc/apache2/sites-available/000-monit.vhost mit ähnlichem Inhalt:

# Monit default Apache configuration

<VirtualHost *:80>
    ServerName monit1.example.com
    RewriteEngine On
    RewriteCond %{SERVER_PORT} 80
    RewriteRule ^(.*)$ https://monit1.example.com$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
    ServerAdmin 
    ServerName monit1.example.com

    <IfModule mod_ssl.c>
	SSLEngine on
	SSLProtocol All -SSLv2 -SSLv3
	# SSLCipherSuite          ...
	SSLHonorCipherOrder     on
	# <IfModule mod_headers.c>
	# Header always add Strict-Transport-Security "max-age=15768000"
	# </IfModule>
	SSLCertificateFile /var/www/clients/clientX/webX/ssl/monit1.example.com-le.crt
	SSLCertificateKeyFile /var/www/clients/clientX/webX/ssl/monit1.example.com-le.key
	SSLCertificateChainFile /var/www/clients/clientX/webX/ssl/monit1.example.com-le.bundle
    </IfModule>

	ProxyPreserveHost On
	ProxyRequests Off
	ProxyVia Off
	SSLProxyEngine On
	ProxyPass / https://monit1.example.com:12345/
	ProxyPassReverse / https://monit1.example.com:12345/
</VirtualHost>

Damit die Umleitung auch funktioniert, benötigt es noch 2 Apache Module, welche wir gleich mit dem vHost aktivieren:

a2ensite 000-monit.conf
a2enmod proxy
a2enmod proxy_http
service apache2 restart

Damit sollte nun Monit wieder erreichbar sein! Denkt auch daran, die URL in eurem ISPConfig anzupassen unter: Sytem → Serverkonfiguration → euer Server → Monit-URL.

An dieser Stelle hatte ich bemerkt, dass auf Wheezy Geräten eine Monit 5.4 Version installiert war, welche bei Aktionen einen CSRF Fehler bringen. Dies hatte nichts mit dieser Umstellung zu tun, sondern mit dem veralteten Monit. Die Installation eines neueren Monits z.B. aus den Backports brachte abhilfe:

apt-get -t wheezy-backports install -y "monit"

Hostname & Email Absicherung

Damit auch die Emails über Let´s Encrypt empfangen & versendet werden können, habe ich einfach meinen Hostnamen ebenfalls im ISPConfig wie gehabt eingetragen. In dem Beispiel server1.example.com. Dieser steht also in allen Mail Clienten, welche verschlüsselt abrufen.

Schritte für den Posteingang Dovecot:

mcedit /etc/dovecot/dovecot.conf

ssl_cert = </etc/letsencrypt/live/server1.example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/server1.example.com/privkey.pem
#ssl_cert = </etc/postfix/smtpd.cert
#ssl_key = </etc/postfix/smtpd.key
#ssl_ca = /etc/ssl/meins/startssl.chain.class2.server.crt

Hier habe ich lediglich die alten Zertifikate auskommentiert und die Orte der neuen Zertifikate eingetragen.

Überprüft werden kann dies relativ einfach mit einem openssl Befehl:

echo QUIT | openssl s_client -connect server1.example.com:993 -CApath /etc/ssl/certs

Am Besten vor dem Dovecot Neustart einmal prüfen, da sollte das alte Zertifikat ausgelesen werden. Dann Dovecot neu starten und erneut den letzten Befehl ausführen sollte das neue Zertifikat zeigen:

service dovecot restart

Schritte für den Postausgang Postfix:

mcedit /etc/postfix/main.cf

smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/server1.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/server1.example.com/privkey.pem
#smtpd_tls_cert_file = /etc/postfix/smtpd.cert
#smtpd_tls_key_file = /etc/postfix/smtpd.key
#smtpd_tls_CAfile = /etc/ssl/meins/startssl.chain.class2.server.crt
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

Hier habe ich lediglich die alten Zertifikate auskommentiert und die Orte der neuen Zertifikate eingetragen.

Hier braucht es jedoch einen etwas anderen openssl Befehl:

echo QUIT | openssl s_client -connect server1.example.com:25 -CApath /etc/ssl/certs -starttls smtp

Am Besten vor dem Postfix Neustart einmal prüfen, da sollte das alte Zertifikat ausgelesen werden. Dann Postfix neu starten und erneut den letzten Befehl ausführen sollte das neue Zertifikat zeigen:

service postfix restart

Hier solltet Ihr auch sicherstellen, dass noch alles funktioniert!

Pure FTP Absicherung

Ein wenig komplexer hat sich die Sache mit PureFTP herausgestellt, da die Let´s Encrypt Zertifikate eine Zertifikate ausliefern, welche auch den Key beinhalten. Eine solche "zusammengefasste" PEM Zertifikatsdatei möchte aber der PureFTP.

Als FTP nehme ich an, dass server1.example.com verwendet wird, insofern kann relativ einfach eine kombinierte Zertifikatsdatei erstellt werden:

rm /etc/ssl/private/pure-ftpd.pem
cat /etc/letsencrypt/live/server1.example.com/privkey.pem /etc/letsencrypt/live/server1.example.com/fullchain.pem > /etc/ssl/private/pure-ftpd.pem

Als erstes entferne ich das alte Zertifikate für den PureFTP.
Dann erstelle ich aus dem PrivateKey und dem Fullchain Zertifikat ein neues. Nun muss nur noch PureFTP neu gestartet werden und schon klappts.

service pure-ftpd-mysql restart

ABER:
Let´s Encrypt Zertifikate laufen nur 90 Tage! Das würde heißen, dass nach 90 Tagen der PureFTP ein veraltetes Zertifikat ausliefert. Schließlich bekommt er von dem Wechsel mit genannter Variante nichts mit.

Und hierfür habe ich ein kleine Bash Script geschrieben, welches ich für euch hier angehängt habe.

Ladet die Textdatei herunter und benennt sie z.B. in renew-ftp-cert.sh um. Diese könnt Ihr auf euren Server laden z.B. unter /scripte/renew-ftp-cert.sh

Die Datei kann mit folgenden Parametern verwendet werden:

• -h = Hilfe
• -w = Ausgabe aktiv
• -c = Name des Zertifikats

Es kann also wie folgt verwendet werden:

sh renew-ftp-cert.sh -wc server1.example.com

Dies gibt auch die Ausgabe aus wie den Ordner und den Erfolg.

Wenn Ihr das W im Parameter weg lässt, wird nichts ausgegeben.

Dies habe ich eingebaut, um den folgenden Cronjob eine Zeit lang zu überwachen, da ich aber nicht möchte, dass er auf Lebzeiten meine Logfiles unnötig vollschreibt, eben die Option.

Hier noch der Cronjob in der /etc/crontab, welche täglich um 6 Uhr ausgeführt wird und mir die Ausgaben/oder auch nicht in die /var/log/cron.log schreibt:

*   6 * * *	root	/scripts/renew-ftp-cert.sh -wc server1.example.com >> /var/log/cron.log

Das stellt nun sicher, dass wenn sich das Zertifikat irgendwann mal änder, es täglich mit geändert wird. Je nachdem wann die Zertfikate also erneuert werden, kann es eine Latenz bis knapp 24h geben! Ist euch das zu lange, könnt Ihr natürlich jederzeit händisch das Script aufrufen oder auch die Ausführzeit verkürzen.

Ich hoffe den Ein oder Anderen damit helfen zu können und freue mich auf eventuelle Feedbacks.

Anhänge:

renew-ftp-cert.txt

[ ]

1 KB