Nachdem mein Webserver Zertifikat von StarSSL ausgelaufen ist und dieser Zertifizierungsstelle (u.a. auch WoSign), das Vertrauen entzogen wurde (Mozilla macht Ernst), muss eine andere kostenlose CA herhalten. Da ich auch schon bei Uberspace auf Let’s Encrypt Zertifikate setzen kann, wollte ich diese CA auch für meine privat gehosteten Seiten nutzen.
Und da stoßen wir auf das Problem! Der Webserver, bzw. eigentlich die MikroTik Firewall, veröffentlicht z.B. die Nextcloud nicht über die Standard-Ports (80/443). Daher funktioniert auch eine einfache Lösung, mit Hilfe von z.B. Certbot nicht. Denn die Reverse Anfrage vom Let’s Encrypt wird mit dem herkömmlichen Verfahren (http-01) immer über die Standard-Ports ablaufen. Nach kurzer Suche konnte ich das Problem identifizieren und herausfinden, dass es noch ein weiteres Verfahren gibt. Dieses Verifiziert die Domäne über DNS (dns-01). Diese sogenannte DNS challenge wird mit Hilfe von TXT-Einträgen im DNS für die Domäne durchgeführt.
Für die DNS Verifizierung gibt es viele Skripte, die über die API des Providers einen DNS-Eintrag machen, so dass Let’s Encrypt dadurch für die Domäne/Subdomäne ein Zertifikat ausstellt. Da viele meiner Domänen bei INWX liegen, ich somit volle Kontrolle über die DNS-Einträge habe, musste ich einen Client finde der die API von INWX bedienen kann. Auch hier bin ich schnell fündig geworden, ein Repository womit es sehr einfach zu realisieren ist könnt Ihr auf GitHub finden.
Mein besagter Webserver, ein Apache2, läuft auf Debian 9. Ich gehe davon aus, dass die SSL Konfiguration für die Website vorhanden ist und auch PHP mindestens in Version 5.5.0 installiert ist. Der Webserver ist von außen nicht über die Standard-Ports erreichbar. Im DNS ist aber ein A-Record auf die IP-Adresse zum Webserver eingetragen.
Wie schon in der Readme.md von ACME-DNS-INWX beschrieben, Klonen oder downloaden wir als erstes das Repository.
git clone https://github.com/Op3rat0r/acme-dns-inwx.git
Im Ordner /acme-dns-inwx/config befindet sich die .inwx.ini Datei. Diese wird mit cp .inwx.ini ~/ ins Homeverzeichnis kopiert. In der Datei werden die Zugangsdaten für den INWX-Acccount eingetragen. Damit nur Euer Benutzer Zugriff auf die ini-Datei hat, werden die Zugriffsberechtigungen noch angepasst.
chmod 0600 ~/.inwx.ini
Um zu prüfen ob die Verbindung zu INWX schon funktioniert, wird jetzt mit dem Skript ein TXT Rekord erstellt. Dabei kann es zur Fehlermeldung kommen, dass einige PHP-Module fehlen. Diese müssen dann noch nachinstalliert werden, siehe hierzu auch das Wiki.
./scripts/acme-dns-inwx "yourdomain.de" "test"
Nach kurzer Wartezeit kann man den DNS-Server auf den neuen Eintrag abfragen.
dig TXT "_acme-challenge.yourdomain.de" +short
Die TTL für den TXT-Rekord beträgt 300 Sekunden. Um zu prüfen ob die Funktion zum Löschen ebenfalls klappt, wird der Befehl nun noch einmal mit –del ausgeführt.
./scripts/acme-dns-inwx --del "yourdomain.de"
Soweit wäre alles für die DNS challenge vorbereitet. Als nächstes habe ich, um ein SSL Zertifikat bei Let’s Encrypt zu beantragen, ein weiteres Repository getSSL geklont.
cd /etc git clone https://github.com/srvrco/getssl cd getssl
Jetzt wird ein getSSL Verzeichnis und Konfigurationsdatei für die besagte Domäne erstellt.
./getssl -c yourdomain.de
Der Befehl wird mit username@JUSTITSRV01:/etc/getssl# creating domain config file in /username/.getssl/yourdomain.de/getssl.cfg bestätigt. Mit dem Befehl wird ein Verzeichnis (~/.getssl) im Homepfad angelegt. Darunter befinden sich dann Verzeichnisse für alle Domänen die zuvor angelegt wurden.
~/.getssl
~/.getssl/getssl.cfg
~/.getssl/yourdomain.com
~/.getssl/yourdomain.com/getssl.cfg
Die Default-Konfigurationsdatei liegt direkt im obersten getSSL Verzeichnis. Hier werden die Werte eingestellt, die für alle Domänen gleich sind. Das sind in diesem Beispiel auf jeden Fall die Einstellungen zur DNS Validierung, sowie die E-Mailadresse und Einstellungen zum Account-Key. Im Wiki zu ACME-DNS-INWX kann man diese Einstellungen für die DNS Validierung ebenfalls finden.
VALIDATE_VIA_DNS="true" DNS_ADD_COMMAND="$HOME/acme-dns-inwx/scripts/acme-dns-inwx --add" DNS_DEL_COMMAND="$HOME/acme-dns-inwx/scripts/acme-dns-inwx --del"
Empfohlen, aber nicht erforderlich.
CHECK_ALL_AUTH_DNS="true" #AUTH_DNS_SERVER="ns.domrobot.com" DNS_WAIT=10 DNS_EXTRA_WAIT=60
In der getssl.cfg Datei für die Domäne muss dann hauptsächlich der Pfad hinterlegt werden, wo die erzeugten Zertifikate abgelegt werden sollen. Das kann, muss aber nicht, direkt der Pfad sein auf die der Webserver (hier: Apache2) für besagte Domäne zugreift.
DOMAIN_CERT_LOCATION=“/etc/apache2/ssl/pub/yourdomain.de/yourdomain.de.crt“
DOMAIN_KEY_LOCATION=“/etc/apache2/ssl/priv/yourdomain.de/yourdomain.de.key“
CA_CERT_LOCATION=“/etc/apache2/ssl/pub/yourdomain.de/chain.crt“
Nach dem das Zertifikat abgespeichert wurde, sollte der Webserver seine Konfiguration neu einlesen.
RELOAD_CMD=“service apache2 reload“
Unter dem Punkt SANS=““ würde, wenn es sich bei der Domäne um keine Subdomäne handelt, direkt noch die Domäne mit www vorangestellt eingetragen werden SANS=“www.yourdomain.de“. An dieser Stelle können noch weitere Domänen eingetragen werden, aber nicht die primäre Domäne.
Die Beispiel getssl.cfg Dateien gibt es auch als Download. Die default-getssl.cfg sowie die domain-getssl.cfg für die einzelnen Domänen.
Ist alles richtig konfiguriert, kann die Ausgabe beim Ausführen von getssl -f yourdomain.de so aussehen:
username@JUSTITSRV01:~/.getssl/yourdomain.de# /etc/getssl/getssl -f yourdomain.de creating account key /root/.getssl/account.key creating key - /root/.getssl/account.key Generating RSA private key, 4096 bit long modulus ..........................++ ......++ e is 65537 (0x010001) creating key - /root/.getssl/yourdomain.de/yourdomain.de.key Generating RSA private key, 4096 bit long modulus .....................................................................................++ .......................................................................++ e is 65537 (0x010001) creating domain csr - /root/.getssl/yourdomain.de/yourdomain.de.csr Registering account Registered Verify each domain Verifying yourdomain.de Verifying www.yourdomain.de sleeping 60 seconds before asking the ACME-server to check the dns Verified yourdomain.de Pending Verified www.yourdomain.de Verification completed, obtaining certificate. Certificate saved in /root/.getssl/yourdomain.de/yourdomain.de.crt The intermediate CA cert is in /root/.getssl/yourdomain.de/chain.crt copying domain certificate to /etc/apache2/ssl/pub/yourdomain.de/yourdomain.de.crt copying private key to /etc/apache2/ssl/priv/yourdomain.de/yourdomain.de.key copying CA certificate to /etc/apache2/ssl/pub/yourdomain.de/chain.crt reloading SSL services certificate obtained for yourdomain.de
Jetzt sind die erforderlichen Zertifikat-Dateien in die dafür konfigurierten Ordner gespeichert worden. Der Apache-Webserver hat ein Reload gemacht und sofern die Konfiguration vorher schon richtig abgeschlossen war, sollte das Zertifikat einwandfrei funktionieren. Im Ubuuntuuser Wiki gibt es einen guten Artikel über getSSL. Dieser beinhaltet auch die Konfiguration über http, der aber nicht mehr Bestandteil meines Setup ist. Im Wiki von getSSL kann man alle Variablen und Ihre Bedeutung nachlesen.
Damit die automatische Aktualisierung funktioniert, kann man einen Cronjob einrichten. Dieser prüft dann z.B. wöchentlich, die Zertifikate und ob es Updates für getSSL gibt.
crontab -e -u root
Der Eintrag könnte so aussehen. Die Parameter von getSSL kann man auch im Ubuntuuser Wiki nachlesen sowie im getSSL Wiki.
# Let' Encrypt # SSL Zertifikate auf updates prüfen, jeden Samstag um 01:00 Uhr 0 1 * * 6 /etc/getssl/getssl -a -q -u
Man kann im Crontab auch einen ausführbaren Skript angeben. Dort würden dann die Parameter stehen die getSSL ausführen soll.
0 1 * * 6 /server/certs/renew-certificates.sh > /dev/null 2>&1
Quellen
[1] ACME-DNS-INWX – https://github.com/Op3rat0r/acme-dns-inwx
[2] getSSL – https://github.com/srvrco/getssl
[3] INWX – https://github.com/inwx
[4] Let’s Encrypt – https://letsencrypt.org/docs/client-options/
[5] Ubuntuuser Wiki (getSSL) – https://wiki.ubuntuusers.de/Howto/getssl/
[6] Bartleweb Blog – https://blog.bartlweb.net/2017/01/lets-encrypt-in-enterprise-setups-ohne-dns-validierungsmoglichkeit-per-http-validierung-einrichten/
[7] digicert – https://www.digicert.com/ssl-certificate-installation-apache.htm
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!
ich bin gerade auf das hier gestoßen
https://github.com/oGGy990/certbot-dns-inwx
es macht es um einiges einfacher..
Servus Timmy,
danke für diesen Hinweis. Werde ich mir bei Zeit mal ansehen!
VG
Daniel