Lua-resty-auto-ssl: Implementierung des reinen Lua ACME-Protokolls

Ich öffne dieses Thema, um die Idee einer reinen Lua ACME-Client-Implementierung zu verfolgen (anstatt sich auf dehydriert zu verlassen). Ich bin mir nicht sicher, ob / wann dies passieren wird, aber ich dachte, es lohnt sich, auf ein Problem zu verweisen und es zu diskutieren.

Diese Idee ist seit der ersten Erstellung von lua-resty-auto-ssl im Umlauf, wie der TODO-Abschnitt der README von Anfang an feststellte:

Wir setzen derzeit auf dehydrated als unseren Let's Encrypt-Client. Es wird auf nicht-blockierende Weise über lua-resty-shell und sockproc aufgerufen , es könnte jedoch einfacher sein, diesen Ansatz eines Tages durch einen nativen OpenResty Let's Encrypt-Client zu ersetzen.

Größtenteils hat uns die Verwendung von dehydrated gute Dienste geleistet und es uns ermöglicht, die gesamte zugrunde liegende ACME-Protokollarbeit für die Registrierung von Zertifikaten bei Let's Encrypt zu entlasten. Abgesehen davon erhöht die Abhängigkeit von lua-resty-shell und sockproc aus mehreren Gründen auch die Komplexität von lua-resty-auto-ssl:

• Es erfordert den zusätzlichen lokalen HTTP-Server, der auf Port 8999 läuft, der für die Kommunikation zwischen den Shell-Skripten von dehydrated und lua-resty-auto-ssl verwendet wird.
• Das Ausführen von sockproc im Hintergrund und das Erhalten der richtigen Berechtigungen kann zu einigen funkigen Installations-/Laufzeitproblemen führen. Während die Dinge größtenteils automatisch ablaufen sollten und ich denke, dass dies für die meisten Benutzer funktioniert, können verschiedene Installationen zu Edge-Case-Problemen führen (eine anständige Anzahl von GitHub-Problemen kann wahrscheinlich darauf zurückgeführt werden, aber hier sind ein paar zufällige Beispiele, die verwandt zu sein scheinen: https://github.com/GUI/lua-resty-auto-ssl/issues/121 , https://github.com/GUI/lua-resty-auto-ssl/issues /114 , https://github.com/GUI/lua-resty-auto-ssl/issues/98
• Die Installation von sockproc erfordert einen Build-Prozess mit make und gcc, was bedeutet, dass lua-resty-auto-ssl nur über LuaRocks und nicht über das OPM von OpenResty installiert werden kann: https://github.com/GUI/lua-resty-auto-ssl/ Probleme/45 Auch wenn an LuaRocks nichts auszusetzen ist und OPM eventuell Module unterstützt, die kompiliert werden müssen, wäre es schön, OPM-Installationen unterstützen zu können.

Nachdem das ACME v2-Protokoll nun fertig gestellt ist, beschäftigte ich mich zunehmend mit dieser Idee. Einerseits erfordert die Erstellung einer reinen Lua ACME-Client-Implementierung eine anständige Menge an neuer Arbeit, aber die Aussicht, die Abhängigkeit von sockproc ablegen zu können, ist ansprechend (nicht, dass mit sockproc etwas nicht stimmt, aber es verkompliziert nur unser Setup /Installation und Architektur).

Wenn wir diesen Weg gehen wollten, war meine allgemeine Idee die Schaffung von 1 oder 2 neuen Lua-Bibliotheken:

• OpenSSL-Bindungen: Wir brauchen eine Möglichkeit, neue Zertifikate direkt in Lua zu erstellen und die OpenSSL-Dinge auf niedrigerer Ebene zu erledigen (die dehydriert derzeit mit den openssl-Befehlszeilentools). luaossl könnte verwendet werden, obwohl es sich um ein C-basiertes Modul handelt, das heißt, es kann derzeit nur über LuaRocks installiert werden (also kein OPM). Ich habe vor kurzem mit einem lua-openssl-ffi- Modul
• ACME-Client: Meine Idee war, eine neue lua-resty-acme Bibliothek zu erstellen, die die OpenSSL-Bibliothek und lua-resty-http verwendet, um das ACME v2-Protokoll tatsächlich zu implementieren. lua-resty-auto-ssl würde immer noch als Bibliothek auf höherer Ebene existieren, die lua-resty-acme verwendet (lua-resty-acme würde nur das Protokoll implementieren und eine ähnliche Rolle spielen wie dehydriert, während lua-resty-auto-ssl würde immer noch die gesamte nginx-Integration, die SNI-basierte Registrierung, die Zertifikatsspeicherung usw. durchführen).

Auch hier bin ich mir nicht sicher, ob/wann dies passieren wird, aber ich wollte zumindest einige dieser Ideen endlich in einem konkreteren Format veröffentlichen.