imported>TechCorner-Redaktion: Verlinkung auf den Artikel OPNsense - ACME-Client für Let's Encrypt-Zertifikate ergänzt

2026-10-08T00:00:00Z

Verlinkung auf den Artikel OPNsense - ACME-Client für Let's Encrypt-Zertifikate ergänzt

Neue Seite

{{Steckbrief
| gilt_fuer = OPNsense 26.1/26.7 mit Plugin os-caddy 2.2 (Caddy 2.10 oder neuer)
| bereich = IT-Security
| dauer = ca. 30 Minuten (Grundeinrichtung und erste Webanwendung), Walkthrough komplett ca. 2 Stunden
| rechte = Administrator (OPNsense-WebUI), Zugriff auf die öffentliche DNS-Zone
| stand = Oktober 2026
}}
'''Caddy''' ist ein moderner Webserver und '''[[Reverse Proxy]]''' mit '''automatischem HTTPS''': Für jede eingetragene Domain besorgt und verlängert Caddy selbstständig ein Zertifikat von [[Let's Encrypt]] oder ZeroSSL. Mit dem Plugin '''os-caddy''' wird die OPNsense so in wenigen Minuten zum sicheren Eingangstor für interne Webanwendungen wie Nextcloud, Grafana, Home-Office-Portale oder die Weboberflächen von Servern – inklusive Zugriffsbeschränkung, Basic Auth, Client-Zertifikaten und Single Sign-On über authentik.

Dieser Artikel stellt das Plugin vor und führt in einem durchgehenden '''Walkthrough''' von der Installation bis zu fortgeschrittenen Szenarien.

== Was ist Caddy und wann ist es die richtige Wahl? ==
* '''Automatisches HTTPS:''' Zertifikate werden ohne zusätzliche Konfiguration ausgestellt und verlängert; HTTP wird automatisch auf HTTPS umgeleitet.
* '''Einfache Oberfläche:''' Domains und ''Handler'' (Weiterleitungen an interne Dienste) statt komplexer Frontend/Backend-Logik.
* '''Moderne Protokolle:''' HTTP/1.1, HTTP/2 und optional HTTP/3 ([[QUIC]]), WebSockets.
* '''Zugriffsschutz pro Domain:''' Access Lists, Basic Auth, mTLS und Forward Auth (authentik, Authelia).
* '''Layer4-Proxy:''' TCP/UDP-Weiterleitung, auch mit Protokollerkennung (SSH, RDP, TLS mit SNI, OpenVPN u. a.).

{| class="wikitable"
! Kriterium !! Caddy (os-caddy) !! HAProxy (os-haproxy) !! OPNWAF (os-OPNWAF)
|-
| Schwerpunkt || Einfacher Reverse Proxy mit Auto-HTTPS || Lastverteilung, sehr fein steuerbar || Reverse Proxy mit Web Application Firewall
|-
| Zertifikate || Automatisch integriert || Über os-acme-client || Integriert
|-
| Einrichtung || Sehr einfach || Komplex || Mittel
|-
| WAF || Nein || Nein || Ja
|-
| Lizenz || Open Source (Community-Plugin) || Open Source || Kommerziell (Business Edition)
|}
Für die meisten Veröffentlichungen interner Webdienste in kleinen und mittleren Umgebungen ist Caddy die bequemste Lösung. Wer eine Web Application Firewall benötigt, greift zu OPNWAF; für komplexe Lastverteilung zu HAProxy (siehe [[OPNsense - HAProxy mit Passwortauthentifizierung]]).

[[Datei:OPNsense-Caddy-Walkthrough.png|thumb|center|750px|Walkthrough-Szenario: Caddy auf der OPNsense nimmt HTTPS-Anfragen für mehrere Domains an, besorgt die Zertifikate automatisch und leitet je nach Domain an Nextcloud, an das per authentik geschützte Grafana oder – nur intern – an die OPNsense-Weboberfläche weiter.]]

== Das Walkthrough-Szenario ==
{| class="wikitable"
! Domain !! Ziel (Upstream) !! Schutz
|-
| <code>cloud.example.com</code> || Nextcloud, <code>http://192.168.10.30:80</code> || öffentlich (Anmeldung in Nextcloud)
|-
| <code>grafana.example.com</code> || Grafana, <code>http://192.168.10.40:3000</code> || nur nach Anmeldung bei '''authentik''' (Forward Auth)
|-
| <code>wiki.example.com</code> || interner Webserver, <code>https://192.168.10.50</code> (selbstsigniert) || nur aus internen Netzen (Access List)
|-
| <code>opn.example.com</code> || OPNsense-Weboberfläche || nur intern, Access List
|}
Öffentliche IPv4-Adresse der Firewall: <code>203.0.113.1</code>.

== Schritt 1: Plugin installieren und OPNsense vorbereiten ==
=== Installation ===
'''System → Firmware → Plugins''': '''os-caddy''' installieren und die Seite neu laden. Das Menü befindet sich anschließend unter '''Services → Caddy''' mit den Punkten ''General Settings'', ''Reverse Proxy'', ''Layer4 Proxy'', ''Diagnostics'' und ''Log File''.

=== Ports 80 und 443 freimachen ===
Caddy benötigt die Ports '''80''' und '''443''' – die OPNsense-Weboberfläche darf sie nicht mehr belegen:
# '''System → Settings → Administration''': '''TCP Port''' auf z. B. <code>8443</code> ändern.
# '''HTTP Redirect – Disable web GUI redirect rule''' aktivieren.
# Speichern und die Weboberfläche künftig über <code><nowiki>https://<firewall>:8443</nowiki></code> aufrufen. Auf dem LAN regelt die Anti-Lockout-Regel den Zugriff automatisch; auf anderen Interfaces eigene Regeln anlegen.

=== DNS-Einträge ===
Für jede Domain einen öffentlichen '''A-Record''' (bei IPv6 zusätzlich '''AAAA''') auf die WAN-Adresse setzen, z. B. <code>cloud.example.com → 203.0.113.1</code>. Alternativ ein Wildcard-Eintrag <code>*.example.com</code> (siehe Schritt 6).

=== Firewall-Regeln ===
Unter '''Firewall → Rules''' auf dem Interface '''WAN''' und ebenso auf '''LAN''' (damit interne Clients die Dienste unter demselben Namen erreichen):
{| class="wikitable"
! Protokoll !! Quelle !! Ziel !! Port !! Zweck
|-
| TCP || any || This Firewall || 80 (HTTP) || ACME-Challenge und Umleitung auf HTTPS
|-
| TCP || any || This Firewall || 443 (HTTPS) || Reverse Proxy
|-
| UDP || any || This Firewall || 443 || nur wenn HTTP/3 (QUIC) aktiviert wird
|}
Eine Portweiterleitung (Destination NAT), NAT Reflection oder Split-DNS ist '''nicht''' nötig: Caddy läuft auf der Firewall selbst, und auch interne Zugriffe auf die öffentliche Adresse bleiben innerhalb der OPNsense. Regeln von der Firewall zu den internen Servern sind ebenfalls nicht nötig.

== Schritt 2: Caddy aktivieren ==
'''Services → Caddy → General Settings''':
* '''Enable Caddy''' aktivieren.
* '''ACME Email''': eine gültige Adresse eintragen – Pflicht für automatische Zertifikate.
* '''Auto HTTPS''': ''On (default)''.
* '''HTTP Versions''': Standard ist HTTP/1.1 und HTTP/2. HTTP/3 nur bei Bedarf ergänzen (dann UDP 443 freigeben).
* '''Apply'''.

== Schritt 3: Erste Anwendung veröffentlichen (Nextcloud) ==
=== Domain anlegen ===
'''Services → Caddy → Reverse Proxy → Domains''' → '''+''':
{| class="wikitable"
! Feld !! Wert
|-
| Protocol || <code>https://</code>
|-
| Domain || <code>cloud.example.com</code>
|-
| Port || leer (443)
|-
| Certificate || Auto HTTPS
|-
| Description || ''Nextcloud''
|}

=== Handler anlegen ===
'''Reverse Proxy → Handlers''' → '''+''':
{| class="wikitable"
! Feld !! Wert
|-
| Domain || <code>https://cloud.example.com</code>
|-
| Path (Abschnitt ''Handler'') || leer (alle Pfade)
|-
| Protocol (Abschnitt ''Upstream'') || <code>http://</code>
|-
| Upstream Domain || <code>192.168.10.30</code>
|-
| Upstream Port || <code>80</code>
|}
'''Save''' und '''Apply'''. Caddy holt nun automatisch das Zertifikat. Unter '''Services → Caddy → Log File''' erscheint bei Erfolg ''certificate obtained successfully''; das Zertifikat ist zudem unter ''System → Trust → Certificates'' und im Dashboard-Widget sichtbar.

'''Test:''' <code><nowiki>https://cloud.example.com</nowiki></code> von außen und von innen aufrufen.

{{Hinweis|Nextcloud muss dem Proxy vertrauen: In der <code>config.php</code> die Firewall-Adresse unter <code>trusted_proxies</code> eintragen, die Domain unter <code>trusted_domains</code> und <code>'overwriteprotocol' => 'https'</code> setzen. Viele andere Anwendungen benötigen eine vergleichbare Einstellung (''Base URL'', ''Trusted Proxy'').}}

== Schritt 4: Zugriff auf interne Netze beschränken (Access List) ==
Ein Reverse Proxy nimmt zunächst Verbindungen von überall an. Eine Firewall-Regel würde alle Domains gleichzeitig betreffen – '''Access Lists''' wirken dagegen pro Domain.
# '''Reverse Proxy → HTTP Access → Access Lists''' → '''+''': Name <code>intern</code>, '''Client IP Addresses''' <code>192.168.0.0/16</code>, <code>172.16.0.0/12</code>, <code>10.0.0.0/8</code> (zusätzlich ggf. das VPN-Tunnelnetz).
# Domain <code>wiki.example.com</code> anlegen und im Abschnitt '''Access''' die Access List <code>intern</code> auswählen.
# Handler für <code>wiki.example.com</code> anlegen (siehe Schritt 5) und '''Apply'''.
Verbindungen von außen werden nun abgewiesen. Im ''advanced mode'' der Access List lässt sich statt des Verbindungsabbruchs ein HTTP-Statuscode (z. B. 403) zurückgeben – hilfreich für Monitoring-Systeme.

=== Alternativen: Basic Auth und Client-Zertifikate ===
* '''Basic Auth:''' Unter ''HTTP Access → Basic Auth'' Benutzer mit Passwort anlegen und im Abschnitt ''Access'' der Domain auswählen – eine einfache Passwortabfrage vor der Anwendung.
* '''Client Auth (mTLS):''' Für höchsten Schutz im Abschnitt ''Access'' der Domain unter '''Client Auth Trust Pool''' die eigene CA (aus ''System → Trust'') auswählen und den '''Client Auth Mode''' festlegen – nur Geräte mit einem Zertifikat dieser CA kommen durch.

== Schritt 5: Interne HTTPS-Server mit selbstsignierten Zertifikaten ==
Viele interne Dienste (z. B. <code>wiki.example.com</code> auf <code>https://192.168.10.50</code>) sprechen nur HTTPS mit selbstsigniertem Zertifikat. Zwei Möglichkeiten:
* '''Sauber:''' Das Zertifikat (bzw. die interne CA) unter ''System → Trust → Authorities'' importieren und im Handler unter '''TLS Trust Pool''' auswählen; unter '''TLS Server Name''' den Namen aus dem Zertifikat (SAN) eintragen.
* '''Schnell (nur in vertrauenswürdigen Netzen):''' Im Handler <code>https://</code> wählen und '''TLS Insecure Skip Verify''' aktivieren.
Caddy akzeptiert keine Zertifikate, die den Namen nur im ''Common Name'' (ohne SAN) tragen.

=== Sonderfall: OPNsense-Weboberfläche über Caddy ===
# Domain <code>opn.example.com</code> mit Access List <code>intern</code> anlegen.
# Das selbstsignierte Zertifikat der Weboberfläche im Browser exportieren und unter ''System → Trust → Authorities'' als ''opnsense-selfsigned'' importieren.
# Handler: Upstream <code>https://</code>, <code>127.0.0.1</code>, Port <code>8443</code>, '''TLS Trust Pool''' ''opnsense-selfsigned'', '''TLS Server Name''' = SAN des Zertifikats (z. B. <code>OPNsense.localdomain</code>).
# Unter ''System → Settings → Administration'' bei '''Alternate Hostnames''' <code>opn.example.com</code> eintragen – sonst meldet die Weboberfläche einen HTTP_REFERER-Fehler.

== Schritt 6: Wildcard-Domain mit DNS-01-Challenge ==
Statt jede Subdomain einzeln mit eigenem Zertifikat zu betreiben, kann Caddy ein '''Wildcard-Zertifikat''' <code>*.example.com</code> verwenden – praktisch bei vielen Diensten und um interne Hostnamen nicht in öffentlichen Zertifikatsprotokollen (Certificate Transparency) zu veröffentlichen.
* '''Mit Cloudflare-DNS:''' ''General Settings → DNS Provider'': ''Cloudflare'', API-Token eintragen, ''Resolvers'' z. B. <code>1.1.1.1</code>. Dann die Domain <code>*.example.com</code> mit aktivierter '''DNS-01 Challenge''' anlegen und darunter '''Subdomains''' wie <code>cloud.example.com</code> erstellen; Handler zeigen dann auf ''Domain'' <code>*.example.com</code> + ''Subdomain''.
* '''Mit anderen DNS-Anbietern:''' Seit Plugin-Version 2.0 ist Cloudflare der einzige integrierte DNS-Provider. Für andere Anbieter das Wildcard-Zertifikat mit '''[[OPNsense - ACME-Client für Let's Encrypt-Zertifikate|os-acme-client]]''' ausstellen, in der Caddy-Domain als ''Certificate'' auswählen und im ACME-Client eine Automatisierung anlegen, die Caddy nach jeder Verlängerung '''neu lädt''' (nicht neu startet).
Ein Wildcard-Zertifikat enthält nicht die Basisdomain <code>example.com</code> – dafür bei Bedarf eine eigene Domain anlegen.

== Schritt 7: Single Sign-On mit authentik (Forward Auth) ==
Mit '''Forward Auth''' fragt Caddy vor jedem Zugriff bei '''[[Authentik – Open-Source-Identity-Provider für Single Sign-On|authentik]]''' nach, ob der Benutzer angemeldet und berechtigt ist. So lassen sich auch Anwendungen ohne eigene Benutzerverwaltung mit SSO und MFA schützen – im Walkthrough Grafana.

=== In authentik ===
# '''Applications → Create with Provider''': Name ''Grafana'', Provider-Typ '''Proxy Provider''' im Modus '''Forward auth (single application)''', '''External host''' <code><nowiki>https://grafana.example.com</nowiki></code>.
# Die Anwendung dem '''Embedded Outpost''' zuweisen (''Applications → Outposts'').
# Zugriff über ''Policy / Group / User Bindings'' auf die gewünschte Gruppe beschränken.

=== In Caddy ===
# '''General Settings''' (advanced mode), Bereich Forward Auth: '''Forward Auth Provider''' ''Authentik'', '''Protocol''' <code>http://</code> bzw. <code>https://</code>, '''Forward Auth Domain''' = authentik-Server (z. B. <code>192.168.10.60</code>), '''Forward Auth Port''' <code>9000</code> (HTTP) bzw. <code>9443</code>, '''Forward Auth URI''' <code>/outpost.goauthentik.io/auth/caddy</code>. Speichern.
# Domain <code>grafana.example.com</code> und Handler zu <code>http://192.168.10.40:3000</code> anlegen; im Handler (advanced mode) '''Forward Auth''' aktivieren.
# '''Apply'''.
Das Plugin ergänzt automatisch die nötige Weiterleitung von <code>/outpost.goauthentik.io/*</code> an authentik und übergibt die authentik-Header (Benutzername, Gruppen, E-Mail) an die Anwendung. Auf derselben Domain sollten dann keine Access Lists oder Basic Auth zusätzlich gesetzt werden.

== Schritt 8: Kontrolle und Diagnose ==
* '''Services → Caddy → Diagnostics''' zeigt das erzeugte '''Caddyfile''' und die JSON-Konfiguration – ideal, um zu prüfen, was die Oberfläche tatsächlich konfiguriert hat.
* '''Log File''' für Zertifikatsausstellung, Fehler bei Upstreams und Startprobleme; für Detailanalysen in den ''Log Settings'' das Log-Level erhöhen.
* Das '''Dashboard-Widget''' zeigt Domains und Gültigkeit der Zertifikate.

== Fortgeschrittene Funktionen ==
=== Mehrere Handler pro Domain ===
Pro Domain können mehrere Handler mit unterschiedlichen Pfaden angelegt werden, z. B. <code>/api/*</code> an einen anderen Server als der Rest. Handler ohne Pfad werden automatisch zuletzt ausgewertet. Mit ''handle_path'' wird der Pfad vor der Weiterleitung entfernt, mit ''handle'' bleibt er erhalten. Access Lists und Basic Auth lassen sich auch pro Handler setzen – etwa um nur <code>/admin/*</code> auf interne Netze zu beschränken.

=== Lastverteilung und Health Checks ===
Werden in einem Handler mehrere '''Upstream Domains''' eingetragen, verteilt Caddy die Last. Passive und aktive '''Health Checks''' nehmen ausgefallene Server automatisch aus der Verteilung.

=== Header anpassen (vHosts) ===
Erwartet ein interner Webserver einen anderen Hostnamen, unter ''Reverse Proxy → Headers'' einen Eintrag ''header_up'' ''Host'' <code>{upstream_hostport}</code> anlegen und im Handler auswählen.

=== ACME-Challenge an interne Server durchreichen ===
Braucht eine Anwendung hinter Caddy ein eigenes Zertifikat (HTTP-01), in der Domain (advanced mode) unter '''HTTP-01 Challenge Redirection''' die IP des internen Servers eintragen. Caddy nutzt dann selbst TLS-ALPN-01 und reicht die HTTP-01-Challenge durch.

=== Layer4-Proxy ===
Nach Aktivieren von '''Enable Layer4 Proxy''' kann Caddy unter ''Services → Caddy → Layer4 Proxy'' auch Nicht-HTTP-Verkehr weiterleiten:
* '''listener_wrappers:''' Auf Port 443 wird z. B. SSH erkannt und an einen Server weitergeleitet, während HTTPS weiter beim Reverse Proxy landet.
* '''global:''' Beliebige freie TCP/UDP-Ports, optional mit Protokollerkennung (TLS mit SNI, RDP, SSH, OpenVPN, WireGuard, DNS u. a.) – z. B. TLS-Durchleitung ohne Entschlüsselung an einen Server, der sein Zertifikat selbst verwaltet.
Der Layer4-Proxy ist für fortgeschrittene Szenarien gedacht und sollte bei Problemen zuerst deaktiviert werden.

=== CrowdSec-Anbindung ===
Caddy bietet keine Web Application Firewall, lässt sich aber mit '''CrowdSec''' (Plugin ''os-crowdsec'') kombinieren, das anhand der Zugriffslogs bekannte Angreifer-IPs sperrt. Einrichtung, Funktionsweise und weitere Möglichkeiten von CrowdSec beschreibt der Artikel [[OPNsense - CrowdSec]]. Für Caddy genügen folgende Schritte:
# ''General Settings → Log Settings'': '''Log HTTP Access in JSON Format''' aktivieren, in jeder überwachten Domain unter ''Access'' '''HTTP Access Log''' einschalten.
# Per SSH die CrowdSec-Collection installieren und die Logquelle eintragen:
<syntaxhighlight lang="bash">
cscli collections install crowdsecurity/caddy
cat > /usr/local/etc/crowdsec/acquis.d/caddy.yaml <<'EOF'
filenames:
- /var/log/caddy/access/*.log
force_inotify: true
poll_without_inotify: true
labels:
type: caddy
EOF
</syntaxhighlight>
# CrowdSec in der Weboberfläche neu starten.

=== Hochverfügbarkeit (CARP) ===
Bei zwei Firewalls mit CARP muss auch die Backup-Firewall Zertifikate erhalten. Möglich sind eigene Zertifikate aus ''System → Trust'', die '''DNS-01 Challenge''' oder die '''HTTP-01 Challenge Redirection''' auf die Sync-Adresse der Backup-Firewall – jeweils mit Synchronisation per XMLRPC.

=== Caddy ohne Root-Rechte ===
Unter ''General Settings → Advanced Settings'' kann Caddy als Benutzer '''www''' laufen. Dann sind nur Ports ab 1024 möglich (z. B. 8080/8443); die Standardports werden per Destination NAT dorthin weitergeleitet.

== Typische Probleme und Lösungen ==
{| class="wikitable"
! Symptom !! Ursache und Lösung
|-
| Caddy startet nicht, Port belegt || Weboberfläche oder ein anderes Plugin nutzt noch Port 80/443 – Schritt 1 prüfen.
|-
| Kein Zertifikat, Fehler im Log || A/AAAA-Record fehlt oder zeigt woanders hin; WAN-Regel für Port 80/443 fehlt; bei IPv6 ohne globale Adresse auf dem WAN schlägt TLS-ALPN-01 fehl.
|-
| Fehler 502 Bad Gateway || Upstream nicht erreichbar oder falsches Protokoll (http/https) bzw. Port im Handler.
|-
| Upstream-HTTPS-Fehler || Zertifikat des internen Servers nicht vertrauenswürdig – TLS Trust Pool + TLS Server Name setzen oder (intern) TLS Insecure Skip Verify.
|-
| Anwendung erzeugt falsche Links/Umleitungen || Anwendung kennt den Proxy nicht – Trusted Proxy, Base URL bzw. <code>overwriteprotocol</code> in der Anwendung setzen.
|-
| Internes ACME der Anwendung scheitert || Caddy fängt <code>/.well-known/acme-challenge</code> ab – HTTP-01 Challenge Redirection nutzen.
|-
| Echte Client-IP fehlt (hinter Cloudflare) || ''Trusted Proxies'' auf die Cloudflare-Netze und ''Client IP Headers'' auf <code>Cf-Connecting-Ip</code> setzen.
|}

== Sicherheitsempfehlungen ==
* '''Nur veröffentlichen, was nötig ist''' – interne Dienste per Access List auf interne Netze/VPN beschränken.
* '''Anwendungen ohne starke Anmeldung''' per Forward Auth (authentik mit MFA) oder mTLS schützen; Basic Auth nur als einfache Zusatzhürde.
* '''Anwendungen aktuell halten''' – der Reverse Proxy schützt nicht vor Schwachstellen der Anwendung; dafür ist eine WAF (OPNWAF) oder zumindest [[OPNsense - CrowdSec|CrowdSec]] sinnvoll.
* '''Port 80 schließen''', wenn Anwendungen Cookies ohne ''Secure''-Flag setzen und keine HTTP-01-Challenge benötigt wird (dann DNS-01 nutzen).
* '''Logs auswerten:''' Zugriffslogs (JSON) an ein SIEM weiterleiten, z. B. ein [https://www.max-it.de/it-services/siem-open-source/ Open-Source-SIEM auf Wazuh-Basis].

== Fazit ==
Mit os-caddy wird die OPNsense zum komfortablen Reverse Proxy: Domain anlegen, Handler definieren, fertig – die Zertifikate kümmern sich um sich selbst. Access Lists, Basic Auth, mTLS und Forward Auth mit authentik bieten abgestufte Schutzmöglichkeiten, und für Spezialfälle stehen Wildcard-Zertifikate, Lastverteilung, Layer4-Routing und CrowdSec bereit. Für die Veröffentlichung interner Webdienste in kleinen und mittleren Unternehmen ist Caddy damit eine der elegantesten Lösungen auf der OPNsense.

== Unterstützung von m.a.x. it ==
Sie möchten interne Webanwendungen sicher veröffentlichen, Single Sign-On mit authentik vorschalten oder Ihren Reverse Proxy um eine Web Application Firewall ergänzen? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit [https://www.max-it.de/it-services/opnsense/ OPNsense-Firewall-Services von m.a.x. it] und einer [https://www.max-it.de/it-services/managed-firewall/ Managed Firewall von m.a.x. it].

== Siehe auch ==
* [[OPNsense - ACME-Client für Let's Encrypt-Zertifikate]]
* [[OPNsense - CrowdSec]]
* [[Authentik – Open-Source-Identity-Provider für Single Sign-On]]
* [[OPNsense - HAProxy mit Passwortauthentifizierung]]
* [[OPNsense - Stunnel-Plugin]]
* [[OPNsense - Plugin-Liste]]
* [[Reverse Proxy]]
* [[Let's Encrypt]]
* [[ACME]]
* [[HTTP/3]]
* [[Web Application Firewall]]

== Links und Quellen ==
* [https://docs.opnsense.org/manual/how-tos/caddy.html OPNsense-Doku – Caddy Reverse Proxy und Layer4 Proxy]
* [https://caddyserver.com/docs/ Caddy – offizielle Dokumentation]
* [https://github.com/opnsense/plugins/tree/master/www/caddy Quellcode und Changelog des Plugins os-caddy]
* [https://docs.goauthentik.io/add-secure-apps/providers/proxy/server_caddy/ authentik – Forward Auth mit Caddy]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

{{Uebermax}}
[[Kategorie:IT-Security]]

OPNsense - Caddy Reverse Proxy - Versionsgeschichte

imported>TechCorner-Redaktion: Verlinkung auf den Artikel OPNsense - ACME-Client für Let's Encrypt-Zertifikate ergänzt