Let’s Encrypt Wildcard-Zertifikate erstellen

Language: Deutsch | English

Da die Wildcard-Zertifikate jetzt live sind, stellt sich für einige die Frage, wie man an diese herankommt. Wie schon beschrieben ist die DNS domain validation momentan der einzige Weg.

Und so wird es im Beispiel des certbots gemacht: sofern die aktuellste Version des certbots installiert ist (habe für das Beispiel die git-Version benutzt), folgendes Kommando eingeben und vgapps.de durch die eigene Domain ersetzen.

(es kann sein, dass certbot durch ./certbot-auto im Beispiel der Git-Version ausgetauscht werden muss)
Warum die --server -Option? Bei bestehenden Let’s Encrypt-Installationen (wie bei meiner) kann es passieren, dass der alte ACME v1-Endpoint als default genommen wird, an dem die Wildcard-Certs aber noch nicht funktionieren. Deshalb müssen wir etwas nachhelfen. Aufgrund des neuen Endpunkts muss wahrscheinlich intern ein neues Konto angelegt werden, weshalb eure E-Mail-Adresse und eine Bestätigung der Nutzungsbedingungen (erneut) abgefragt werden.

Hiernach (und dem OK, dass Let’s Encrypt die IP der anfragenden Instanz öffentlich loggt) wird folgender Text (ähnlich und natürlich bezogen auf eure Domaindaten) angezeigt:

Der Key muss nun als TXT-Record in der jeweiligen Zone angelegt werden. Danach Enter drücken.

Hiernach wird, wenn die Optionen wie oben eingesetzt werden, noch ein weiterer Key angezeigt, den ihr auch in die Zone eintragen müsst, weil jede angefragte Domain eine eigene Challenge/Validierung benötigt. Und ja, es ist im DNS möglich, dass es zu einer Domäne mehrere Ressource Records gibt. Das Ganze kann dann z.B. in der Zone so aussehen:

LESETIPP  In eigener Sache: DSGVO

Ist die Zone geupdatet und ihr habt euch über das Zone-Update vergewissert, kann dann nochmals mit Enter bestätigt werden, sodass die Domains validiert werden. Nach Erledigung sind die Certs wie immer unter /etc/letsencrypt/live/ verfügbar. Die TXT-Records werden bis zur renewal nicht mehr benötigt.

7 Gedanken zu „Let’s Encrypt Wildcard-Zertifikate erstellen“

  1. Ich habe eine grundsätzliche Verständnisfrage. Was heißt hier DNS Txt Records. Ich betreibe im konkreten Fall, für den es mir noch nicht gelungen ist, überhaupt Zertifikate zu erhalten, keinen DNS-Server und verwalte somit auch keine Zoneneinträge. Bei mir ist die Fritzbox 7490 für die interne Namensauflösung zuständig und externe Adressanfragen werden entsprechend geforwardet. Meine Domains werden essentiell von der Telekom gehostet.
    Das ganze Projekt LE und CERTBOT ist mir diesbezüglich noch nicht klar, obwohl ich seit Jahren via CERTBOT eine meiner Domains mit Zertifikaten versorgen konnte und in dem Fall für die Updates noch nie ein Problem auftrat. Für meine zweite Domain ist es mir bisher noch nicht gelungen, überhaupt Zertifikate zu erhalten – trotz Beseitigung der AAAA-Records auf den TelekomNameservern. Nachforschungen im Netz ergeben eine Menge Artikel, die noch nicht zur Lösung meines Problems geführt haben. Deshalb hier einmal die grundsätzliche Verständnisfrage. Muss ich einen eigenen DNS betreiben, damit das Ganze überhaupt funktioniert? Bei meiner ersten Domain habe ich einen DNS und DHCP aufgesetzt und wie gesagt, dort läuft das. Bei meiner zweiten Domain nicht.

    1. Grundsätzlich: damit du über Let’s Encrypt ein Zertifikat erhalten kannst, ist es notwendig, dass der entsprechende Host verifizierbar ist. Denn Zertifikate sagen vereinfacht gesagt aus “der mit dem du verbunden bist, ist der, der es sein sollte” und das “bezeugt” die Zertifizierungsstelle, hier Let’s Encrypt.
      Wenn du certbot benutzt, gibst du ja die Domain (z.B. test.vgapps.de) an, für die du ein Cert haben willst und wählst eine Verifizierungsmethode aus. Eine gängige ist z.B. Webroot. Da legt certbot auf dem Webserver der Maschine, von dem das Zertifikat angefordert wird, eine Datei (z.B. challenge.txt) an, und schickt eine Anforderung an das LE-System bzw. deren Datacenter. Das überprüft, ob diese Datei von außen auch abrufbar ist. (z.B. test.vgapps.de/challenge.txt) Ist das möglich, ist mit sehr hoher Wahrscheinlichkeit das anfordernde System auch das, was für die Domain zuständig ist, somit autorisiert und das Zertifikat wird für die Domain ausgestellt. Bei diesem Fall ist wichtig, dass die Domain unbedingt auf die IP-Adresse des anfordernden Rechners zeigt. Wie deine FritzBox für die Namensauflösung eingestellt ist, spielt in dem Moment keine Rolle – Let’s Encrypt muss über das Internet darauf zugreifen können.
      Die DNS Challenge geht mit der Art der Verifikation etwas anders vor. Hierzu muss ich etwas weiter ausholen. Wenn du eine Domain von deinem Registrar (z.B. die Deutsche Telekom) registrieren lässt, sendet dieser an die Domain Name Registry (für .de wäre das die DENIC eG), wem die Domain gehört und vor allem welcher DNS-Server für diese zuständig ist. Wenn du nicht mit irgendwelchen Spezialsystem bzw. Domain Robot arbeitest, bei denen du bei Domains vom Handle über die Nameserver bis zu KK-Aufträgen nahezu alles selber bestimmen kannst, übernimmt dein Registrar auch meist die Bereitstellung der DNS-Server. (es ist zudem relativ aufwendig, eigene DNS-Server im Internet bereitzustellen, da von den Domain Name Registries eine gewisse Redundanz erwartet wird) Sprich: wenn du die Domains bei der Telekom bestellt hast, wird sie meist auch eine Administrationskonsole hierfür anbieten. In der Konsole kannst du dann die Informationen, welche IPv4- (A-Record) oder IPv6-Adresse (AAAA-Record) zu einer Domain gehört, einstellen oder auch einsehbare frei wählbare Zusatztexte für Domains definieren, die TXT-Records. Das macht sich LE zu Nutze. Es stellt bei der Zertifikatsanforderung einen Code bereit, der als TXT-Record angelegt werden muss und dann überprüft wird. Und da nur i.d.R. der Domaininhaber bzw. eine von ihm autorisierte Person Zugriff auf die Konsole hat und den TXT-Record hinterlegen kann, gilt das als “verifziert” und das Zertifikat kann ausgestellt werden.
      Besonders ist wie gesagt, dass für Wildcard-Certs nicht das wesentlich einfachere Webroot-Verfahren zur Verfügung steht, was aber auch logisch ist, weil dieses Verfahren ja nur eine bestimmte Domain und nicht alle darunterliegenden verifizieren kann.

Schreibe einen Kommentar