Certbot: Wie aktiviere ich ACMEv2 und das Abrufen von Wildcard-Zertifikaten?

Sie müssen die DNS-01 Herausforderung verwenden. Das bedeutet, dass Sie eine Möglichkeit haben müssen, die DNS-Zone innerhalb Ihres Servers zu ändern und zu veröffentlichen und zu aktualisieren.

Könnten Sie mir bitte die Flagge dafür sagen?

Es ist nicht nur eine Flagge, sondern alles ist im Dokument verfügbar. Es sind einige Plugins für verschiedene DNS-Anbieter, die dort aufgeführt sind. Wenn Sie dies nicht tun, können Sie hier eine Funktionsanfrage öffnen, um Support dafür zu bitten (es sind bereits einige für Dinge wie Gandi geöffnet, also verwenden Sie unbedingt die Suche, bevor Sie ein öffnen ein neues).

Hm, nein, du brauchst tatsächlich certbot >= 0.22 , sorry, dass ich das in deinem ersten Beitrag übersehen habe.

OK.... Wie installiere ich das? Muss ich aus dem Quellcode kompilieren?

Sie können entweder warten, bis es im PPA veröffentlicht wird , über pip oder ähnliches installieren oder tatsächlich aus dem Quellcode erstellen.

Wäre ich Sie, würde ich lieber auf die Aktualisierung des offiziellen Pakets warten. Auf diese Weise haben Sie etwas Zeit, die DNS-Herausforderung richtig einzurichten, die Sie bereits ohne Wildcard ausprobieren können, um zu überprüfen, ob alles funktioniert, und dann, wenn das Update verfügbar ist (was nicht lange dauern sollte), sind Sie bereit Holen Sie sich Ihr Wildcard-Zertifikat.

Ja, Sie können certbot aus Quellen verwenden

root<strong i="6">@cs12</strong>:~# git clone https://github.com/certbot/certbot
...
root<strong i="7">@cs12</strong>:~# DOMAIN=example.com
root<strong i="8">@cs12</strong>:~# cd certbot 
root<strong i="9">@cs12</strong>:~/certbot# ./certbot-auto certonly --manual -d *.$DOMAIN -d $DOMAIN --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory
...
-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.example.com with the following value:

qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

TXT-Eintrag hinzufügen drücken Sie die Eingabetaste. Sie erhalten einen weiteren Datensatz. Fügen Sie es auch hinzu.

Überprüfen Sie dann im zweiten Terminalfenster, ob Datensätze bereitgestellt wurden:

root<strong i="15">@cs12</strong>:~# host -t txt _acme-challenge.example.com
_acme-challenge.example.com descriptive text "qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI"
_acme-challenge.example.com descriptive text "oMmMa-fDLlebdUhvhMD5MinJ2EeFpdP0F9lUPTShh4w"

Wenn alles in Ordnung ist, gehen Sie zurück und drücken Sie die Eingabetaste

Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2018-06-11. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Update: Sehen Sie sich die vollständige Anleitung zu Gist mit Schritten zum Installieren, Einrichten und Erneuern von Zertifikaten an.

Danke für die ausführliche Antwort @ArchangeGabriel! Wir arbeiten daran, unsere Pakete für Ubuntu zu aktualisieren, hoffentlich werden sie bald veröffentlicht.

@ohemorange Gern geschehen ! Ehrlich gesagt befürchtete ich, dass wir einen Zustrom von Leuten sehen würden, die versuchen, Wildcard-Zertifikate zu erhalten, ohne jedoch zu wissen, was die DNS-01-Herausforderung ist, aber anscheinend ist dies (noch) nicht passiert.

Nett @talyguryn , Als Follow-up zu @talyguryn

Wenn Sie ein Zertifikat auf Apex mit Wildcard erstellen, erhalten Sie __zwei__ Herausforderungen.

Mit -d "example.com, *.example.com" _geben Sie mir ein Zertifikat für den Apex und einen Platzhalter für den Apex_

Du wirst _zweimal_ herausgefordert, einmal für example.com und noch einmal für *.example.com

Denken Sie also nicht, dass es bei der zweiten Herausforderung fehlgeschlagen ist und Sie den Wert ändern müssen. Fügen Sie einfach die zusätzliche Herausforderung zum DNS hinzu. Warten Sie auf die Ausbreitung und fahren Sie fort,

Eventuell sollte die Ausgabe geändert werden, damit man leichter erkennen kann, welche Domain angefochten wird?

Dokumente: https://sinkcup.github.io/letsencrypt-wildcard-certificate

@AubreyHewes , ich habe das gleiche Problem. Ich bin mir nicht sicher, wie man ein einzelnes Zertifikat für example.com und *.example.com ausstellt. Leider erfordert certbot, dass ich den TXT-Eintrag zweimal ändere. Dies führt dazu, dass die Validierung für eine der Domänen fehlschlägt. Gibt es einen Weg, dies zu umgehen?

@nathan-alden Sie müssen beide TXT Datensätze gleichzeitig festlegen. Löschen Sie nicht den ersten, wenn Sie den zweiten hinzufügen.

@nathan-alden
Sie erhalten zwei Herausforderungen.. Dieser _scheint_ certbot möchte, dass Sie denselben TXT erneut ändern. Aber der zweite Wert ist für die zweite Domäne. Fügen Sie also einen neuen TXT-Eintrag für die zweite Domäne hinzu.

dh
Wenn Sie -d "example.com,*.example.com" die erste Herausforderung für example.com also fügen Sie dafür ein TXT hinzu. Fahren Sie nach der Vermehrung fort.
Die zweite Herausforderung ist für *.example.com also füge dafür ein TXT hinzu. Fahren Sie nach der Vermehrung fort.

Ich habe gute Erfahrungen mit der Docker-Version gemacht. Als Randnotiz stellen Sie sicher, dass Sie die TTL für den TXT-Eintrag auf etwa 1 Minute einstellen, damit Sie nicht eine Stunde warten müssen, bis sich der zweite Eintrag verbreitet.

docker run -it --name certbot \
  -v <certs>:/etc/letsencrypt \
  -v <logs>:/var/lib/letsencrypt \
  certbot/certbot certonly --manual \ 
  -d *.<domain.com> -d <domain.com> \
  --agree-tos \
  --manual-public-ip-logging-ok \ 
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory

Wundern. Warum benötigen wir dns-01 . Können Sie nicht einfach einen Server auf Port 80 starten (jede Form von http Herausforderung) und prüfen, ob ich die Wildcard-Domain besitze, indem Sie N zufällige Subdomains generieren und eine Verbindung herstellen?

@AubreyHewes , ich habe herausgefunden, dass Sie nur eine Herausforderung/einen

Ich habe ein Zertifikat für vier Domänen und ihre Platzhalter. Jede Domain hat nur eine TXT _acme-challenge. Es ist ziemlich inkonsistent, da drei Domänen mit der ersten Herausforderung in der certbot-Ausgabe arbeiten und die Werte bei jeder Ausführung gleich zu sein scheinen.

Die vierte Domäne funktioniert nicht mit dem ersten Datensatz in der Ausgabe, sondern mit dem zweiten und dieser scheint sich jedes Mal zu ändern, wenn ich den certbot ausführe.

Ich verwende diesen Befehl:

/usr/bin/certbot --renew-by-default certonly --manual --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges dns-01 -w /usr/share/nginx/letsencrypt-root/ -d *.domain1.sk -d domain1.sk -d *.domain2.sk -d domain2.sk -d *.domain3.sk -d domain3.sk -d *.domain4.sk -d domain4.sk

Ich habe dies durch Versuch und Irrtum gemacht - ich wusste nur nicht, dass Sie zwei gleiche DNS-Einträge mit unterschiedlichen Werten haben können :-) Das nächste Mal werde ich das versuchen.

@robertvalik Es ist nicht möglich, denselben TXT Datensatzwert für zwei verschiedene Validierungen zu verwenden, einschließlich example.com und *.example.com .

Let's Encrypt ermöglicht die Wiederverwendung einer Autorisierung für eine Weile, derzeit 30 Tage. Wenn Ihr Konto kürzlich etwas validiert hat, kann es ohne erneute Validierung weitere Zertifikate ausstellen. Aufgrund von Certbot-Einschränkungen (#5342) fordert Certbot Sie jedoch auf, denselben TXT Datensatz erneut zu setzen, auch wenn er nicht erneut überprüft wird.

Es muss also passiert sein, dass für einen der Namen bereits eine gültige Berechtigung vorhanden war, sodass die Tatsache, dass der erforderliche DNS-Eintrag nicht mehr existierte, keine Rolle mehr spielte.

@francoism90 Man könnte aus mehreren Gründen eine Wildcard-Domain wünschen, eine könnte wenige statische Subdomains bedienen, andere potenziell unendliche Subdomains (z. B. Software as a Service). Im letzteren Fall (meinem Fall) hat man bereits einen Platzhalter in der DNS-Datei, und eigentlich sollte jede zufällige Unterdomäne richtig aufgelöst werden. Ich frage mich, ob für dieses Szenario eine Form der http-Herausforderung bereitgestellt werden könnte. Danke für all Ihre Mühe!

Ich hatte einen Erfolg, ein Zertifikat zu generieren, indem ich es ausstellte

./certbot-auto certonly --manual -d *.example.com -d example.com --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Jetzt frage ich mich nur, wie ich die Zertifikate erneuern kann

<> certbot renew
<> certbot-renew
<> certbot-auto renew

Ich bin verwirrt, ich habe ./certbot-auto renew versucht, da ich beim Anfordern denselben Befehl verwendet habe, aber ich möchte nur sicherstellen, dass es der richtige Weg ist.

Können wir die Wildcard-Zertifizierung automatisieren?

@ufo911 Natürlich. Verwenden Sie beispielsweise das RFC 2136-Plugin von Certbot:

certbot certonly \
  --dns-rfc2136 \
  --dns-rfc2136-credentials ~/.secrets/certbot/rfc2136.ini \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

Oder den manuellen Auth-Hook von acme-dns :

certbot certonly \
  --debug-challenges \
  --manual \
  --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

https://certbot.eff.org/docs/using.html
https://community.letsencrypt.org/t/getting-wildcard-certificates-with-certbot/56285

Wenn Sie Hilfe benötigen, können Sie ein Thema im Let's Encrypt-Forum veröffentlichen .

@mnordhoff
Ist es notwendig, dass der DNS-TXT-Eintrag bei jeder Verlängerung live ist?

@ufo911 Natürlich ist eine Erneuerung nur eine Zertifikatsanforderung, die die vorherigen Parameter wiederverwendet.

@ArchangeGabriel Stange sagt mir, dass ich neue TXT-Rekorde aufstellen soll:

#!/bin/bash
certbot certonly \
  --manual \
  --agree-tos \
  --manual-public-ip-logging-ok \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d domain.tld \
  -d "*.domain.tld"

Ist das normal? Warum werden neue Token generiert?

Tut mir leid, wenn ich nicht klar war, ja, bei jeder Anfrage gibt es einen neuen TXT-Eintrag. Denn dies ist eine Challenge-Response-Validierung und die Wiederverwendung der Challenge wäre eine sehr schlechte Idee.

Sie können den TXT-Eintrag also tatsächlich entfernen, sobald Sie das Zertifikat erhalten haben, aber es muss bei jeder Verlängerung ein neuer TXT-Eintrag veröffentlicht (und nach erfolgreichem Entfernen entfernt) werden.

@ArchangeGabriel Hmm , glaube nicht, dass das eine Option für mich ist. Das Erstellen eines neuen TXT-Eintrags kann 24 Stunden in Anspruch nehmen und wenn etwas schief geht, werden Sie viel Ausfallzeit haben.

Ich werde stattdessen den allgemeinen Weg verwenden. :)

Sicher, die DNS-Herausforderung ist nicht die einfachste. Aber für Wildcards gibt es zumindest derzeit keine andere Möglichkeit. Ich weiß nicht, ob dies zum Beispiel durch Senden der Challenge an einen zufälligen Subdomain-Namen im Platzhalterbereich ersetzt werden könnte (z. B. wenn Sie nach *.domain.com fragen, würde es versuchen, die Challenge-Antwort bei somerandomstring.domain.com zu lesen *.domain.com Raum haben). Auf diese Weise würde eine Wildcard-Umleitung im DNS ausreichen.

@ArchangeGabriel Dies wäre eine gute Option, aber wäre in diesem Fall noch eine DNS-Überprüfung erforderlich? Bietet es etwas, das für ein sicheres Wildcard-Setup benötigt wird?

Nein, meine Idee wäre, eine Alternative zur DNS-Herausforderung anzubieten.

Für ein Wildcard-Setup müssen Sie die Kontrolle über alle Subdomains nachweisen. Die einzig naheliegende Möglichkeit besteht darin, den technischen Besitz der entsprechenden DNS-Zone nachzuweisen.

Jetzt frage ich mich, ob es einen anderen Weg geben könnte, der den anderen Herausforderungstypen ähnlicher ist. Die Frage nach einer zufälligen Subdomain würde beweisen, dass Sie die Kontrolle über eine Wildcard-Umleitung haben. Ich weiß nicht, ob das für die IETF ausreichen würde, ich denke, sie haben darüber nachgedacht und es muss einige Probleme geben.

Ich frage mich zum Beispiel, ob dieser Fall möglich ist:
– somespecificsub.domain.com verweist auf eine bestimmte IP;
– *.domain.com und domain.com zeigen auf eine andere IP.

In diesem Fall können Sie Anfragen für die Hauptdomäne und jede Unterdomäne mit Ausnahme von somespecificsub.domain.com beantworten. Und ich denke, es wäre nicht richtig, Ihnen ein *.domain.com-Zertifikat zu liefern. Wenn das möglich ist, benötigen wir einige zusätzliche Einstellungen. Wie ein permanenter TXT-Eintrag, der angibt, dass er berechtigt ist, eine zufällige Subdomain-Verifizierung für die Wildcard-Challenge-Antwort durchzuführen. Auf diese Weise wäre die DNS-Konfiguration nur ein Fire-and-Forget, und Sie könnten einen Platzhalter einfacher validieren.

Jedenfalls weiß ich nicht, mit wem dies besprochen werden soll und an welcher Stelle sie dieses Setup in Betracht gezogen haben, und auch nicht, was genau die erforderlichen Kriterien sind, um eine Wildcard sicher zu liefern. Ich denke, ich sollte dafür einfach den RFC lesen, aber ich habe keine Zeit dafür.