Lua-resty-auto-ssl: Wildcard-Zertifikate

Ich bin kein Repo-Betreuer, aber ich muss sagen, dass dies nicht einfach hinzuzufügen ist. LE-Wildcard-Zertifikate erfordern eine DNS-Validierung, und im Moment verwendet lua-resty-auto-ssl die HTTP-Validierung.

DNS-Validierung wäre schön zu haben, auch wenn Wildcards nicht berücksichtigt werden. Ein paar Gedanken:

• Wir müssen warten, bis dehydrated zuerst ACMEv2-Unterstützung erhält: dehydrated#420
• dehydrated unterstützt bereits die (ACMEv1) dns-01 Challenge . Die dns-01-Herausforderung im aktuellen ACMEv2-Entwurf sieht für mich identisch oder fast identisch aus.
• Der Hook deploy_challenge von dehydrated stellt eine Domain und einen Token bereit, die in einen TXT-Eintrag geschrieben werden.
• Da wir nicht wissen, wie Benutzer ihre DNS-Einträge verwalten, muss dieser Teil generisch sein.
  
  
  
  1. Unterstützung gängiger DNS-APIs. Wir sollten zumindest Infrastruktur hinzufügen, um "Standard"-APIs wie die von PowerDNS, CloudFlare oder sogar nsupdate bereitgestellte zu unterstützen. In diesem Fall wird in unseren Einstellungen nur eine Art Authentifizierungstoken benötigt.
  
  
  2. Must-Benutzer benötigen eine benutzerdefinierte Lösung, um diese Rekorde festzulegen, z. B. die Kommunikation mit einer proprietären API oder sogar das Aufrufen von Dirty-Shell-Skripten. Für diese Fälle sollten wir einen generischen Hook bereitstellen:
     
     -- Define a function to store the validation tokens for DNS verification -- by let's encrypt in your DNS setup. auto_ssl:set("deploy_dns_challenge", function(domain, token) -- talk to your DNS-API to create a new TXT record _acme-challenge.$domain with value $token end)
  
  
• Die Speicherschicht geht derzeit davon aus, dass sie die vollständige Domäne als Schlüssel zum Abrufen des Zertifikats verwenden kann. Dies wird nicht mehr gelten. Meine erste Idee ist, Platzhalter als parentdomain.com:wildcard:latest zu speichern und die Speicherschicht diesen Schlüssel überprüfen zu lassen, wenn kein konkretes Zertifikat gefunden wird.

Fragen:

1. Woher wissen wir, ob wir ein normales oder ein Wildcard-Zertifikat generieren sollen? eine neue benutzerdefinierte Funktion is_wildcard_domain ? Ein neuer Rückgabewert für das vorhandene allow_domain ?
2. Unterstützen wir die DNS- (für Wildcards) und HTTP-Validierung (für normale Zertifikate) gleichzeitig oder nur DNS für beide? Beachten Sie, dass HTTP möglicherweise viel schneller ist, da wir alle beweglichen Teile kontrollieren.

Zu Ihrer Information: Es ist jetzt ein ACMEv2-Staging-Endpunkt verfügbar. :)

Die dns-01-Herausforderung im aktuellen ACMEv2-Entwurf sieht für mich identisch oder fast identisch aus.

Sie haben recht :-) An der DNS-01-Challenge hat sich zwischen der V1- und der V2-API nichts geändert.

FYI: zumindest die Entwicklungsversion von dehydrated unterstützt jetzt ACMEv2 sowie Wildcard-Zertifikate. Falls jemand anfangen möchte, daran zu arbeiten, ist jetzt Ihre Chance ;)

Ich denke, resty-auto-ssl, das die DNS-Validierung durchführt, ist völlig außerhalb des Geltungsbereichs.
Es sollte uns jedoch möglich sein, resty-auto-ssl auf ein "out of band" konfiguriertes Wildcard-Zertifikat zurückfallen zu lassen.
Zum Beispiel werde ich meinen Dienst mit bind9 und certbot einrichten, um ein Wildcard-Zertifikat für eine Domain zu erstellen. Im Moment glaube ich nicht, dass ich resty-auto-ssl anweisen kann, dieses Wildcard-Zertifikat zu verwenden, anstatt zu versuchen, eines zu generieren.

EDIT: Nun, es ist nicht so außerhalb des Geltungsbereichs. Ich wusste nicht, dass Dehydrated mit manuellen Skripten konfiguriert werden kann, um sich in eine benutzerdefinierte DNS-API einzuklinken ...

Gibt es eine Möglichkeit, ein manuell generiertes Platzhalter-LE-Zertifikat in Redis zu speichern, damit resty-auto-ssl es verwenden kann?

Soweit ich den Code verstehe, ist dies nicht möglich. Wir könnten jedoch leicht die folgenden Überprüfungen in der Speicherschnittstelle für jedes sub.domain.tld hinzufügen:

• sub.domain.tld:latest — aktuell
• *.domain.tld:latest
• *.sub.domain.tld:latest

Auf diese Weise könnten wir einen ersten Schritt in Richtung Wildcards machen, die vorerst nur zuvor generierte Zertifikate unterstützen. Danach könnten wir weitermachen und uns für eine nette Möglichkeit entscheiden, die Generierung von Wildcard-Zertifikaten zu unterstützen, wenn wir uns dazu entschließen.

Bearbeiten: Ich würde gerne eine Implementierung des oben Gesagten kratzen.

@akalipetis hast du versucht zu sehen, ob die Einstellung

ssl_options.fullchain_der
ssl_options.privkey_der

würde in allow_domain funktionieren?
Wenn es möglich ist, können Sie in allow_domain eine Redis-Anfrage stellen und diese festlegen.

Um festzuhalten, dass ich gerade auf dieses Problem gestoßen bin, ich verwende lua-resty-auto-ssl , um Zertifikate für benutzerdefinierte Domänenstatusseiten in meinem Überwachungsdienst zu generieren, und die meisten Leute würden meine eigenen Domänen wie xxxx.status.updown.io verwenden, für die es viel effizienter ist um ein Wildcard-Zertifikat zu verwenden.

Ich habe dies erreicht, indem ich das Lambda allow_domain verwendet habe, um die Zertifikatsgenerierung für *status.updown.io zu überspringen:

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

Und dann den Platzhalter als Standard-Fallback-Zertifikat bereitgestellt:

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

Ich habe das Zertifikat manuell mit der DNS-Herausforderung generiert mit:

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

Ich bin mir nicht sicher, ob es sich lohnt, meine Zeit damit zu verbringen, dies zu automatisieren, da es mit der DNS-Herausforderung kompliziert aussieht. Es ist Low-Tech, aber es funktioniert wie erwartet :)

Das ist eine nette Problemumgehung, die für viele Anwendungsfälle gilt.
Beachten Sie jedoch, dass die DNS-Herausforderung mit https://github.com/AnalogJ/lexicon sehr einfach gemacht wurde!
Es funktioniert gut und unterstützt viele Anbieter. Ich habe sogar einen von ihnen hinzugefügt und der Prozess ist lächerlich einfach.

@kapouer danke für den Tipp zu lexicon , werde es mir merken wenn ich automatisieren will ;)

Um festzuhalten, dass ich gerade auf dieses Problem gestoßen bin, ich verwende lua-resty-auto-ssl , um Zertifikate für benutzerdefinierte Domänenstatusseiten in meinem Überwachungsdienst zu generieren, und die meisten Leute würden meine eigenen Domänen wie xxxx.status.updown.io verwenden, für die es viel effizienter ist um ein Wildcard-Zertifikat zu verwenden.

Ich habe dies erreicht, indem ich das Lambda allow_domain verwendet habe, um die Zertifikatsgenerierung für *status.updown.io zu überspringen:

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

Und dann den Platzhalter als Standard-Fallback-Zertifikat bereitgestellt:

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

Ich habe das Zertifikat manuell mit der DNS-Herausforderung generiert mit:

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

Ich bin mir nicht sicher, ob es sich lohnt, meine Zeit damit zu verbringen, dies zu automatisieren, da es mit der DNS-Herausforderung kompliziert aussieht. Es ist Low-Tech, aber es funktioniert wie erwartet :)

Ich mache auch die gleiche Art von Domain-Check für unsere App. Wenn der Portalhost des Benutzers eine unserer "eigenen" Domänen enthält, greifen wir einfach auf die Verwendung von Wildcard-Zertifikaten von einer statischen Zertifizierungsstelle zurück. Aber ich mag Ihre Idee, immer noch LE zu verwenden und die Platzhalter manuell zu generieren.

Ich werde das testen.

Aktualisieren
Okay, das ist die Lösung, die wirklich das tut, was ich will. Das Cloudflare-Plugin. Die Dokumente sind ziemlich gut. Ich hatte es innerhalb von ein oder zwei Stunden zum Laufen gebracht.

https://certbot-dns-cloudflare.readthedocs.io/en/stable/

@jarthod eine andere Problemumgehung, um dies zu automatisieren? Sich daran zu erinnern, die Wildcard alle 3 Monate zu erneuern, ist wirklich schmerzhaft.

@jarthod eine andere Problemumgehung, um dies zu automatisieren? Sich daran zu erinnern, die Wildcard alle 3 Monate zu erneuern, ist wirklich schmerzhaft.

Nicht auf meiner Seite, ich benutze das immer noch und mache die manuelle Erneuerung alle 3 Monate. Das Erinnern ist für mich kein Problem, da ich meinen Dienst (updown.io) verwende, um den Endpunkt zu überwachen, und mich benachrichtigt, wenn das Zertifikat bald abläuft.

Ich bin auch Benutzer Ihres Dienstes. Wie auch immer, ich habe weitergemacht und traditionelles 1-Jahres-Wildcard-SSL bekommen.

Jetzt hat dein Service die Aufgabe, mich nächstes Jahr daran zu erinnern 😄

Am 03.10.2020 um 22:30 Uhr schrieb Adrien Rey-Jarthon [email protected] :

,
@jarthod eine andere Problemumgehung, um dies zu automatisieren? Sich daran zu erinnern, die Wildcard alle 3 Monate zu erneuern, ist wirklich schmerzhaft.

Nicht auf meiner Seite, ich benutze das immer noch und mache die manuelle Erneuerung alle 3 Monate. Das Erinnern ist für mich kein Problem, da ich meinen Dienst (updown.io) verwende, um den Endpunkt zu überwachen, und mich benachrichtigt, wenn das Zertifikat bald abläuft.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder kündigen Sie sie.