Caddy Webserver im ZeroSSL Umfeld HTTPS, Reverse Proxy und PKI als Module mit API

Caddy verbindet HTTP-Server, Reverse Proxy und Zertifikatsmanagement in einer modularen Laufzeit. Go als Basis, statische Binaries und ein Admin-API-Ansatz reduzieren Abhängigkeiten und vereinfachen Deployments. Automatische TLS-Zertifikate und erneuerte OCSP-Staples gehören zum Standard.

Caddy fungiert als Go-basiertes Konfigurations- und Laufzeitsystem für mehrere Serverrollen. Das Design organisiert Funktionen als Apps und Config-Module. HTTP, TLS, PKI, Events sowie Raw TCP und UDP, SSH, PHP und weitere Komponenten laufen innerhalb eines Prozesses, sofern das jeweilige Modul aktiv ist. Erweiterungen werden als Plugins zur Compile-Zeit eingebunden, was bei Deployments keine zusätzlichen Laufzeitabhängigkeiten erzeugt und Inkompatibilitäten durch Systembibliotheken vermeidet.

Die Auslieferung erfolgt als plattformnahes statisches Binary ohne externe Laufzeitbibliotheken. Das vereinfacht Updates, weil ein Austausch der Datei reicht. Caddy läuft auf Linux, Windows, macOS sowie BSD-Derivaten und deckt verbreitete CPU-Architekturen von x86 und x86_64 bis ARM64 und RISCV64 ab.

Konfiguration über Caddyfile und JSON

Caddy akzeptiert Konfigurationen als JSON und verarbeitet alternative Formate über Adapter. Das Caddyfile dient als kompakte Textsyntax für typische Deployments und übersetzt intern nach JSON. Adapter unterstützen zusätzlich mehrere Formate, darunter NGINX-Konfigurationen, YAML und HCL, sofern passende Adapter verfügbar sind. Für Automatisierung liefert Caddy ein Admin-API, das Konfigurationszustände exportiert und Laufzeitänderungen ohne Downtime einspielt. Graceful Reloads halten Listener und Verbindungen stabil, sofern die Änderung kompatibel bleibt.

Für den operativen Betrieb spielt die CLI eine zentrale Rolle. Kommandos wie "caddy start", "caddy run", "caddy stop" und "caddy reload" arbeiten eng mit dem Admin-API zusammen. Caddy stellt außerdem Funktionen zur Validierung und Formatierung des Caddyfile bereit, erzeugt Shell-Completion, liefert Build-Metadaten und listet installierte Module. Plugin-Builds gehören zum Betriebsmodell, weil viele Funktionen über zusätzliche Module kommen.

Automatisches HTTPS und Zertifikatsbetrieb

Caddy aktiviert HTTPS standardmäßig und übernimmt das komplette Zertifikats-Lifecycle-Handling. Das System beschafft Zertifikate, erneuert sie und verwaltet Schlüsselmaterial sowie OCSP-Staples. Zertifikatsvorgänge skalieren über mehrere Instanzen, sobald mehrere Caddy-Knoten auf denselben Storage-Backend zugreifen. In diesem Cluster-Modus koordinieren die Instanzen Zertifikatsoperationen, teilen OCSP-Staples und synchronisieren Session-Ticket-Keys. Das reduziert Doppelanfragen bei ACME und verhindert inkonsistente Zustände bei Parallelbetrieb.

Als ACME-Client unterstützt Caddy gängige Challenge-Varianten. HTTP-01 und TLS-ALPN-01 funktionieren ohne DNS-Eingriff. Für CAs mit Pflicht zur External Account Binding lässt sich EAB konfigurieren. Caddy funktioniert nicht nur mit einer einzelnen CA, sondern mit mehreren ACME-kompatiblen Ausstellern, darunter Let’s Encrypt, ZeroSSL, Google Trust Services und weitere RFC-8555-konforme Anbieter.

On-Demand TLS ergänzt das Standardmodell für Szenarien mit vielen Domänen, die erst zur Laufzeit auftauchen. Das System erstellt Zertifikate im TLS-Handshake, sofern die Konfiguration diese Funktion erlaubt. Dieser Modus passt zu SaaS-Setups mit Kundendomänen, erfordert aber strenge Zulassungslogik, damit kein unkontrollierter Zertifikatsabruf erfolgt.

OCSP-Stapling aktiviert Caddy standardmäßig und hält Antworten im Cache, damit Clients auch bei OCSP-Responder-Störungen valide Staple-Daten erhalten. Must-Staple lässt sich nutzen, sofern die CA diese Erweiterung unterstützt. Bei Widerruf erkennt Caddy den Status über OCSP und ersetzt Zertifikate, sobald der Status einen Austausch erfordert.

Interne PKI und lokales TLS

Caddy beschränkt sich nicht auf Web-PKI. Eine integrierte PKI-Funktionalität erzeugt interne CAs und signiert Zertifikate für interne FQDNs, IP-Adressen und localhost. Das passt zu mTLS in Service-Netzen, zu Entwicklungsumgebungen und zu internen Admin-Oberflächen. Eine ACME-Server-Funktion ermöglicht eine interne ACME-Directory-Endpoint-Struktur, sodass andere Caddy-Instanzen oder ACME-Clients Zertifikate aus der internen PKI beziehen. Ein Konfigurationsblock für PKI definiert CAs und benennt sie über "name". Ein Caddyfile-Ausschnitt zeigt das Prinzip ohne Zusatzkomponenten.

{

pki {

ca corporate {

name "Our Corporation Authority"

}

}

}

internal.example.com {

acme_server {

ca corporate

}

}

Reverse Proxy und Transportmodule

Der Reverse Proxy bildet ein Kernmodul und adressiert HTTP-Frontends für interne Services. Caddy trennt Clientseite und Upstream-Transport, wodurch Backends auch über alternative Transports erreichbar sind. Neben HTTP unterstützt Caddy Transportmodule für FastCGI und NTLM. Load Balancing arbeitet mit mehreren Policies, darunter Round Robin, Least Connections und Hash-basierte Varianten über IP, URI, Query, Header oder Cookie. Health Checks existieren als aktiv und passiv.

(ID:50663317)