NGINX führt native Unterstützung für das ACME-Protokoll ein

• NGINX hat eine Preview-Version veröffentlicht, die das ACME-Protokoll nativ unterstützt und damit die Ausstellung und Erneuerung von SSL/TLS-Zertifikaten automatisiert
• Über das neue Rust-basierte Modul ngx_http_acme_module können Zertifikate direkt über die NGINX-Konfiguration angefordert, installiert und erneuert werden, ganz ohne externe Tools
• Dadurch sinkt die Abhängigkeit von externen Tools wie Certbot, während Sicherheit und Plattformunabhängigkeit steigen
• Die erste Version unterstützt die HTTP-01-Challenge; Unterstützung für TLS-ALPN und DNS-01 ist für später geplant
• Die ACME-Unterstützung dürfte nicht nur im Web, sondern auch für die Sicherheitsautomatisierung in IoT- und Edge-Computing-Umgebungen eine wichtige Rolle spielen

---

Überblick und wichtigste Änderungen

• NGINX hat eine Preview-Version der ACME-Protokollunterstützung veröffentlicht
• Mit dem neuen Modul ngx_http_acme_module ist es so konzipiert, dass Zertifikatsanforderung, Installation und Erneuerung direkt in der NGINX-Konfiguration verarbeitet werden können
• Diese ACME-Unterstützung nutzt intern das NGINX-Rust SDK und wird als Rust-basiertes dynamisches Modul bereitgestellt
• Sowohl Open-Source-Nutzer als auch Unternehmenskunden von NGINX Plus können diese Funktion verwenden
• Durch die geringere Abhängigkeit von externen Tools wie Certbot steigen Sicherheit und Effizienz des Zertifikatsmanagements

Einführung in das ACME-Protokoll

• Das ACME(Automated Certificate Management Environment)-Protokoll ist ein Kommunikationsprotokoll zur Automatisierung von Ausstellung, Verifizierung, Erneuerung und Widerruf von SSL/TLS-Zertifikaten
• Clients können den Zertifikatslebenszyklus durch automatisierte Kommunikation mit einer CA(Certificate Authority) direkt verwalten, ohne manuelle Zwischenschritte
• Es wurde 2015 von der Internet Security Research Group(ISRG) im Rahmen des Projekts Let’s Encrypt entwickelt und veröffentlicht
• Vor dem Aufkommen von ACME war der Prozess der Zertifikatsausstellung manuell und mit höheren Kosten sowie größerer Fehleranfälligkeit verbunden
• Das aktuelle ACMEv2 erweitert den Funktionsumfang unter anderem um Authentifizierungsmethoden und Wildcard-Unterstützung und erhöht damit Flexibilität und Sicherheit

Ablauf der ACME-basierten Zertifikatsautomatisierung in NGINX

• Die Automatisierung des Zertifikatslebenszyklus mit dem ACME-Protokoll in NGINX erfolgt in den folgenden vier Schritten

• 1. ACME-Server konfigurieren

  • Zur Aktivierung der ACME-Funktion muss mit acme_issuer zwingend die Directory-URL des ACME-Servers angegeben werden
  • Bei der Zertifikatsausstellung können optional auch Kontaktinformationen des Clients, Speicherpfade für Statusdaten und weitere Angaben definiert werden

• 2. Gemeinsamen Speicher (Zone) zuweisen

  • Mit acme_shared_zone kann zusätzlich eine Shared-Memory-Zone für die Speicherung von Zertifikaten, privaten Schlüsseln und Challenge-Daten konfiguriert werden
  • Die Standardgröße beträgt 256K und kann bei Bedarf erweitert werden

• 3. Challenge konfigurieren

  • Die aktuelle Preview-Version unterstützt nur die HTTP-01-Challenge, die zur Verifizierung des Domain-Besitzes dient
  • Dafür müssen in der NGINX-Konfiguration ein Listener auf Port 80 sowie eine Standard-404-Antwort definiert werden
  • Unterstützung für TLS-ALPN- und DNS-01-Challenges ist für die Zukunft geplant

• 4. Zertifikate ausstellen und erneuern

  • Wird die Direktive acme_certificate zum Server-Block hinzugefügt, kann die Ausstellung/Erneuerung von TLS-Zertifikaten für die jeweilige Domain automatisiert werden
  • Die Ziel-Domain für die Zertifikatsausstellung wird in der Regel mit server_name angegeben
  • Reguläre Ausdrücke und Wildcards in server_name werden in der Preview-Version nicht unterstützt
  • Über die Modulvariablen $acme_certificate und $acme_certificate_key werden Zertifikat und Schlüssel automatisch verknüpft

Wichtigste Vorteile

• Das ACME-Protokoll steht im Zentrum des weltweiten starken Wachstums von HTTPS
• Durch automatisiertes Zertifikatsmanagement sinken Kosten für das Zertifikatslebenszyklus-Management und Fehler durch manuelle Arbeit deutlich
• Der Verzicht auf externe Tools reduziert die Angriffsfläche und verbessert die Portabilität
• Fördert die Standardisierung von Sicherheit in unterschiedlichsten Umgebungen

Ausblick

• Unterstützung für TLS-ALPN- und DNS-01-Challenges ist geplant
• Funktionsausbau auf Basis von Nutzerfeedback
• Mit der breiteren Einführung von IoT, API und Edge Computing dürfte ACME künftig eine Schlüsselrolle in einem noch größeren Spektrum automatisierter Sicherheitsinfrastrukturen übernehmen
• Die native ACME-Unterstützung von NGINX dürfte als Grundlage dafür dienen, Websicherheit, Automatisierung und Skalierbarkeit zum künftigen Standard zu machen

Erste Schritte

• Open-Source-Nutzer können vorgefertigte Module über die NGINX Linux packages verwenden
• Unternehmenskunden von NGINX Plus erhalten die Funktion als von F5 unterstütztes dynamisches Modul
• Die Moduldokumentation findet sich in den NGINX Docs

[GN⁺]

Hacker-News-Kommentare

• In der aktuellen Preview-Version wird nur die HTTP-01-Challenge unterstützt, um den Besitz der Client-Domain zu verifizieren.
  DNS-01 wäre für nginx-Nutzer, die nicht öffentlich erreichbar sind, eine deutlich sinnvollere Funktion (z. B. bei Nutzung von Nginx Proxy Manager). DNS-01 aktualisiert einfach nur Records, deshalb fand ich das immer die sauberste Lösung. Ich warte wirklich darauf, dass diese Funktion kommt.
  • Dafür muss man aber zwingend einen DNS-API-Key besitzen, und viele DNS-Anbieter stellen keine separaten API-Keys pro Zone bereit. Ich mag DNS-01 persönlich, aber realistisch gesehen braucht man vielleicht einen unbefriedigenden Kompromiss.
  • Kein Grund zu warten: Angie unterstützt das ebenfalls (Angie ist ein nginx-Fork, den ehemalige nginx-Entwickler nach ihrem Weggang von F5 erstellt haben).
  • Mein Problem mit ACME in Traefik ist, dass man pro DNS-Anbieter nur einen API-Key verwenden kann. Dadurch gibt es viele Einschränkungen, wenn man API-Keys pro Domain begrenzen will oder Domains aus mehreren Accounts nutzt. Ich hoffe, dass nginx ohne diese Einschränkung kommt.
  • Ich nutze in meinem Homelab DNS-01 mit step-ca und Caddy. Die Erfahrung ist sehr zufriedenstellend.
  • Da DNS-01 sehr gut unterstützt wird, kann ich auch einen Wechsel zu Angie empfehlen.
• Das ist eine ziemlich große Änderung. Caddy unterstützt das schon lange, aber nicht jeder bevorzugt Caddy. Dieses Upgrade könnte Software wie Traefik Marktanteile abnehmen.
  • Ich mag besonders die saubere Syntax von Caddy. Ich nutze aktuell nginx (über nginx proxy manager) und Traefik, habe in letzter Zeit aber Projekte mit Caddy gemacht, und das war sehr angenehm. Wenn ich Zeit habe, würde ich meine Self-Hosted-Umgebung gern auf Caddy umstellen. Oder ich nutze etwas wie pangolin. Pangolin bietet sogar eine Alternative zu Cloudflare Tunnels.
  • Ich bin kürzlich komplett zu Caddy gewechselt. Ausschlaggebend war die zurückhaltende Reaktion von nginx auf das HTTP/1-Desync-Problem. Ich mag es nicht, auf einen Vorfall warten zu müssen oder keine klare Antwort von nginx zu bekommen, wenn Auditoren nachfragen.
    Caddy ist definitiv einfacher als nginx. Es bietet Templates für verschiedenste Services, Tests und Sonderdienste für Bildungseinrichtungen, besseres Logging, für mich perfekte Zertifikatsverwaltung und bessere Metriken.
    Allerdings arbeite ich mich noch in die Plugins ein; Caddy hat kein Rate Limiting, und wegen eines Bugs in Power BI fordert ein bestimmter Nutzer Bilder 300.000-mal pro Tag an, was unpraktisch ist.
  • Das denke ich auch. Ich nutze zu Hause teilweise Traefik, aber ich werde es jetzt wohl direkt ersetzen.
• Das ist eine willkommene Änderung. Dokku (ich bin Maintainer) verwendet mit dem letsencrypt-Plugin aktuell eine Behelfslösung, und Nutzer stoßen oft auf zufällige Probleme. Es kommt auch vor, dass nginx während eines Reloads gelegentlich "hängen bleibt" und den Endpoint nicht finden kann. Je weniger solcher komplexen Variablen, desto besser.
  Allerdings wird es noch eine ganze Weile dauern, bis diese Funktion in den Stable-Repositories von Ubuntu oder Debian landet.
  Außerdem werden DNS-Challenges (Wildcard-Zertifikate) noch nicht unterstützt, daher hilft das Dokku kurzfristig vermutlich nicht besonders.
  • Hallo! Schön, dich hier zu sehen.
    Ich habe Dokku ausprobiert (und versuche es immer noch), aber die Einstiegshürde wirkte ziemlich hoch.
    Coolify konnte zum Beispiel nach dem Erstellen einer GitHub-App sofort Deployments integrieren, und ich habe auch Erfahrung damit, Container per GH Actions zu bauen und auszurollen.
    Die offizielle Dokku-Dokumentation fühlt sich eher wie ein Nachschlagewerk an, fast wie das Lesen einer Enzyklopädie: offizielle Dokku-Doku zur Git-Initialisierung
    Ich finde eine direkte, sofort hilfreiche Einführung wie bei Coolify nützlicher: Hilfe zur GitHub-Integration bei Coolify
    Ich fände es gut, wenn es für Dokku ein Tutorial zur Installation populärer OSS-Apps gäbe, einen Einstiegsleitfaden mit schrittweisen Zielen und Erfolgen und ein Tutorial, das in einer Bare-Metal-Umgebung Reverse Proxy und mehrere populäre Apps zusammen behandelt.
    Letztlich nutzt man Dokku nicht um Dokku willen, sondern um mit Dokku schnell und einfach den "gewünschten Zustand" zu erreichen.
    Am Ende wünsche ich mir einen reibungslosen Prozess, bei dem ich einfach auf ein passendes Repository klicke und es sofort auf meiner Maschine deployt wird. Danach würde ich gern in die Details des Unterbaus eintauchen.
• Gute Nachricht. Für alle, die es nicht kennen: Es gab bereits eine einfache Lösung namens dehydrated. Man musste nur ein paar Zeilen zur vhost-Konfiguration hinzufügen:

    location ^~ /.well-known/acme-challenge/ {  
      alias ;  
    }  
  

  dehydrated ist seit Langem ein leichtgewichtiges Tool zur Automatisierung von HTTP-01-Erneuerungen.
  • Die Funktion selbst ist wirklich großartig, aber es ist schade, wenn ein Projekt, von dem Tausende abhängen, weiterhin keine Stable-Releases veröffentlicht.
    Bei Software ohne offizielles Release v1.0.0 kann sich die Schnittstelle jederzeit ohne Vorwarnung ändern. Major-Version 0 wird irgendwann zur Falle.
    Ich würde empfehlen, die Maintainer zu stabilen Releases zu drängen.
    dehydrated ist seit 7 Jahren noch auf Major-Version 0.
    0ver.org ist ebenfalls einen Blick wert:
    Dahinter steht eine Versionierungsphilosophie nach dem Motto: "Wenn es in Produktion genutzt wird, sollte es bereits 1.0.0 sein."
    Mehr dazu hier.
• In diesem Release gab es einen kleinen Fehler: ngx_http_acme_module wurde in mehrere Linux-Distributionspakete aufgenommen, aber Debian stable fehlt noch.
  Laut der offiziellen nginx-Paketliste sind oldstable/oldoldstable vorhanden, aber Debian 13 Trixie, das vor 4 Tagen veröffentlicht wurde, fehlt.
  • Wir arbeiten gerade am Upload des Trixie-Pakets. Es sollte noch diese Woche erscheinen. Debian 13 ist erst seit 4 Tagen verfügbar, daher brauchten wir Zeit, um die Infrastruktur für das neue OS einzurichten. (Ich arbeite bei F5.)
  • Ich denke, das ist vermutlich ein Fehler auf Debian-Seite.
• Seit ich Caddy kennengelernt habe, nutze ich nginx nicht mehr. Die Developer Experience ist deutlich besser.
• Das Problem großer Open-Source-Konzerne ist, dass sie grundlegende Innovationen immer zu spät verstehen und umsetzen.
  Was Caddy und Traefik schon vor 5 Jahren gemacht haben, unterstützt nginx jetzt erst.
  Trotzdem ist das natürlich eine gute Veränderung. Jetzt muss man certbot nicht mehr selbst ausführen, was praktischer ist.
  • Tatsächlich unterstützte Caddy automatisches HTTPS von Let's Encrypt schon vor fast 10 Jahren, nämlich 2016, in gewissem Umfang.
    nginx führt diese Funktion also mit fast 9 bis 10 Jahren Verspätung ein.
• Ich persönlich hatte nie das Gefühl, dass es ein Problem wäre, wenn nginx nur Webinhalte ausliefert und certbot die Erneuerung übernimmt.
  Ich fand die Unix-Philosophie, eine Sache gut zu machen und sich mit anderen Tools kombinieren zu lassen, immer besser.
  Ein "Tool", das alles können will, wird zwangsläufig irgendwo Defizite haben.
  • Das Setup mit certbot ist ziemlich umständlich.
    Selbst wenn certbot die automatische Konfiguration versucht, funktioniert das außerhalb der meisten Standardumgebungen nicht besonders gut.
    Wenn nginx alles intern direkt erledigt, wirkt das eher wie die bessere Lösung.
• Ich verstehe das also so, dass man mit dieser Funktion nur ein paar Zeilen zur nginx-Konfigurationsdatei hinzufügen muss und certbot nicht mehr installieren oder betreiben muss.
  Ich frage mich auch, ob damit der Weg frei wird, neben Let's Encrypt auch einfach Alternativen zu nutzen.
• Eine spannende Änderung.
  Caddy ist mit seinen vielen sofort nutzbaren Komfortfunktionen wirklich praktisch.
  Persönlich konnte ich nicht vollständig zu Caddy wechseln, weil ich die Rate-Limiting- und Geo-Module von nginx brauche.