Wildcard-Zertifikate sind Zertifikate, die für *.domain.tld gültig sind. Also zum Beispiel foo.domain.tld oder bar.domain.tld und jede andere Subdomäne. Das Praktische dabei ist, dass man nicht für jede Subdomäne ein eigenes Zertifikat anlegen muss, sondern ein und das selbe Zertifikat für alle Subdomänen nutzen kann.
Damit Let’s Encrypt aber ein Wildcard-Zertifikat ausstellt, muss man Let’s Encrypt beweisen, dass man Herr der ganzen Domäne domain.tld ist. Dies kann aber nicht über die herkömmliche Validierung per HTTP-Challenge/Response-Protokoll erfolgen, sondern setzt ein Challenge/Response-Protokoll voraus, bei dem die Response als TXT-Record im DNS veröffentlich wird. Die Annahme dabei ist: „wer DNS kontrollieren kann, dem gehört die Domäne“.
Viele, die eine Domain besitzen, werden das Problem kennen: Der Registrar bietet zwar eine WebUI an, über die man die DNS-Records der Domain verwalten kann, aber diese ist in ihrer Funktionalität sehr eingeschränkt. Man kann dort vielleicht Standard-Records wie CNAME-Records anlegen, die für Subdomains benötigt werden, aber etwas exotischere Dinge wie TXT-Records oder gar CAA-Records fehlen. Auch kann das DNS nur über die WebUI konfiguriert werden, was z.B. Anwendungen wie DynDNS und auch das Ausstellen von Wildcard-Zertifikaten mit Let’s Encrypt unmöglich macht – also Szenarien, in denen ein Programm über die API automatisiert irgendwelche Änderungen am DNS vornehmen können muss.
Nach einigem Suchen bin ich auf desec.io gestoßen, einen kostenlosen DNS-Dienst, der sehr (!) viele Einstellungsmöglichkeiten per WebUI und API bietet. Um desec.io mit der eigenen Domain nutzen zu können, muss man allerdings beim Registrar die DNS-Server von desec.io als autoritative Nameserver einstellen können. Ansonsten funktioniert das leider nicht.
Da sich die APIs von DNS-Dienst zu DNS-Dienst unterscheiden, benötigt der Certbot ein Plugin, über das die DNS-Response veröffentlicht werden kann. Certbot ist sozusagen der Let’s Encrypt-Client, der sich quasi vollautomatisch um die Erzeugung der Zertifikate und auch um die Konfiguration des Webservers kümmert. Das nötige Certbot-Plugin wird von desec.io bereit gestellt und kann einfach über pip3 nachinstalliert werden. Ich habe aber festgestellt, dass mein bereits per apt installierter Certbot mit diesem Plugin nicht kompatibel ist. Ich habe daher alle certbot-apt-Pakete erstmal deinstalliert. Danach habe ich per pip3 install certbot certbot-dns-desec certbot-nginx Certbot und die nötigen Plugins wieder installiert.
Damit der Certbot mit desec.io über die API „sprechen“ kann, wird ein Authentifizierungs-Token benötigt. Dieses kann über die desec.io WebUI bezogen werden. Nun erzeugt man sich eine Datei mit dem Inhalt dns_desec_token = TOKEN und speichert diese mit dem Namen domain.tld.token ab.
Als letzten Schrit führt man folgenden Befehl in der Shell aus:
certbot --authenticator dns-desec --dns-desec-credentials domain.tld.token \ -d "domain.tld.token" -d "*.domain.tld.token"
Man muss einigen Anweisungen in der Shell folgen, was eigentlich völlig selbsterklärend ist. Am Ende des Prozesses fragt Certbot freundlich nach, ob das neue Zertifikat in die Config-Datei des Webservers eingetragen werden soll. Ja, bitte! Überrascht hat mich, dass Certbot verstanden hat, dass auf meinem Server ein nginx und kein Apache läuft. Früher musste man das Certbot über einen extra Schalter mitteilen. Aber egal.
Da Let’s Encrypt-Zertifikate eine maximale Laufzeit von 90 Tagen haben, muss man sich regelmäßig ein neues Zertifikat ausstellen lassen. Dies geschieht über den nahezu identischen Befehl:
certbot certonly --authenticator dns-desec --dns-desec-credentials domain.tld.token \-d "domain.tld.token" -d "*.domain.tld.token"
Das certonly sorgt dafür, dass Certbot nicht mehr fragt, ob das Zertifikat in der Config-Datei des Webservers eingetragen werden soll. So kann der Befehl auch in ein kleines Skripts geschrieben werden, welches z.B. am Ende jeden Monats als Cronjob automatisch und ohne weitere Nutzereingaben ausgeführt wird. Dabei ist noch zu beachten, dass man den Pfad setzen muss, da sonst der Certbot nicht gefunden wird. Das ganze Skript kann etwa so aussehen:
#!/bin/bash
exec &> /dev/zero
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
certbot certonly --authenticator dns-desec --dns-desec-credentials domain.tld.token \-d "domain.tld.token" -d "*.domain.tld.token"
Schreibe einen Kommentar