Für die meisten Server ist das kein Drama, sofern die Erneuerung wirklich automatisch läuft. Für alle, bei denen irgendwo eine feste Zahl in einem Cronjob steht, ist es eine Frist. Diese Meldung sortiert, was sich wann ändert, welche verbreiteten ACME-Programme damit klarkommen und wo es eng wird.

Let's Encrypt 64 Tage: die Termine im Überblick

Ganz neu ist der Plan nicht. Bereits am 2. Dezember 2025 hatte Let's Encrypt den Weg von 90 auf 45 Tage angekündigt, mit einem Zwischenschritt über 64 Tage. Neu ist, dass die Termine jetzt verbindlich bestätigt sind und der Testbetrieb deutlich früher beginnt als damals in Aussicht gestellt. Die Daten im Einzelnen:

• Seit 13. Mai 2026: Wer will, kann über das Profil tlsserver bereits 45 Tage gültige Zertifikate beziehen. Das ist freiwillig und für Frühstarter gedacht.
• 14. Oktober 2026: Die Testumgebung (Staging) stellt auf 64-Tage-Zertifikate um, und zwar mit genau dem Verhalten, das ab Februar in der Produktion gilt. Das bestätigt ein Mitarbeiter von Let's Encrypt im Community-Forum.
• 10. Februar 2027: Das Standardprofil classic liefert nur noch 64 Tage. Gleichzeitig sinkt die Zeit, während der eine erfolgreiche Domainprüfung wiederverwendet werden darf, von 30 auf 10 Tage.
• Um den 11. Mai 2027: Das letzte 90-Tage-Zertifikat läuft voraussichtlich ab. Gültige Zertifikate werden laut Let's Encrypt im Zuge der Umstellung nicht widerrufen.
• 16. Februar 2028: Das Standardprofil sinkt auf 45 Tage, die Wiederverwendung einer Domainprüfung auf sieben Stunden.

Unverändert bleiben nach Angaben von Let's Encrypt die Rate Limits, die ACME-Adressen und die Zertifikatskette. Zu den Rate Limits hatte Let's Encrypt schon im Februar einen eigenen Beitrag veröffentlicht: Erneuerungen zählen nicht auf die Grenzen für neue Zertifikate, also ändert die häufigere Erneuerung daran nichts.

Was gegenüber Dezember neu ist

Im Dezember hiess es noch, jede Änderung erreiche die Testumgebung etwa einen Monat vor der Produktion. Jetzt sind es fast vier Monate. Das ist die eigentlich nützliche Nachricht dieser Woche: Wer seine Erneuerung, seine Reload-Skripte und seine Überwachung gegen echte 64-Tage-Zertifikate prüfen will, kann das ab dem 14. Oktober tun und muss nicht bis Januar warten. Ausserdem nennt die Mitteilung zum ersten Mal ein konkretes Ablaufdatum für die letzten 90-Tage-Zertifikate.

Warum die Zertifikate kürzer werden

Let's Encrypt handelt nicht aus eigenem Antrieb. Im April 2025 hat das CA/Browser Forum, in dem sich Zertifizierungsstellen und Browserhersteller auf gemeinsame Regeln einigen, den Antrag SC081v3 angenommen. Er senkt die höchstzulässige Laufzeit öffentlich vertrauter Zertifikate schrittweise von 398 auf 47 Tage und die Wiederverwendung einer Domainprüfung von 398 auf 10 Tage. Begonnen hat das im März 2026, abgeschlossen ist es im März 2029. Die Zwischenschritte fasst der DNS-Anbieter DNSimple übersichtlich zusammen: höchstens 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Alle vier grossen Browserhersteller, Apple, Google, Microsoft und Mozilla, haben zugestimmt, keine Zertifizierungsstelle hat dagegen gestimmt.

Die Begründung ist nüchtern. Ein Zertifikat, dessen Schlüssel gestohlen wurde, bleibt bis zu seinem Ablauf gültig, wenn der Widerruf nicht greift, und der Widerruf greift in der Praxis schlecht. Je kürzer die Laufzeit, desto kürzer das Zeitfenster für Missbrauch. Let's Encrypt schreibt dazu im Dezemberbeitrag, kürzere Laufzeiten begrenzten den Schaden einer Kompromittierung und machten den Widerruf wirksamer.

Bemerkenswert ist das Tempo. Let's Encrypt lag mit 90 Tagen schon immer weit unter den Branchenregeln und bleibt das auch: Die 64 Tage greifen einen Monat, bevor die 100-Tage-Grenze überhaupt in Kraft tritt. Kommerzielle Anbieter, die früher Jahreszertifikate verkauften, mussten schon im März 2026 auf 200 Tage herunter und dürfen ihren Kunden ab März 2027 erklären, warum das Produkt nach 100 Tagen erneuert werden muss. Das ist allerdings nicht euer Problem.

Wann certbot, acme.sh und Caddy erneuern

Ob die Umstellung euch etwas angeht, hängt fast nur davon ab, wie euer ACME-Programm den Erneuerungszeitpunkt bestimmt. Es gibt drei Verfahren: einen festen Abstand vor dem Ablauf, einen Anteil der Laufzeit, oder die Frage an die Zertifizierungsstelle selbst. Für Letzteres gibt es seit Juni 2025 den Standard RFC 9773, ACME Renewal Information (ARI): Der Server nennt dem Client ein Zeitfenster, in dem er erneuern soll. Let's Encrypt bietet ARI seit März 2023 an.

Caddy: erledigt sich selbst

Caddy unterstützt ARI seit Version 2.8 und zieht es zusammen mit Laufzeit und Widerrufsstatus heran, um eine Erneuerung auszulösen. Wer Caddy nach unserer Anleitung zum Caddy Reverse Proxy betreibt, muss nichts ändern.

certbot: die Version entscheidet

Bei certbot kommt es darauf an, welche Fassung eure Distribution mitliefert. Bis Version 3 erneuerte certbot fest 30 Tage vor Ablauf. Version 4.0 vom 8. April 2025 stellte auf ein Drittel Restlaufzeit um, Version 4.1 vom 10. Juni 2025 fragt zusätzlich ARI ab und erneuert bei Let's Encrypt laut Changelog typischerweise nach rund zwei Dritteln der Laufzeit.

Debian 12 liefert certbot 2.1.0, Debian 13 die Version 4.0.0, so steht es im Debian-Paketverfolger. Ubuntu 24.04 hat certbot 2.9.0. Alle drei kommen mit 64 Tagen zurecht: Die alte 30-Tage-Regel erneuert ein 64-Tage-Zertifikat nach 34 Tagen, die Drittel-Regel nach rund 43 Tagen. Auch bei 45 Tagen im Jahr 2028 bleibt genug Puffer. Wer certbot mit dem vom Paket mitgelieferten Timer betreibt, ist also auf der sicheren Seite, solange niemand die Vorgabe mit einem eigenen renew_before_expiry verbogen hat.

acme.sh: hier wird es eng

Anders sieht es beim reinen Shell-Skript acme.sh aus. Laut der Handbuchseite in Debian 13 erneuert acme.sh standardmässig 60 Tage nach der Ausstellung, gesteuert über --days. ARI beherrscht es noch nicht, das schreibt der Hauptentwickler selbst in Issue 6633 und empfiehlt dort für kurzlebige Zertifikate, --days von Hand anzupassen.

Durchgerechnet bleiben bei einem 64-Tage-Zertifikat noch vier Tage zwischen dem ersten Erneuerungsversuch und dem Ablauf. Das reicht, solange nichts schiefgeht. Fällt die Erneuerung über ein langes Wochenende aus, weil der DNS-Anbieter klemmt oder Port 80 kurz zu ist, steht das Zertifikat abgelaufen da. Ab 2028, mit 45 Tagen, kommt der Erneuerungsversuch nach 60 Tagen schlicht zwei Wochen zu spät. Wer acme.sh nutzt, setzt --days deshalb jetzt auf einen Wert um 40, für jedes Zertifikat einzeln.

Dass es auch anders geht, zeigt pfSense: Das ACME-Paket dort hatte dasselbe Problem mit einem festen 60-Tage-Abstand und erneuert seit Version 1.1 standardmässig nach zwei Dritteln der Laufzeit. Das Paket ist für pfSense Plus 25.11.1 und CE 2.8.1 erschienen.

Selbst geschriebene Skripte und Cronjobs

Die grösste Gefahr steckt nicht in den bekannten Programmen, sondern in Eigenbauten: dem Skript, das alle 60 Tage --force-renewal auslöst, oder dem Überwachungscheck, der erst bei 80 Tagen Alter Alarm gibt. Let's Encrypt rät ausdrücklich dazu, Cronjobs, Hilfsskripte und Betriebsanleitungen nach typischen fest eingetragenen Werten wie 83, 80 oder 60 zu durchsuchen. Ein Skript, das erst nach 80 oder 83 Tagen erneuert, kommt bei 64 Tagen schlicht zu spät. Ohne ARI empfiehlt Let's Encrypt, nach ungefähr zwei Dritteln der Laufzeit zu erneuern.

Eine Sache, die viele noch im Kopf haben, gibt es übrigens nicht mehr: die Warn-E-Mail vor dem Ablauf. Let's Encrypt hat diesen Dienst am 4. Juni 2025 eingestellt. Wer sich darauf verlassen hat, ist seit über einem Jahr ohne Netz unterwegs. Auch unsere ältere Anleitung zum SSL-Zertifikat für den Nextcloud-Homeserver geht noch davon aus, dass diese Mail kommt.

Die kürzere Wiederverwendung der Domainprüfung

Der zweite Teil der Änderung fällt weniger auf. Bisher durfte Let's Encrypt eine erfolgreiche Domainprüfung 30 Tage lang für weitere Zertifikate wiederverwenden, ab Februar sind es 10 Tage. Wer die Erneuerung voll automatisch erledigt, merkt davon laut Let's Encrypt nichts, ausser der Client ist ausdrücklich darauf gebaut, sich auf die Wiederverwendung zu verlassen. Betroffen sind vor allem Setups mit DNS-Challenge, bei denen der TXT-Eintrag von Hand gesetzt wird. Für sie hat Let's Encrypt im Februar das Verfahren DNS-PERSIST-01 angekündigt, bei dem ein dauerhafter TXT-Eintrag ein bestimmtes ACME-Konto berechtigt. Der Produktivstart war für das zweite Quartal 2026 angepeilt; ob er erfolgt ist, sagt die aktuelle Mitteilung nicht.

Was ihr bis Februar prüfen solltet

Das meiste davon ist eine Sache von zehn Minuten pro Server. Die Reihenfolge ist so gewählt, dass ihr nach dem ersten Punkt bereits wisst, ob der Rest euch überhaupt betrifft.

1. Herausfinden, welcher Client erneuert. Bei certbot zeigt certbot --version die Fassung, bei acme.sh acme.sh --version. Läuft Caddy, ist der Punkt erledigt.
2. Feste Zahlen suchen. Durchsucht Cronjobs und systemd-Units nach Erneuerungsabständen. Ein grober erster Durchgang, der alle Zeilen mit den von Let's Encrypt genannten Werten zeigt:

sudo grep -rnwE '60|80|83' /etc/cron* /etc/systemd/system /var/spool/cron 2>/dev/null

Nicht jeder Treffer hat mit Zertifikaten zu tun, eine Minutenangabe von 60 ist harmlos. Gesucht sind Zeilen, in denen certbot, acme.sh, --days, --force-renewal oder ein eigenes Erneuerungsskript vorkommt.

3. Ab dem 14. Oktober gegen Staging testen. certbot holt mit --dry-run laut Handbuchseite ein Testzertifikat von der Staging-Umgebung, ohne es zu speichern. Das prüft, ob die Challenge durchläuft:

sudo certbot renew --dry-run

4. Die Laufzeit des aktuellen Zertifikats ansehen. So seht ihr, wann es ausgestellt wurde und abläuft. Den Domainnamen ersetzt ihr durch euren:

sudo openssl x509 -noout -dates -in /etc/letsencrypt/live/cloud.example.ch/cert.pem

5. acme.sh umstellen. Setzt --days beim nächsten Ausstellen auf einen Wert um 40, damit auch bei 45 Tagen im Jahr 2028 Puffer bleibt.
6. Eine Ablaufwarnung einrichten, die nicht von Let's Encrypt kommt. Die Mail gibt es nicht mehr. Eine eigene Prüfung per systemd-Timer mit Benachrichtigung bei Fehlschlag haben wir in der Anleitung systemd-Timer statt Cronjob beschrieben; openssl x509 -checkend mit einer Sekundenzahl ist dafür der passende Baustein.
7. Den Reload nicht vergessen. Ein erneuertes Zertifikat nützt nichts, wenn der Webserver weiter das alte ausliefert. Bei certbot erledigt das ein Deploy-Hook, bei Diensten mit eigener Zertifikatskopie (Mailserver, Datenbanken, NAS) muss die Kopie nach jeder Erneuerung neu verteilt werden. Wer nach zwei Dritteln der Laufzeit erneuert, tut das bei 64 Tagen rund achtmal im Jahr statt wie bisher rund sechsmal.

Fazit: 64 Tage bestrafen nur Handarbeit

Für einen sauber automatisierten Server ändert der 10. Februar 2027 nichts, ausser dass im Log etwas öfter eine Erneuerung steht. Caddy, aktuelle certbot-Fassungen und alles, was ARI spricht, regeln das selbst. Selbst die alten certbot-Versionen in Debian 12 und Ubuntu 24.04 kommen mit ihrer starren 30-Tage-Regel durch.

Treffen wird es die Stellen, an denen ein Mensch einmal eine Zahl eingetragen hat und seither niemand mehr hingesehen hat: das acme.sh mit 60 Tagen, das Skript mit erzwungener Erneuerung, das NAS, auf das jemand das Zertifikat von Hand kopiert. Genau darauf zielt die Branche, und es fällt schwer, ihr zu widersprechen. Ein Zertifikat, das ein Jahr hält, verzeiht vergessene Automatisierung; eines, das 64 Tage hält, deckt sie auf. Wer die Testumgebung ab dem 14. Oktober nutzt, findet diese Stellen im Herbst statt an einem Februarmorgen, an dem die Nextcloud plötzlich eine rote Warnseite zeigt.

Quellen und weiterführende Links

• Let's Encrypt: 64-Day Certificate Lifetimes Coming Feb 2027, Ankündigung vom 7. Oktober 2026
• Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days, Zeitplan vom 2. Dezember 2025
• Let's Encrypt: Profiles, Profile classic, tlsserver und shortlived
• Let's Encrypt: Rate Limits and 45-Day Certificates, Februar 2026
• Let's Encrypt Community: Staging-Termin für die 64-Tage-Zertifikate
• Let's Encrypt: Expiration Notification Service Has Ended
• Let's Encrypt: DNS-PERSIST-01, Ankündigung vom 18. Februar 2026
• Let's Encrypt: Upcoming Features, Stand der Funktionen inklusive ARI
• CA/Browser Forum: Ballot SC081v3, Beschluss und Abstimmungsergebnis
• DNSimple: SSL Certificate Validity Changes (2026–2029), Zwischenschritte des Zeitplans
• RFC 9773: ACME Renewal Information (ARI) Extension
• Certbot 4.0.0 und Certbot 4.1.0, Changelogs zu Erneuerungszeitpunkt und ARI
• Debian-Paketverfolger: python-certbot und Ubuntu-Paket certbot in 24.04
• certbot(1) und acme.sh(1), Handbuchseiten in Debian 13
• acme.sh Issue 6633, Aussage des Entwicklers zu fehlender ARI-Unterstützung
• Caddy v2.8.0 Release Notes, ARI-Unterstützung
• pfSense Redmine 16603, Erneuerung nach zwei Dritteln der Laufzeit im ACME-Paket 1.1

The post Let's Encrypt 64 Tage: kürzere Zertifikate ab 2027 appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Diese Anleitung baut direkt auf unserer Einrichtung des Caddy Reverse Proxy mit automatischem HTTPS auf; Installation, Caddyfile und Zertifikate für den Server setzen wir voraus. Hier kommt die andere Richtung dazu: Nicht nur der Server weist sich gegenüber eurem Gerät aus, sondern auch euer Gerät gegenüber dem Server. Dafür legen wir mit OpenSSL eine eigene kleine Zertifizierungsstelle an, stellen jedem Gerät ein Zertifikat aus, bringen Caddy bei, nur noch diese zu akzeptieren, und klären, wie ihr ein verlorenes Gerät wieder aussperrt.

mTLS mit Caddy: was gegenseitiges TLS leistet

Bei gewöhnlichem HTTPS ist die Prüfung einseitig. Der Server zeigt ein Zertifikat vor, euer Browser prüft es, und danach steht eine verschlüsselte Verbindung — zu irgendwem. Bis zum Login hat jeder Besucher Zugriff auf alles, was davor liegt: Anmeldemaske, öffentliche Schnittstellen und jede Sicherheitslücke, die genau dort steckt.

Mutual TLS, kurz mTLS, macht die Prüfung gegenseitig. Während des TLS-Handshakes fordert der Server zusätzlich ein Zertifikat vom Client an und prüft, ob es von einer Stelle unterschrieben ist, der er vertraut. Fehlt es oder stammt es von einer fremden Stelle, endet die Verbindung, bevor eine einzige HTTP-Anfrage ausgewertet wird. Das Anmeldeformular bleibt, steht aber hinter einer zweiten Tür, die sich nur für Geräte öffnet, die ihr selbst ausgestattet habt.

Wichtig ist die Abgrenzung zu einem Verfahren, das wir schon beschrieben haben. Die SSH-Zertifikate aus unserer SSH-CA-Anleitung folgen derselben Idee, benutzen aber ein eigenes OpenSSH-Format ohne jede Verbindung zu X.509. Hier geht es um X.509-Zertifikate, also dasselbe Format, das auch euer Server für HTTPS vorzeigt. Eine SSH-CA lässt sich für mTLS nicht weiterverwenden, und umgekehrt.

Warum es eine eigene Zertifizierungsstelle sein muss

Die naheliegende Frage lautet, ob sich nicht einfach Let's Encrypt einspannen lässt. Die Antwort ist seit diesem Sommer endgültig nein. Let's Encrypt hat im Mai 2025 angekündigt, die Verwendung für Client-Authentifizierung aus seinen Zertifikaten zu streichen: Das Standardprofil verlor sie am 11. Februar 2026, und am 8. Juli 2026 wurde auch das Übergangsprofil tlsclient eingestellt. Als Grund nennt das Projekt die Vorgabe des Chrome-Root-Programms, Server- und Client-Authentifizierung bis Juni 2026 in getrennte Infrastrukturen aufzuteilen. Gleich dazu steht der Hinweis, viele Anwendungsfälle seien mit einer privaten Zertifizierungsstelle ohnehin besser bedient.

Für euren Zweck ist das sogar der bessere Weg. Ein öffentliches Zertifikat beweist nur, dass jemand eine Domain kontrolliert, und das kann jeder. Eine eigene Zertifizierungsstelle beweist, dass ihr dieses Gerät persönlich ausgestattet habt. Genau diese Aussage soll Caddy prüfen. Dass ein Weltkonzern seine Wurzelzertifikate neu sortiert und dabei zufällig das Richtige für Selfhoster herauskommt, ist selten genug, um es einmal festzuhalten.

mTLS oder VPN?

Das gleiche Ziel — nur eigene Geräte kommen an den Dienst — erreicht auch ein VPN, etwa ein eigener Wireguard-Server. Der Unterschied liegt in der Ebene. Ein VPN öffnet einen Tunnel ins Netz, und hinter dem Tunnel ist dann alles erreichbar, was dort freigegeben ist. mTLS gilt pro Dienst und pro Hostname, und auf dem Gerät muss nichts laufen ausser dem Browser oder der App, die ohnehin benutzt wird.

Ein VPN ist die richtige Wahl für Verwaltungsoberflächen, die gar nicht öffentlich sein sollen. mTLS passt dort, wo ein Dienst bewusst im Internet steht, weil Familie oder Freunde ihn ohne VPN-Client nutzen sollen.

Was ihr für die Client-Zertifikate braucht

• Einen laufenden Caddy in Version 2.11.1 oder neuer. Älteren Fassungen fehlt eine Sicherheitskorrektur, die genau diese Funktion betrifft; mehr dazu in Schritt 3. Die aktuelle Version zeigt caddy version.
• OpenSSL auf dem Rechner, der die Zertifizierungsstelle verwahrt. Unter Debian und Ubuntu ist es vorinstalliert. Die Befehle unten wurden mit OpenSSL 3 geprüft.
• Einen sicheren Ort für den privaten Schlüssel der Zertifizierungsstelle. Das ist nicht der Server, auf dem Caddy läuft. Ein verschlüsselter Arbeitsrechner oder USB-Stick genügt.
• Einen zweiten Zugang zum Server, etwa eine offene SSH-Sitzung. Sonst sperrt euch ein Tippfehler aus.

Schritt 1: Eine eigene Zertifizierungsstelle anlegen

Die Zertifizierungsstelle, kurz CA, ist bei OpenSSL ein Schlüsselpaar und ein selbst unterschriebenes Zertifikat. Erzeugt wird beides auf dem Rechner, auf dem es dauerhaft bleiben soll:

mkdir -p ~/client-ca && chmod 700 ~/client-ca
cd ~/client-ca

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out client-ca.key
chmod 600 client-ca.key

openssl req -x509 -new -key client-ca.key -sha256 -days 3650 \
  -subj "/CN=Heimnetz Client-CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -out client-ca.crt

Der erste Befehl erzeugt einen Schlüssel auf der Kurve P-256, der zweite daraus ein zehn Jahre gültiges Zertifikat. Die Optionen sind in openssl-req(1) beschrieben: -x509 erzeugt direkt ein Zertifikat statt einer Anfrage, und -addext fügt eine Erweiterung hinzu, in derselben Schreibweise wie in einer Konfigurationsdatei.

Die beiden Erweiterungen sind der eigentliche Inhalt. basicConstraints mit CA:TRUE erklärt das Zertifikat zur Zertifizierungsstelle, und pathlen:0 bedeutet laut x509v3_config(5), dass sie nur Endzertifikate unterschreiben darf, keine weiteren Zwischenstellen. keyUsage beschränkt den Schlüssel auf das Signieren von Zertifikaten und Sperrlisten. Prüft das Ergebnis:

openssl x509 -in client-ca.crt -noout -subject -enddate -ext basicConstraints,keyUsage

Die Datei client-ca.crt ist öffentlich und wandert gleich auf den Server. Die Datei client-ca.key ist das Gegenteil: Wer sie besitzt, kann sich selbst ein Zertifikat für jeden eurer Dienste ausstellen. Für sie gilt dasselbe wie für den CA-Schlüssel aus der SSH-CA-Anleitung — nicht auf den Server, nicht in ein Cloud-Verzeichnis, und eine Kopie an einen zweiten Ort, wie es die 3-2-1-Regel für Backups verlangt. Wer zusätzlich eine Passphrase will, hängt beim ersten Befehl -aes256 an.

Schritt 2: Ein Client-Zertifikat pro Gerät ausstellen

Jedes Gerät bekommt ein eigenes Zertifikat, sonst lässt sich später kein einzelnes Gerät aussperren. Legt zuerst einmalig eine kleine Datei mit den Erweiterungen für Client-Zertifikate an:

cat > ~/client-ca/client.ext <<'EOF'
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
EOF

CA:FALSE verhindert, dass das Gerät selbst Zertifikate ausstellen kann. extendedKeyUsage = clientAuth ist der Eintrag, den x509v3_config(5) als "SSL/TLS WWW Client Authentication" beschreibt — genau der, den Let's Encrypt gestrichen hat. Dann das eigentliche Zertifikat, hier für einen Laptop:

cd ~/client-ca
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out laptop-mario.key
openssl req -new -key laptop-mario.key -subj "/CN=laptop-mario" -out laptop-mario.csr
openssl x509 -req -in laptop-mario.csr \
  -CA client-ca.crt -CAkey client-ca.key \
  -days 365 -sha256 -extfile client.ext \
  -out laptop-mario.crt
openssl verify -CAfile client-ca.crt laptop-mario.crt

Der Name hinter CN= ist frei wählbar. Nehmt etwas, das Person und Gerät eindeutig benennt; er taucht später in den Protokollen auf und ist das, was ihr beim Sperren sucht. Zur Seriennummer müsst ihr nichts tun: Laut openssl-x509(1) erzeugt OpenSSL eine zufällige, wenn weder -CAserial noch -CAcreateserial angegeben ist und keine Seriennummerndatei existiert. Ohne -days gälte das Zertifikat übrigens nur 30 Tage; ein Jahr ist ein brauchbarer Mittelweg zwischen Sicherheit und Erneuerungsaufwand. Die letzte Zeile muss mit laptop-mario.crt: OK enden.

Browser und Betriebssysteme wollen Schlüssel und Zertifikat in einer gemeinsamen, passwortgeschützten Datei im Format PKCS#12. Die entsteht so:

openssl pkcs12 -export \
  -in laptop-mario.crt -inkey laptop-mario.key \
  -certfile client-ca.crt \
  -name "laptop-mario" \
  -out laptop-mario.p12

OpenSSL fragt nach einem Exportpasswort. Vergebt ein echtes, denn die Datei reist gleich über USB-Stick, Messenger oder E-Mail auf das Gerät. -name setzt laut openssl-pkcs12(1) den Anzeigenamen, den Browser beim Auswählen des Zertifikats zeigen. Verschlüsselt wird standardmässig mit AES-256-CBC. Ältere Programme kennen das unter Umständen nicht; meldet ein Gerät beim Import ein falsches Passwort, obwohl es stimmt, erzeugt die Datei mit dem zusätzlichen Schalter -legacy neu, der auf die älteren Verfahren zurückfällt.

Haltet zum Schluss den Fingerabdruck fest. Ihr braucht ihn in Schritt 6, und zwar genau in dem Moment, in dem das Gerät nicht mehr greifbar ist:

openssl x509 -in laptop-mario.crt -noout -fingerprint -sha256 \
  | cut -d= -f2 | tr -d ':' | tr 'A-F' 'a-f' \
  | sed 's/^/laptop-mario /' >> ~/client-ca/register.txt

Die Umformung in Kleinbuchstaben ohne Doppelpunkte ist kein Zierrat: In genau dieser Schreibweise gibt Caddy den Fingerabdruck aus, und nur so passt er später in die Sperrregel. Die Dateien .key, .csr und .p12 des Geräts könnt ihr nach dem Import auf dem Gerät löschen; aufbewahrt werden nur das Zertifikat und das Register.

Schritt 3: Caddy verlangt das Client-Zertifikat

Auf den Server gehört ausschliesslich das öffentliche CA-Zertifikat. Legt es dort ab, wo Caddy es lesen kann:

scp ~/client-ca/client-ca.crt benutzer@server:/tmp/
ssh benutzer@server
sudo install -o root -g caddy -m 0644 /tmp/client-ca.crt /etc/caddy/client-ca.crt

Im Site-Block des Dienstes bekommt die tls-Direktive einen Unterblock client_auth:

cloud.example.ch {
	tls {
		client_auth {
			mode require_and_verify
			trust_pool file /etc/caddy/client-ca.crt
		}
	}
	reverse_proxy 127.0.0.1:8080
}

trust_pool file nennt die Datei mit dem CA-Zertifikat, gegen das geprüft wird. mode legt fest, wie streng Caddy dabei ist. Die Dokumentation kennt vier Stufen:

• request — fragt nach einem Zertifikat, lässt aber auch ohne durch und prüft keines.
• require — verlangt ein Zertifikat, prüft aber nicht, von wem es stammt.
• verify_if_given — lässt auch ohne Zertifikat durch, prüft aber jedes, das vorgezeigt wird.
• require_and_verify — verlangt ein gültiges Zertifikat und prüft es.

Für den Schutz eines ganzen Dienstes ist nur die letzte Stufe sinnvoll. Ist ein trust_pool gesetzt, ist sie laut Dokumentation ohnehin die Vorgabe; ohne trust_pool fällt Caddy auf require zurück, und dann genügt irgendein Zertifikat. Schreibt die Zeile trotzdem hin, damit niemand raten muss. Danach wie gewohnt:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Testen, bevor ihr den Browser bemüht

Am schnellsten prüft ihr das Ergebnis mit curl von einem Rechner, auf dem Zertifikat und Schlüssel liegen. Drei Aufrufe, drei erwartete Ergebnisse:

# ohne Zertifikat: Verbindung muss scheitern
curl -sS https://cloud.example.ch/

# mit Zertifikat: Antwort des Dienstes
curl -sS --cert laptop-mario.crt --key laptop-mario.key https://cloud.example.ch/

# mit einem selbst gebauten fremden Zertifikat: muss ebenfalls scheitern
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout fremd.key -out fremd.crt -subj "/CN=fremd" -days 1
curl -sS --cert fremd.crt --key fremd.key https://cloud.example.ch/

Ohne Zertifikat meldet curl einen TLS-Abbruch mit certificate required, beim fremden Zertifikat unknown ca. Genau so soll es aussehen. Nur der mittlere Aufruf darf eine Antwort des Dienstes liefern. Lasst den dritten Test nicht weg: Nur er zeigt, dass Caddy wirklich gegen eure CA prüft.

Warum die Version zählt

Ende Februar 2026 wurde in Caddy eine Lücke geschlossen, die genau diesen Aufbau betrifft. Laut dem Sicherheitshinweis GHSA-hffm-g8v7-wrv7 (CVE-2026-27586) haben zwei verschluckte Fehlermeldungen dazu geführt, dass die Client-Authentifizierung "silently fail open", wenn die CA-Datei fehlt, nicht lesbar oder beschädigt ist. Caddy startete dann ohne Warnung und nahm jedes Client-Zertifikat an, das von einer der im System hinterlegten öffentlichen Zertifizierungsstellen stammte. Ein Tippfehler im Pfad hätte den Schutz also lautlos abgeschaltet. Behoben ist das mit Caddy 2.11.1.

Mit einer aktuellen Version sieht derselbe Fehler anders aus: Zeigt trust_pool file auf eine Datei, die es nicht gibt, bricht schon caddy validate mit einer Meldung ab, die den Pfad und no such file or directory nennt. So muss es sein: Ein Fehler in der Konfiguration muss den Start verhindern, nicht den Schutz abschalten. Prüft deshalb mit caddy version, dass ihr nicht auf einer älteren Fassung sitzt, etwa aus dem Paketarchiv einer älteren Distribution.

Ein Snippet für mehrere Dienste

Sollen mehrere Dienste denselben Schutz bekommen, schreibt ihr den Block einmal als Snippet und bindet ihn überall ein. Ein Snippet steht in runden Klammern ausserhalb aller Site-Blöcke:

(mtls) {
	tls {
		client_auth {
			mode require_and_verify
			trust_pool file /etc/caddy/client-ca.crt
		}
	}
}

cloud.example.ch {
	import mtls
	reverse_proxy 127.0.0.1:8080
}

fotos.example.ch {
	import mtls
	reverse_proxy 127.0.0.1:2283
}

Eine Eigenheit nimmt euch Caddy dabei von selbst ab. Weil TLS-Einstellungen am Hostnamen aus dem Handshake hängen, die HTTP-Anfrage aber einen eigenen Host-Header mitbringt, könnte ein Client sich mit dem Namen eines ungeschützten Dienstes verbinden und dann einen geschützten anfragen. Die globale Option strict_sni_host verhindert das, und sie ist laut Dokumentation automatisch aktiv, sobald Client-Authentifizierung konfiguriert ist. Wer es ausprobiert, bekommt den Status 421 Misdirected Request.

Schritt 4: Das Client-Zertifikat auf die Geräte bringen

Jetzt braucht jedes Gerät seine .p12-Datei. Übertragt sie auf einem Weg, den ihr kontrolliert, und das Exportpasswort auf einem anderen. Die Bedienschritte unterscheiden sich je nach System:

• Firefox führt einen eigenen Zertifikatsspeicher. Unter Einstellungen, Datenschutz & Sicherheit, Abschnitt Zertifikate, öffnet Zertifikate anzeigen, wechselt auf den Reiter Ihre Zertifikate und wählt Importieren. Die Schritte entsprechen der Importanleitung von DigiCert, die dort für Firefox und Windows beschrieben ist.
• Chrome, Edge und andere Programme unter Windows greifen auf den Zertifikatsspeicher von Windows zu. Ein Doppelklick auf die .p12-Datei startet den Importassistenten; als Ziel wählt ihr den aktuellen Benutzer und den Speicher Eigene Zertifikate.
• Android verwaltet Zertifikate in den Einstellungen unter Sicherheit & Datenschutz, Weitere Sicherheitseinstellungen, Verschlüsselung & Anmeldedaten, Ein Zertifikat installieren; den Pfad beschreibt Google in der Pixel-Hilfe, die Bezeichnungen weichen je nach Hersteller leicht ab. Wählt dort die Variante für VPN- und App-Nutzerzertifikate, wie es etwa die Anleitung des MIT für dessen Client-Zertifikate zeigt — nicht die für CA-Zertifikate.
• Linux auf der Kommandozeile braucht keinen Import. curl nimmt Zertifikat und Schlüssel direkt mit --cert und --key, wie im Test oben.

Beim ersten Aufruf fragt der Browser, welches Zertifikat er vorzeigen soll, und zeigt dabei den Namen aus -name. Danach öffnet sich die gewohnte Anmeldeseite. Prüft auch die App des Dienstes: Nicht jede mobile App kann ein Client-Zertifikat aus dem Systemspeicher vorzeigen, und eine, die es nicht kann, ist ab jetzt ausgesperrt. Testet das, bevor ihr euch unterwegs darauf verlasst.

Schritt 5: Nur den Admin-Bereich hinter das Zertifikat stellen

Manchmal soll der Dienst öffentlich bleiben und nur ein Teil davon geschützt werden, etwa die Verwaltungsoberfläche unter /admin. Eine Einstellung pro Pfad gibt es bei client_auth nicht, weil das Zertifikat im TLS-Handshake abgefragt wird, bevor überhaupt ein Pfad bekannt ist. Der Umweg führt über die mildere Stufe verify_if_given und einen Matcher, der prüft, ob ein Zertifikat vorgezeigt wurde:

vault.example.ch {
	tls {
		client_auth {
			mode verify_if_given
			trust_pool file /etc/caddy/client-ca.crt
		}
	}

	@admin_ohne_zertifikat {
		path /admin*
		vars {tls_client_subject} ""
	}
	respond @admin_ohne_zertifikat "Nur mit Zertifikat" 403

	reverse_proxy 127.0.0.1:8000
}

Der Matcher vars vergleicht den Wert eines Platzhalters, hier {tls_client_subject}, also den Namen aus dem Zertifikat. Ist er leer, wurde keines vorgezeigt, und für Pfade unter /admin gibt es einen 403. Ein vorgezeigtes Zertifikat einer fremden Stelle scheitert schon im Handshake, weil verify_if_given jedes vorgezeigte Zertifikat prüft. Alles ausserhalb von /admin bleibt ohne Zertifikat erreichbar.

Zwei Nebenwirkungen solltet ihr kennen. Erstens fragt Caddy jetzt auf der ganzen Domain nach einem Zertifikat, nicht nur unter /admin; Browser mit installiertem Zertifikat bieten es deshalb auch auf der öffentlichen Seite an. Zweitens schützt dieser Aufbau nur Pfade, die ihr kennt; liegt dieselbe Funktion noch in einer API, bleibt sie offen. Eine eigene Subdomain mit require_and_verify ist deshalb robuster.

Wer ist angemeldet: Zertifikatsdaten an den Dienst weitergeben

Caddy kennt nach dem Handshake die Daten des Client-Zertifikats und stellt sie als Platzhalter bereit. Die Übersicht der Platzhalter nennt unter anderem {tls_client_subject}, {tls_client_issuer}, {tls_client_serial} und {tls_client_fingerprint}. Mit header_up reicht ihr davon weiter, was der Dienst dahinter wissen soll:

cloud.example.ch {
	import mtls
	reverse_proxy 127.0.0.1:8080 {
		header_up X-Client-Subject {tls_client_subject}
	}
}

Der Dienst sieht dann eine Kopfzeile wie X-Client-Subject: CN=laptop-mario, aber nie das Zertifikat oder gar den Schlüssel. In unserem Test mit Caddy 2.11.4 hat Caddy eine vom Client mitgeschickte, gefälschte Kopfzeile gleichen Namens dabei überschrieben. Darauf verlassen darf sich der Dienst trotzdem nur, wenn er ausschliesslich über Caddy erreichbar ist, also an 127.0.0.1 gebunden, wie in der Caddy-Grundanleitung beschrieben. Sonst kann jeder Caddy umgehen und die Kopfzeile selbst setzen.

Schritt 6: Ein Gerät ist weg — Zertifikat sperren

Das klassische Werkzeug zum Widerrufen von X.509-Zertifikaten ist eine Sperrliste. Die Dokumentation der tls-Direktive erwähnt allerdings an keiner Stelle Sperrlisten oder eine andere Widerrufsprüfung für Client-Zertifikate. Verlasst euch also nicht darauf.

Der verlässliche Weg ist eine Sperrregel mit demselben Matcher wie in Schritt 5, gestützt auf den Fingerabdruck aus eurem Register:

(mtls) {
	tls {
		client_auth {
			mode require_and_verify
			trust_pool file /etc/caddy/client-ca.crt
		}
	}
	@gesperrt vars {tls_client_fingerprint} 151a598999f66b8a2bf831977b32d6a273ba945734ce0cf3f330fa1954206d93
	respond @gesperrt "Zertifikat gesperrt" 403
}

Der Wert oben ist ein Beispiel; tragt den Fingerabdruck des verlorenen Geräts aus register.txt ein. Weitere gesperrte Geräte hängt ihr mit Leerzeichen getrennt an dieselbe Zeile, denn vars nimmt mehrere Werte und trifft, sobald einer davon passt. Nach caddy validate und systemctl reload caddy bekommt das gesperrte Gerät auf jedem Dienst, der das Snippet einbindet, einen 403. Alle anderen Geräte arbeiten unverändert weiter.

Zur Schreibweise eine Warnung, weil sie Zeit kostet: Caddy liefert den Fingerabdruck in Kleinbuchstaben ohne Doppelpunkte, OpenSSL dagegen in Grossbuchstaben mit Doppelpunkten. Bei der Seriennummer ist es noch tückischer. OpenSSL zeigt sie hexadezimal an, der Platzhalter {tls_client_serial} lieferte in unserem Test dieselbe Zahl in Dezimalschreibweise. Wer eine Seriennummer aus openssl x509 -serial in die Sperrregel kopiert, sperrt deshalb niemanden. Der Fingerabdruck in der Umformung aus Schritt 2 umgeht dieses Problem. Im Zweifel lasst euch den Wert einmal von Caddy selbst ausgeben, etwa mit einem vorübergehenden respond {tls_client_fingerprint}.

Daneben bleibt die Laufzeit das zuverlässigste Sperrmittel, weil sie ohne euer Zutun wirkt. Den Ablauf behaltet ihr am besten mit einer Erinnerung im Blick, etwa über einen systemd-Timer mit Benachrichtigung, der openssl x509 -checkend über die Zertifikate im Register laufen lässt. Und falls der CA-Schlüssel selbst abhandenkommt, hilft keine Sperrregel mehr: Dann legt ihr eine neue CA an, ersetzt client-ca.crt auf dem Server und stattet alle Geräte neu aus.

Wo mTLS an seine Grenzen kommt

Ein Client-Zertifikat schützt den Weg zum Dienst, nicht den Dienst selbst. Wer ein entsperrtes Gerät in der Hand hält, hat das Zertifikat gleich mit. mTLS ergänzt Passwort und zweiten Faktor, es ersetzt sie nicht.

Ausserdem muss die TLS-Verbindung tatsächlich bei Caddy enden. Steht ein fremder Proxy davor, etwa der Proxy-Modus von Cloudflare mit der orangen Wolke, baut Cloudflare die Verbindung zu euren Geräten auf und Caddy sieht nur noch Cloudflare. Ein Client-Zertifikat eures Laptops kommt dort nie an. Für mTLS muss der Eintrag im DNS direkt auf euren Server zeigen.

Und schliesslich will die Absicherung gepflegt werden: Zertifikate laufen ab, Geräte werden ersetzt, neue Familienmitglieder wollen Zugang. Bei drei Geräten ist das wenig Arbeit, bei zwanzig ist ein VPN oder ein Werkzeug, das die Ausstellung automatisiert, die einfachere Antwort. Spätestens wenn die Tabelle mit den Fingerabdrücken länger ist als die Einkaufsliste, ist dieser Punkt erreicht.

Was ihr vorher festlegen solltet

Die Befehle sind in einer Stunde abgearbeitet. Die folgenden Entscheidungen solltet ihr vorher treffen, weil sie sich später nur mühsam ändern lassen:

• Wo der CA-Schlüssel liegt — und wo seine Kopie liegt. Nicht auf dem Server, nicht unverschlüsselt, nicht nur an einem Ort.
• Wie lange Client-Zertifikate gelten. Kürzer heisst sicherer und mehr Arbeit. Ein Jahr ist ein vernünftiger Anfang; für Geräte, die öfter verloren gehen können, darf es weniger sein.
• Nach welchem Schema ihr die Namen vergebt. person-geraet ist im Protokoll lesbar und beim Sperren auffindbar. test2 ist es nicht.
• Wo das Register liegt. Name, Fingerabdruck und Ablaufdatum jedes ausgestellten Zertifikats, an einem Ort, den ihr auch erreicht, wenn das Gerät weg ist.
• Welche Dienste mit welcher Stufe laufen. Ganzer Dienst mit require_and_verify oder nur ein Pfad mit verify_if_given — und ob die zugehörige App überhaupt Client-Zertifikate kann.
• Wie ihr reinkommt, wenn es klemmt. Eine SSH-Sitzung auf den Server oder ein Weg im lokalen Netz, der nicht über den geschützten Dienst führt.

Fazit: mTLS sperrt Fremde aus, bevor sie das Login überhaupt sehen

Ein selbst gehosteter Dienst im Internet ist so sicher wie das, was vor seinem Login liegt. Bei den meisten Installationen ist das nichts: Jeder Scanner der Welt darf die Anmeldeseite abrufen, Benutzernamen durchprobieren und auf die nächste Lücke in genau diesem Code warten. Mit mTLS endet dieser Versuch im Handshake, noch bevor der Dienst davon erfährt. Caddy braucht dafür sechs Zeilen, OpenSSL eine Handvoll Befehle.

Dass Let's Encrypt die Client-Authentifizierung in diesem Jahr gestrichen hat, wirkt auf den ersten Blick wie ein Verlust und ist in Wahrheit eine Klarstellung. Wer bestimmt, welche Geräte an eure Dienste dürfen, gehört nicht in eine öffentliche Zertifizierungsstelle, sondern in euren Schrank. Der Preis dafür ist Verantwortung: für den CA-Schlüssel, für das Register, für die Ablaufdaten. Wer sie übernimmt, hat das stärkste Schloss, das ein Reverse Proxy zu bieten hat — ohne Cloud und ohne irgendjemandes Erlaubnis.

Quellen und weiterführende Links

• Caddy Documentation — tls, Syntax von client_auth, die vier Modi, Vorgabeverhalten und das Modul trust_pool file
• Caddy Documentation — Global Options, strict_sni_host und seine automatische Aktivierung bei Client-Authentifizierung
• Caddy Documentation — Request Matchers, der Matcher vars mit Platzhaltern und mehreren Werten
• Caddy Documentation — Caddyfile Concepts, Platzhalter {tls_client_*}
• Caddy Documentation — reverse_proxy, Kopfzeilen mit header_up setzen
• GHSA-hffm-g8v7-wrv7 / CVE-2026-27586, Client-Authentifizierung schlägt bei fehlender CA-Datei offen fehl
• Caddy v2.11.1 — Release Notes, Behebung von CVE-2026-27586
• Let's Encrypt — Ending TLS Client Authentication Certificate Support in 2026, Zeitplan und Begründung
• openssl-req(1), -x509, -addext, -subj und -days
• openssl-x509(1), Signieren mit -CA, -CAkey und -extfile, zufällige Seriennummer
• x509v3_config(5), basicConstraints, keyUsage und extendedKeyUsage = clientAuth
• openssl-pkcs12(1), Export als PKCS#12, Standardverschlüsselung und -legacy
• DigiCert — Install client authentication certificate in your browser, Import in Firefox und Windows
• Google Pixel-Hilfe — Zertifikate hinzufügen und entfernen, Pfad zu Verschlüsselung & Anmeldedaten
• MIT Knowledge Base — Installing Certificates on Android, Import als VPN- und App-Nutzerzertifikat

The post mTLS mit Caddy: Dienste nur für eigene Geräte appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Chatkontrolle ist damit endgültig das Gesetz, das nie beschlossen wird und nie verschwindet. Wie die freiwillige Variante im Juli per Verfahrenstrick zurückkam, steht in unserem Beitrag EU beschliesst Chatkontrolle Light im Eilverfahren; die Unterscheidung zwischen Chatkontrolle 1.0 und 2.0 ist dort ebenfalls erklärt. Hier geht es um das, was seither dazugekommen ist, und um die Frage, was am Dienstag entschieden werden soll.

Chatkontrolle-Trilog am 29. September: was feststeht

Ein Trilog ist die informelle Verhandlungsrunde, in der Vertreter der drei EU-Institutionen einen gemeinsamen Gesetzestext aushandeln. Protokolle werden nicht veröffentlicht, die Öffentlichkeit erfährt vom Ergebnis erst, wenn es feststeht. Dass am 29. September verhandelt wird, belegt ein internes Papier der irischen Ratspräsidentschaft an die Mitgliedstaaten: Das Ratsdokument 11956/26 vom 10. September 2026, eingestuft als „LIMITE" und von Agence Europe öffentlich gemacht, kündigt den sechsten Trilog „at the Council premises on 29 September 2026" an.

Patrick Breyer, früherer EU-Abgeordneter der Piraten und derjenige, der den Begriff Chatkontrolle geprägt hat, beschreibt die Lage auf seiner laufend aktualisierten Themenseite so: „Am Dienstag, den 29. September findet ein potenziell letzter und entscheidender Trilog statt." Und weiter: „Die EU-Unterhändler stehen unter massivem Druck, einen ‚faulen Kompromiss' zu schliessen, der verdachtslose Massenscans unserer Chats dauerhaft zementieren würde." Verhandlungsführer der Kommission ist Innenkommissar Magnus Brunner.

Seit Juli wieder erlaubt: die freiwillige Chatkontrolle

Der Juli-Beitrag endete mit dem Hinweis, dass der Rat noch zustimmen muss. Das hat er getan: Am 23. Juli 2026 hat der Rat die Übergangsverordnung wieder in Kraft gesetzt. Anbieter dürfen damit erneut freiwillig nach Darstellungen sexuellen Kindesmissbrauchs suchen, und zwar „until 3 April 2028". Laut EDRi gilt die neue Ausnahme seit dem 31. Juli 2026.

Eine Einschränkung hat das Parlament durchgesetzt, und sie ist die wichtigste: Ende-zu-Ende-verschlüsselte Kommunikation ist ausgenommen. Der Rat zitiert die Änderung wörtlich, ausgeschlossen sind Dienste, „to which end-to-end encryption is, has been or will be applied". EDRi hält fest, dass die beiden Änderungsanträge ausdrücklich auch gegen Client-Side-Scanning schützen. Für die Übergangszeit heisst das: Signal bleibt draussen, unverschlüsselte Direktnachrichten grosser Plattformen nicht.

Das verschiebt die Kräfte im Trilog. Die Übergangslösung, die das Parlament im März abgelehnt hatte, gilt jetzt wieder bis 2028. Breyer hatte schon im Juli gewarnt, dass die Regierungen keinen Anreiz haben, sich auf das Konzept des Parlaments einzulassen, solange ihr Status quo immer wieder verlängert wird. Seit dem 31. Juli liegt dieser Status quo für die nächsten zwanzig Monate fest.

Der Kompromiss der Präsidentschaft: zwei Spuren

Wie die irische Präsidentschaft die Verordnung zuschneiden will, hat Agence Europe am 23. September 2026 beschrieben. Der Vorschlag teilt Inhalte in zwei Gruppen:

• Öffentliche Inhalte — also alles, was ohnehin jeder sehen kann — sollen per Aufdeckungsanordnung durchsucht werden können, allerdings nur nach bereits bekanntem Material, ausdrücklich um eine allgemeine Überwachungspflicht zu vermeiden.
• Private Kommunikation — Chats, Direktnachrichten, private Cloud-Ordner — soll weiter freiwillig durchsucht werden, gestützt auf die Ausnahme von der ePrivacy-Richtlinie. Und zwar nach bekanntem und neuem Material sowie nach Anbahnungsversuchen gegenüber Kindern, dem sogenannten Grooming.

Die Reihenfolge ist bezeichnend: Dort, wo ohnehin alles öffentlich ist, gibt es enge Regeln. Dort, wo es um private Nachrichten geht, gibt es die weiteste Befugnis.

Der Unterschied zwischen bekanntem und neuem Material ist dabei nicht nur juristisch. Bekanntes Material lässt sich mit einer Liste von Prüfwerten bereits identifizierter Aufnahmen abgleichen. Neues Material und Grooming dagegen setzen voraus, dass eine Software private Bilder und Unterhaltungen inhaltlich beurteilt, die sie nie zuvor gesehen hat. Das Parlament verlangt deshalb laut Agence Europe, automatisierte Erkennung auf bekanntes Material zu beschränken und dafür die Indikatoren-Datenbank des geplanten EU-Zentrums zu verwenden.

Suchplan statt Verdacht

Der Kern des Streits ist die Frage, wer eine Durchsuchung auslösen darf und für wie lange. Das Ratsdokument 11956/26 nennt als möglichen Kompromiss die „authorisation of search plans for a period of time rather than on a case-by-case basis" — also die Genehmigung von Suchplänen für einen Zeitraum statt im Einzelfall. Der Antrag eines Anbieters könne dabei „the technologies used and other relevant safeguards" enthalten. Was dem Rat dabei am wichtigsten ist, steht im selben Papier: „the most important aspect for the Council is effective detection and removal of content online as provided for through the voluntary regime".

Pikant ist, dass der Plan auch in der Position des Parlaments vorkommt. Es verlangt laut Agence Europe, dass jede Suche einen Plan mit den eingesetzten Technologien und Schutzvorkehrungen voraussetzt und von einer Justiz- oder unabhängigen Verwaltungsbehörde genehmigt und beaufsichtigt wird. Der Rat übernimmt den Begriff, verschiebt aber den Gegenstand: Durchsucht werden sollen laut Agence Europe „specific parts of a service or individual users". Nicht mehr nur einzelne Nutzer also, sondern wahlweise einzelne Nutzer oder ganze Teile eines Dienstes.

Breyer nennt das auf seiner Seite „Schein-Targeting" und fasst den Vorschlag so zusammen: „Sie wollen Behörden dauerhaft erlauben, auf Antrag eines Anbieters ‚Suchpläne' für ‚Teile eines Dienstes' zu genehmigen." Was ein „Teil eines Dienstes" ist, beantragt der Anbieter; genehmigen muss es die Behörde — nur eben nicht mehr im Einzelfall, sondern für einen Zeitraum. Die Direktnachrichten einer Plattform sind ebenso ein Teil des Dienstes wie ihre Gruppenchats. Ein richterlicher Durchsuchungsbefehl nennt eine Person. Ein Suchplan nennt eine Funktion. Das ist kein Durchsuchungsbefehl für eine Wohnung, sondern eine Dauerbewilligung für das ganze Treppenhaus.

Was sonst noch auf dem Tisch liegt

Das Ratsdokument listet als ergänzende Massnahmen „safety by design, facilitating user flagging, metadata analysis and behaviour patterns and age verification systems". Zwei davon verdienen Aufmerksamkeit. Metadaten und Verhaltensmuster fallen auch dort an, wo Inhalte verschlüsselt sind — ihre Analyse wäre also der Weg, auf dem auch verschlüsselte Dienste wieder in den Blick geraten. Warum Metadaten oft mehr verraten als Inhalte, haben wir in Metadaten bei Messengern ausführlich beschrieben. Und die Altersverifikation, die der Rat laut EDRi für riskante Dienste verpflichtend machen will, ist dieselbe Art Werkzeug, die die Kommission parallel im EU KIDS Act vorsieht. Das Parlament lehnt sie in der CSA-Verordnung ab.

Offen ist, ob die Verschlüsselung in der dauerhaften Verordnung so geschützt bleibt wie in der Übergangslösung. Laut netzpolitik.org galt der Ausschluss verschlüsselter Inhalte im Juni nur als „vorläufig" vereinbart. Ob das nach dem Dienstag noch gilt, steht in keinem öffentlich bekannten Dokument.

Was ihr bis Dienstag tun könnt

Ein Trilog ist nicht öffentlich, aber die Verhandler des Parlaments sind gewählt und erreichbar. Viel Zeit bleibt nicht:

• Schreibt euren EU-Abgeordneten, oder ruft an. Das Werkzeug auf fightchatcontrol.eu hilft dabei, die eigenen Abgeordneten zu kontaktieren, und verfolgt die Positionen der Mitgliedstaaten. Betrieben wird es nach eigener Angabe von einem dänischen Softwareentwickler ohne Parteibindung, der keine Spenden annimmt.
• Nennt drei konkrete Punkte, wie Breyer sie formuliert: Das Parlament soll bei seinem Mandat bleiben — Anordnungen nur gegen konkret Verdächtige —, pauschale Suchpläne ablehnen und keine Schlupflöcher für freiwillige Massenscans zulassen.
• Setzt bei den grossen Fraktionen an. Breyer empfiehlt, vor allem Abgeordnete der konservativen EVP und der Sozialdemokraten anzusprechen, weil an ihnen das Ergebnis hängt.
• Lest in der Schweiz mit. Die Schweiz verhandelt nicht mit, eure Abgeordneten sitzen nicht in Strassburg. Die Dienste, um die es geht, sind aber dieselben, die ihr benutzt — teilt die Information mit Bekannten in der EU.
• Schützt eure eigene Kommunikation, unabhängig vom Ausgang: Ende-zu-Ende-verschlüsselte Messenger sind von der freiwilligen Chatkontrolle ausgenommen. Welche sich eignen, steht in unserem Juli-Beitrag.

Fazit: Ein Suchplan ist kein Verdacht

Die Chatkontrolle 2.0 kommt nicht mehr als Scanpflicht für alle zurück, sondern in Einzelteilen: freiwilliges Scannen, das bis 2028 bereits gilt, Suchpläne, die ganze Teile eines Dienstes umfassen dürfen, Metadatenanalyse für das, was verschlüsselt bleibt, und eine Altersprüfung für Dienste, die als riskant gelten. Jedes Einzelteil lässt sich als massvoll verkaufen. Zusammen ergeben sie das, was das Parlament seit 2023 ablehnt: die Durchsuchung privater Kommunikation ohne konkreten Verdacht.

Der Unterschied zwischen dem Parlament und dem Rat lässt sich deshalb auf eine einzige Frage zurückführen, die am Dienstag beantwortet werden soll: Beginnt eine Durchsuchung bei einem Menschen, gegen den etwas vorliegt, oder bei einem Dienst, auf dem viele Menschen sind? Alles andere ist Verpackung. Dass diese Frage hinter verschlossenen Türen entschieden wird, gehört leider zur Tradition des Verfahrens — ebenso wie der Umstand, dass die Öffentlichkeit vom Ergebnis voraussichtlich aus einem geleakten Dokument erfährt.

Quellen und weiterführende Links

• Rat der EU: Dokument 11956/26 (LIMITE), 10.09.2026, via Agence Europe — Stand der Verhandlungen, sechster Trilog am 29.09.2026, Suchpläne für einen Zeitraum, ergänzende Massnahmen
• Agence Europe, 23.09.2026: Irish Presidency seeks to refine approach between public and private content — die zwei Spuren, die Positionen von Rat und Parlament
• Patrick Breyer: Chatkontrolle — laufend aktualisierte Themenseite mit Termin, Einschätzung „Schein-Targeting" und Handlungsaufruf
• Rat der EU, 23.07.2026: Interim measure now reinstated — Wiederinkraftsetzung der Übergangsverordnung bis 03.04.2028, Ausschluss verschlüsselter Kommunikation
• EDRi, 04.08.2026: The Chat Control 1.0 saga — Geltung ab 31.07.2026, Schutz auch gegen Client-Side-Scanning
• EDRi, 25.02.2026: Chat Control is in the final stretch — Positionen von Rat und Parlament zu Scanpflicht, Verschlüsselung und Altersverifikation
• netzpolitik.org, 12.06.2026: Trilog zur Chatkontrolle geht in entscheidende Phase — interne Dokumente, vorläufiger Ausschluss verschlüsselter Inhalte
• Fight Chat Control — Werkzeug zum Kontaktieren der EU-Abgeordneten

The post Chatkontrolle-Trilog: Suchplan statt Verdacht appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der Unterschied zu einem gewöhnlichen Proxy liegt in der Richtung. Ein normaler Proxy steht vor euch und schützt euch gegenüber dem Server. Ein Reverse Proxy steht vor den Servern und nimmt ihnen die Aussenwelt ab. Für den Browser existiert nur eine einzige Adresse, ein einziges Zertifikat, ein einziger Einstiegspunkt. Was dahinter läuft, auf welchem Port, in welchem Container, auf welchem Rechner im lokalen Netz — davon bekommt der Client nichts mit.

Der naheliegende Gegenvorschlag lautet: einfach jedem Dienst einen eigenen Port geben und die Sache über example.ch:8080 ansprechen. Das funktioniert, bis ihr das erste Mal aus einem fremden WLAN, einem Firmennetz oder einem Hotelnetzwerk zugreifen wollt. Dort ist alles ausser 80 und 443 üblicherweise dicht. Dazu kommt, dass jedes dieser Ziele ein eigenes gültiges Zertifikat braucht und jeder Dienst seine TLS-Konfiguration selbst pflegen müsste — mit dem Ergebnis, dass drei Programme drei verschiedene Meinungen darüber haben, welche Cipher noch in Ordnung sind.

Genau an dieser Stelle setzt dieser Artikel an: eine vollständige Einrichtung von Caddy als Reverse Proxy unter Debian und Ubuntu, von der Installation über die erste Caddyfile bis zu Wildcard-Zertifikaten per DNS-Challenge. Wer bisher mit Apache und Certbot gearbeitet hat, findet den vertrauten Weg in unserer Anleitung zum SSL-Zertifikat für den Nextcloud-Homeserver. Hier geht es um den Weg, bei dem dieser Schritt schlicht entfällt.

Warum Caddy und nicht nginx

Caddy ist ein in Go geschriebener Webserver, der unter der Apache-2.0-Lizenz steht und ohne externe Abhängigkeiten auskommt. Die aktuelle stabile Version ist v2.11.4 vom 3. Juni 2026. Das Alleinstellungsmerkmal steht im Untertitel des Projekts und ist keine Marketingfloskel: automatisches HTTPS, und zwar als Standardverhalten, nicht als Zusatzpaket.

Automatisches HTTPS ist eingebaut, nicht angeflanscht

Bei nginx oder Apache läuft die Zertifikatsbeschaffung über ein zweites Programm. Certbot legt Dateien ab, schreibt in die Konfiguration hinein, richtet einen Timer ein und startet den Webserver neu. Vier bewegliche Teile, die alle einzeln kaputtgehen können. Caddy spricht ACME selbst. Es erkennt aus der Konfiguration, für welche Hostnamen es Zertifikate braucht, holt sie, erneuert sie und leitet HTTP auf HTTPS um — ohne dass ihr das irgendwo hinschreibt.

Wie gross der Unterschied im Alltag ist, zeigt das Projekt Immich selbst. In der offiziellen Reverse-Proxy-Dokumentation steht eine nginx-Konfiguration mit erhöhtem Upload-Limit, abgeschaltetem Request-Buffering, gesetzten Weiterleitungs-Headern und Timeouts von 600 Sekunden. Direkt darunter steht die Caddy-Variante, vollständig:

immich.example.org {
    reverse_proxy http://127.0.0.1:2283
}

Das ist kein verkürztes Beispiel. Die drei Dinge, die nginx dort von Hand braucht, sind in Caddy Standard. Das Upload-Limit: nginx begrenzt den Request-Body per Vorgabe auf 1 MB und antwortet darüber mit einem 413, was bei Foto- und Video-Uploads sofort auffällt. Caddy kennt kein solches Vorgabelimit, die Direktive request_body müsst ihr setzen, wenn ihr begrenzen wollt. Die Weiterleitungs-Header: Caddy setzt X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Host von sich aus und verwirft eingehende Werte dieser Felder, damit sie nicht gefälscht werden können. Und WebSockets laufen einfach durch, ohne die aus nginx bekannte Upgrade-Klausel.

Wo Caddy nginx nicht ersetzt

Ehrlichkeitshalber gehört die Gegenrichtung dazu. nginx hat ein deutlich grösseres Ökosystem an Modulen, mehr Feinsteuerung beim Caching und mehr Personen, die sich damit auskennen. Wer bereits eine gewachsene, funktionierende nginx-Konfiguration hat, gewinnt durch einen Wechsel wenig. Und Caddy hat eine architektonische Eigenheit, die überrascht: Erweiterungen sind einkompilierte Go-Module. Ein Plugin nachzurüsten bedeutet, das Binary neu zu bauen. Dafür gibt es einen bequemen Befehl, aber es bleibt ein anderes Modell als eine nachinstallierte .so-Datei — mit einer Nebenwirkung, auf die wir weiter unten zurückkommen.

Voraussetzungen für den Reverse Proxy

Vier Dinge müssen stimmen, bevor die erste Zeile Konfiguration Sinn ergibt.

• Ein Server mit Debian 12/13 oder Ubuntu 24.04 und Root- beziehungsweise sudo-Rechten. Ein Raspberry Pi reicht für den Heimgebrauch vollkommen aus, der Proxy selbst ist genügsam.
• Eine Domain, deren DNS-Einträge auf eure öffentliche IP zeigen. Bei wechselnder IP am Hausanschluss braucht es dafür einen dynamischen Eintrag, wie in unserer Anleitung zum DynDNS-Eintrag bei dynamischer IP beschrieben. Für jeden Dienst legt ihr eine eigene Subdomain an.
• Die Ports 80 und 443 müssen von aussen auf den Proxy zeigen. Wie das am Schweizer Router eingerichtet wird, steht in unserem Beitrag zur Portweiterleitung auf Swisscom- und UPC-Modems. Hängt ihr an einem DS-Lite-Anschluss ohne öffentliche IPv4-Adresse, hilft keine Weiterleitung — dann führt der Weg über einen VPS als Brücke, wie in Webdienste hinter DS-Lite verfügbar machen mit Wireguard gezeigt.
• Die Dienste laufen bereits und lauschen lokal. Ob nativ installiert oder über Docker, spielt keine Rolle. Wichtig ist, dass sie auf 127.0.0.1 gebunden sind und nicht auf 0.0.0.0 — sonst ist der Proxy umgehbar.

Läuft auf dem Rechner bereits ein Apache oder nginx auf Port 80 und 443, stoppt und deaktiviert ihn vorher. Zwei Programme auf demselben Port ergeben beim Start nur eine Fehlermeldung.

Caddy unter Debian und Ubuntu installieren

Die Distributionspakete hinken der Entwicklung meist hinterher. Nehmt deshalb das offizielle Repository des Projekts:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Das Paket bringt eine systemd-Unit mit und startet den Dienst sofort. Prüft danach die Version:

caddy version
systemctl status caddy

Ruft ihr jetzt die IP des Servers im Browser auf, begrüsst euch eine Startseite. Der Dienst läuft unter dem Benutzer caddy, die Konfiguration liegt in /etc/caddy/Caddyfile, und die Zertifikate landen später unter /var/lib/caddy/.local/share/caddy. Diese drei Pfade solltet ihr euch merken, sie beantworten später die meisten Fragen.

Die erste Caddyfile: ein Dienst, ein Zertifikat

Öffnet /etc/caddy/Caddyfile, löscht den mitgelieferten Inhalt und schreibt stattdessen:

{
	email admin@example.ch
}

cloud.example.ch {
	reverse_proxy 127.0.0.1:8080
}

Das war die vollständige Konfiguration für einen Dienst mit gültigem Zertifikat und automatischer Weiterleitung von HTTP auf HTTPS. Der geschweifte Block ganz oben ist der globale Optionsblock. Er muss der erste Block der Datei sein und darf nur einmal vorkommen. Die Adresse unter email wird für das ACME-Konto verwendet; darüber informiert euch die Zertifizierungsstelle, wenn eine Erneuerung dauerhaft scheitert. Der zweite Block ist ein Site-Block: alles zwischen den Klammern gilt für Anfragen an diesen Hostnamen.

Formatiert und prüft die Datei, bevor ihr sie aktiviert:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Ein Hinweis zur Einrückung: Die Caddyfile erwartet Tabulatoren, keine Leerzeichen. caddy fmt --overwrite räumt das für euch auf, weshalb dieser Befehl der erste von dreien ist. Alle Unterbefehle sind dokumentiert, im Alltag braucht ihr vor allem diese drei.

Was beim ersten Neuladen tatsächlich passiert

Caddy liest aus dem Site-Block heraus, dass es ein Zertifikat für cloud.example.ch braucht, und beginnt sofort damit. Primäre Zertifizierungsstelle ist Let's Encrypt, bei Fehlern weicht Caddy automatisch auf ZeroSSL aus. Zur Validierung stehen die HTTP-Challenge über Port 80 und die TLS-ALPN-Challenge über Port 443 bereit; Caddy wählt zunächst zufällig und merkt sich, welcher Weg bei euch verlässlich funktioniert. Nach wenigen Sekunden ist das Zertifikat da und der Dienst über HTTPS erreichbar.

Zusehen könnt ihr dabei im Journal:

journalctl -u caddy -f

Und hier lauert die erste ernsthafte Falle. Solange die DNS-Einträge noch nicht stimmen oder die Portweiterleitung fehlt, scheitert die Validierung — und Let's Encrypt zählt mit. Nach den offiziellen Rate Limits sind pro Bezeichner und Konto fünf fehlgeschlagene Autorisierungen pro Stunde erlaubt, pro registrierter Domain 50 Zertifikate in sieben Tagen und für einen exakt gleichen Satz von Bezeichnern fünf Zertifikate in sieben Tagen. Wer eine Konfiguration in Ruhe durchprobieren will, schaltet deshalb vorher auf die Testumgebung um:

{
	email admin@example.ch
	acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

Die Zertifikate der Testumgebung sind im Browser ungültig, das ist beabsichtigt. Wenn alles steht, nehmt ihr die Zeile wieder heraus und ladet neu. Praktisch heisst das: erst mit Staging bauen, dann scharf schalten. Wer diese zwei Minuten überspringt, sitzt im schlechtesten Fall eine Woche auf einem gesperrten Bezeichner.

Drei Dienste hinter einer Adresse

Der eigentliche Gewinn zeigt sich erst ab dem zweiten Dienst. Jeder bekommt seinen eigenen Site-Block, jeder sein eigenes Zertifikat, alle teilen sich denselben Port:

{
	email admin@example.ch
}

cloud.example.ch {
	reverse_proxy 127.0.0.1:8080
}

vault.example.ch {
	reverse_proxy 127.0.0.1:8000
}

fotos.example.ch {
	reverse_proxy 127.0.0.1:2283
}

Die Ports sind die Vorgaben der jeweiligen Projekte: 8000 für Vaultwarden, 2283 für Immich, 8080 für einen Nextcloud-Container hinter dem Proxy. Bemerkenswert ist vor allem, was hier nicht steht. Keine Upload-Grenze für Immich. Keine WebSocket-Klausel für Vaultwarden, dessen eigenes Caddy-Beispiel im Projekt-Wiki ebenfalls mit einer einzigen reverse_proxy-Zeile auskommt. Keine Zertifikatspfade, keine Cipher-Listen, kein Redirect-Block.

Liegt ein Dienst auf einem anderen Rechner im lokalen Netz, tragt ihr dort statt 127.0.0.1 dessen IP ein. Und wenn das Backend selbst schon HTTPS spricht, etwa mit einem selbstsignierten Zertifikat, sieht das so aus:

nas.example.ch {
	reverse_proxy https://192.168.1.50:5001 {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

Das Überspringen der Zertifikatsprüfung ist hier vertretbar, weil die Strecke im eigenen Netz liegt und die Verschlüsselung nach aussen der Proxy übernimmt. Auf einer Verbindung über das Internet wäre es ein Fehler.

Nextcloud hinter dem Reverse Proxy richtig konfigurieren

Nextcloud ist der Dienst, bei dem am häufigsten etwas schiefgeht — nicht wegen Caddy, sondern weil Nextcloud sich selbst hinter einem Proxy falsch einschätzt. Es sieht eine unverschlüsselte Anfrage von 127.0.0.1 und baut daraus Links mit http://. Ergebnis: Anmeldeschleifen, kaputte Vorschaubilder, und im Log steht bei jedem Zugriff dieselbe IP-Adresse. Ergänzt deshalb in config/config.php:

'trusted_domains' => [
  'cloud.example.ch',
],
'trusted_proxies' => ['127.0.0.1'],
'forwarded_for_headers' => ['HTTP_X_FORWARDED_FOR'],
'overwriteprotocol' => 'https',
'overwritehost' => 'cloud.example.ch',
'overwrite.cli.url' => 'https://cloud.example.ch',

Die Bedeutung der Werte steht in der kommentierten Beispielkonfiguration im Nextcloud-Repository. trusted_proxies erlaubt Nextcloud, den weitergereichten Client-IPs überhaupt zu glauben, forwarded_for_headers legt fest, welchem Header dabei vertraut wird, und die drei overwrite-Werte korrigieren die Selbsteinschätzung bei der URL-Erzeugung. Läuft Nextcloud in einem Container, gehört unter trusted_proxies nicht 127.0.0.1, sondern die Adresse des Docker-Netzes.

Sicherheitskopfzeilen an einer Stelle statt in jedem Dienst

Der zweite grosse Vorteil eines zentralen Einstiegspunkts: Kopfzeilen, die für alle Dienste gelten sollen, schreibt ihr genau einmal. Caddy kennt dafür wiederverwendbare Bausteine, sogenannte Snippets, die in runden Klammern definiert und mit import eingebunden werden:

{
	header {
		Strict-Transport-Security "max-age=31536000"
		X-Content-Type-Options "nosniff"
		X-Frame-Options "SAMEORIGIN"
		Referrer-Policy "no-referrer"
		-Server
	}
}

cloud.example.ch {
	import sicherheit
	reverse_proxy 127.0.0.1:8080
}

vault.example.ch {
	import sicherheit
	reverse_proxy 127.0.0.1:8000
}

Das führende Minus vor Server löscht die Kopfzeile aus der Antwort. Bei Strict-Transport-Security ist Vorsicht angebracht: Die Anweisung sagt jedem Browser, diese Domain für die angegebene Dauer ausschliesslich über HTTPS anzusprechen — hier ein Jahr. Das ist erwünscht, aber es lässt sich nicht kurzfristig zurücknehmen. Nehmt die Zusätze includeSubDomains und preload erst dazu, wenn wirklich jede Subdomain dauerhaft per HTTPS erreichbar ist.

Zertifikate ohne offene Ports: die DNS-Challenge

HTTP- und TLS-ALPN-Challenge setzen voraus, dass die Zertifizierungsstelle euren Server von aussen erreicht. Das ist nicht immer der Fall: an einem DS-Lite-Anschluss fehlt die öffentliche IPv4-Adresse, manche Provider sperren Port 80, und für Dienste, die absichtlich nur im VPN erreichbar sind, gibt es gar keinen Weg von aussen. Ausserdem lassen sich Wildcard-Zertifikate ausschliesslich per DNS ausstellen.

Die DNS-Challenge dreht die Beweisrichtung um: Statt einer Datei auf eurem Server legt Caddy einen TXT-Eintrag in eurer DNS-Zone an. Damit braucht es keinen einzigen offenen Port — aber Schreibzugriff auf die Zone.

Plugin nachrüsten mit caddy add-package

Für jeden DNS-Anbieter gibt es ein eigenes Modul, und weil Caddy-Erweiterungen einkompiliert werden, braucht es ein neues Binary. Der eingebaute Befehl erledigt das:

sudo caddy add-package github.com/caddy-dns/cloudflare
caddy list-modules --packages | grep cloudflare
sudo systemctl restart caddy

Und damit zur angekündigten Nebenwirkung: caddy add-package ersetzt das vom Paketmanager installierte Binary. Beim nächsten apt upgrade überschreibt apt es wieder mit der Standardversion — das Plugin ist weg, die Caddyfile verweist auf ein Modul, das es nicht mehr gibt, und der Dienst startet nicht. Wer das vermeiden will, führt add-package nach jedem Upgrade erneut aus oder aktualisiert stattdessen mit caddy upgrade, das die installierten Module beibehält. Notiert euch die Zeile mit euren Paketen an einer Stelle, an der ihr sie wiederfindet.

Den API-Token sauber übergeben

Der Token gehört nicht in die Caddyfile, sondern in die Umgebung des Dienstes. Bei Cloudflare braucht er laut Modul-Dokumentation genau zwei Berechtigungen: Zone.Zone:Read und Zone.DNS:Edit, beschränkt auf die betroffenen Zonen. Legt ein systemd-Override an:

sudo systemctl edit caddy

Und tragt dort ein:

[Service]
Environment="CF_API_TOKEN=euer_token_hier"

In der Caddyfile wird der Wert dann als Platzhalter referenziert:

intern.example.ch {
	tls {
		dns cloudflare {env.CF_API_TOKEN}
	}
	reverse_proxy 127.0.0.1:3000
}

Die ältere Schreibweise mit getrennten zone_token- und api_token-Feldern taucht in vielen Anleitungen im Netz noch auf. Das Modul bezeichnet sie ausdrücklich als veraltet und behält sie nur aus Kompatibilitätsgründen — nehmt die einzeilige Variante.

Wildcard-Zertifikate

Steht die DNS-Challenge, könnt ihr ein einziges Zertifikat für alle Subdomains ausstellen lassen. Das reduziert die Zahl der ACME-Anfragen erheblich und hält euch von den Rate Limits fern:

*.example.ch {
	tls {
		dns cloudflare {env.CF_API_TOKEN}
	}

	@cloud host cloud.example.ch
	handle @cloud {
		reverse_proxy 127.0.0.1:8080
	}

	@vault host vault.example.ch
	handle @vault {
		reverse_proxy 127.0.0.1:8000
	}

	handle {
		abort
	}
}

Die mit @ beginnenden Ausdrücke sind Matcher, die den passenden Hostnamen herausgreifen. Der letzte handle-Block ohne Matcher fängt alles ab, was zu keinem Dienst gehört, und bricht die Verbindung ab — sonst würde jede erfundene Subdomain irgendwo landen. Beachtet dabei, dass ein Wildcard-Zertifikat nur eine Ebene abdeckt: *.example.ch gilt für cloud.example.ch, aber nicht für a.b.example.ch.

Betrieb: prüfen, neu laden, Logs lesen

Im laufenden Betrieb sind es vor allem drei Handgriffe. Nach jeder Änderung an der Caddyfile gilt dieselbe Reihenfolge wie oben: formatieren, validieren, neu laden. systemctl reload caddy übernimmt die neue Konfiguration ohne Verbindungsabbruch — ein restart ist nur nötig, wenn ihr das Binary getauscht oder die systemd-Unit geändert habt.

Standardmässig landet alles im Journal. Für einen einzelnen Dienst lohnt sich ein eigenes Zugriffsprotokoll, etwa um es später an CrowdSec zu übergeben:

cloud.example.ch {
	log {
		output file /var/log/caddy/cloud.log {
			roll_size 10MiB
			roll_keep 5
		}
	}
	reverse_proxy 127.0.0.1:8080
}

Das Verzeichnis muss dem Benutzer caddy gehören. Und ein Punkt, der gern vergessen wird: In eure Sicherung gehört nicht nur /etc/caddy, sondern auch /var/lib/caddy/.local/share/caddy. Dort liegen die Zertifikate, die privaten Schlüssel und der ACME-Kontoschlüssel. Ohne dieses Verzeichnis holt ein neu aufgesetzter Server zwar alle Zertifikate neu — aber jeder solche Durchlauf zählt auf die Rate Limits.

Stolperfallen, die euch einen Abend kosten

• Port 80 zugemacht. Viele schliessen ihn, weil ohnehin alles über HTTPS läuft. Dann fehlt die Weiterleitung für Besucher, die ohne Präfix tippen, und die HTTP-Challenge fällt als Ausweichweg weg. Lasst ihn offen, ausser ihr nutzt ausschliesslich die DNS-Challenge.
• Alter Webserver läuft noch. Ein address already in use im Journal bedeutet fast immer einen vergessenen Apache oder nginx.
• Dienst lauscht auf 0.0.0.0. Dann ist er direkt über seinen Port erreichbar, unverschlüsselt und ohne die gesetzten Kopfzeilen. Bindet Backends an 127.0.0.1 und blockt die Ports zusätzlich in der Firewall.
• Cloudflare-Proxy davor. Steht in eurem DNS die orange Wolke, terminiert Cloudflare TLS selbst und die TLS-ALPN-Challenge scheitert zwangsläufig. Dann führt der Weg über die DNS-Challenge.
• Konfiguration nicht validiert. systemctl reload mit einer fehlerhaften Datei lässt die alte Konfiguration aktiv und meldet den Fehler nur im Journal. Wer nicht hinsieht, wundert sich, warum die Änderung nichts bewirkt.
• Leerzeichen statt Tabulatoren. Erzeugt Fehlermeldungen, die auf den ersten Blick nichts mit Einrückung zu tun haben. caddy fmt --overwrite zuerst.

Was ihr tun könnt

• Legt für jeden Dienst eine eigene Subdomain an, statt Ports nach aussen zu öffnen. Das kostet nichts und ist die Grundlage für alles Weitere.
• Baut die erste Konfiguration gegen den Staging-Endpunkt von Let's Encrypt. Zwei zusätzliche Minuten, die euch im Fehlerfall eine Woche Wartezeit ersparen.
• Bindet alle Backends auf 127.0.0.1 und prüft mit ss -tlnp, ob sich noch etwas an einer öffentlichen Adresse festhält.
• Zieht die Sicherheitskopfzeilen in ein Snippet und importiert es in jeden Site-Block, statt sie in jedem Dienst einzeln zu pflegen.
• Nehmt /var/lib/caddy/.local/share/caddy in die Sicherung auf.
• Wenn ihr Plugins nachrüstet: haltet die add-package-Zeile fest und prüft nach jedem Systemupdate mit caddy list-modules --packages, ob sie noch da sind.

Fazit: Caddy macht TLS zur Standardeinstellung statt zur Bastelaufgabe

Die verbreitete Kombination aus nginx und Certbot funktioniert seit Jahren zuverlässig, und niemand muss sie ersetzen. Aber sie besteht aus vier Teilen, die zusammenarbeiten müssen: Webserver, ACME-Client, Timer und Konfigurationsdateien, die zwei Programme gleichzeitig bearbeiten. Jeder dieser Teile hat schon einmal jemandem ein abgelaufenes Zertifikat beschert.

Caddy schneidet diese Kette auf ein Teil zusammen. Sechs Zeilen Konfiguration reichen für einen Dienst mit gültigem Zertifikat, automatischer Erneuerung, HTTP-Weiterleitung, HTTP/2, HTTP/3 und funktionierenden WebSockets. Dass Immich in der eigenen Dokumentation eine halbe Seite nginx neben drei Zeilen Caddy stellt, ist keine Werbung des Caddy-Projekts, sondern die Einschätzung eines unbeteiligten Dritten.

Der Preis dafür sind weniger Stellschrauben und ein Erweiterungsmodell, das bei jedem Systemupdate Aufmerksamkeit verlangt. Für die überwiegende Mehrheit selbst gehosteter Installationen ist das ein guter Handel. Verschlüsselung sollte der unauffällige Normalzustand sein und nicht die Aufgabe, die dreimal im Jahr um drei Uhr morgens Alarm schlägt — und genau daran gemessen ist Caddy für Selfhoster derzeit die vernünftigste Wahl.

Quellen und weiterführende Links

• Caddy Documentation — Install, offizielle Installationswege inklusive apt-Repository
• Caddy Documentation — Automatic HTTPS, Ablauf der Zertifikatsbeschaffung und Challenge-Auswahl
• Caddy Documentation — reverse_proxy, Syntax, gesetzte Header, Transport und Lastverteilung
• Caddy Documentation — tls, DNS-Challenge, Propagation und alternative Zertifizierungsstellen
• Caddy Documentation — Global Options, globaler Optionsblock mit email und acme_ca
• Caddy Documentation — Command Line, validate, fmt, reload, add-package und upgrade
• Caddy Documentation — Keeping Caddy Running, systemd-Dienst, Benutzer und Datenverzeichnisse
• Caddy Documentation — request_body, Begrenzung der Anfragegrösse
• caddyserver/caddy — Releases, Versionsstand v2.11.4 vom 3. Juni 2026
• caddy-dns/cloudflare, Konfigurationssyntax und benötigte Token-Berechtigungen
• Let's Encrypt — Rate Limits, verbindliche Grenzwerte für Ausstellung und Fehlversuche
• nginx — client_max_body_size, Vorgabewert 1 MB und Verhalten bei Überschreitung
• Immich — Reverse Proxy, Vergleich der nginx- und Caddy-Konfiguration
• Vaultwarden Wiki — Proxy examples, Caddy-Beispiel des Projekts
• Nextcloud — config.sample.php, kommentierte Referenz zu trusted_proxies und den overwrite-Werten

The post Caddy Reverse Proxy einrichten: HTTPS ohne Certbot appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Wie funktioniert LUKS?

• Es verschlüsselt ganze Partitionen oder Laufwerke, anstatt nur einzelne Dateien.
• Es verwendet starke kryptografische Algorithmen (z. B. AES-256).
• Es ermöglicht die Speicherung mehrerer Schlüssel für den Zugriff auf die verschlüsselte Partition.
• Es ist mit verschiedenen Authentifizierungsmethoden kompatibel, z. B. Passwörter oder Smartcards.

LUKS2 vs. LUKS1

• LUKS1 ist der ältere Standard, der weit verbreitet und mit vielen Systemen kompatibel ist.
• LUKS2 ist die neuere Version mit Verbesserungen wie flexiblerem Header-Management und besserer Widerstandsfähigkeit gegen Angriffe auf die Metadaten.

Wann ist eine Verschlüsselung mit LUKS sinnvoll?

Die Verschlüsselung eines Linux-Systems mit LUKS ist in verschiedenen Szenarien sinnvoll, vor allem in den folgenden Fällen:

1. Schutz sensibler Daten

Wenn ihr persönliche oder geschäftliche Daten auf eurem Laptop oder PC speichert, schützt LUKS vor unbefugtem Zugriff, falls das Gerät verloren geht oder gestohlen wird.

2. Sicherheit bei mobilen Geräten (Laptops, USB-Sticks, externe Festplatten)

Laptops und externe Speichergeräte sind besonders anfällig für Diebstahl oder Verlust. Eine LUKS-Verschlüsselung stellt sicher, dass niemand ohne das richtige Passwort auf die Daten zugreifen kann.

3. Datenschutz und DSGVO-Konformität

Unternehmen oder Selbstständige, die personenbezogene Daten speichern, müssen Maßnahmen ergreifen, um unbefugten Zugriff zu verhindern. LUKS hilft, Datenschutzrichtlinien (z. B. die EU-DSGVO) einzuhalten.

4. Schutz gegen physische Angriffe

Wenn ein Angreifer physischen Zugriff auf eine unverschlüsselte Festplatte hat, kann er Daten extrahieren oder ein Rootkit installieren. Mit LUKS ist das Auslesen der Festplatte ohne das richtige Passwort unmöglich.

5. Cloud- und Server-Sicherheit

Falls ihr einen Server betreibt und euch vor unautorisiertem Zugriff auf die Festplatte absichern möchtest (z. B. wenn euer dedizierter Server in einem Rechenzentrum steht), kann eine Verschlüsselung sinnvoll sein.

6. Multi-User-Systeme

Wenn mehrere Benutzer auf ein System zugreifen, bietet LUKS eine zusätzliche Sicherheitsebene, indem es die gesamte Festplatte vor unautorisiertem Zugriff schützt.

Wann ist eine Verschlüsselung weniger sinnvoll?

Obwohl LUKS eine starke Sicherheitsmaßnahme ist, gibt es Fälle, in denen eine Verschlüsselung nicht unbedingt notwendig ist:

1. Wenn das System nur lokal und ohne sensible Daten genutzt wird
   – Beispielsweise ein Heimserver, der ohnehin nur in einem sicheren Netzwerk läuft.
2. Leistungseinbußen bei älteren Systemen
   – Verschlüsselung benötigt Rechenleistung, insbesondere auf älteren Geräten ohne AES-NI-Unterstützung (Hardware-Beschleunigung für Verschlüsselung).
3. Wenn ein System rund um die Uhr ohne manuelle Eingabe startet
   – Bei Headless-Servern kann eine Verschlüsselung unpraktisch sein, wenn beim Booten ein Passwort eingegeben werden muss.
4. Wenn bereits andere Sicherheitsmaßnahmen ausreichen
   – Beispielsweise, wenn das System bereits in einem sicheren, abgeschotteten Netzwerk betrieben wird.

Home Ordner oder ganze Platte verschlüsseln

Bei vielen Linux-Distributionen könnt ihr während der Installation entscheiden, ob ihr die gesamte Platte oder nur den Home-Ordner verschlüsseln möchtet. Beide Optionen haben Vor- und Nachteile, je nach euren Anforderungen. Hier sind die wesentlichen Unterschiede:

Ganze Festplatte verschlüsseln (Full Disk Encryption, FDE mit LUKS)

Wie funktioniert es?

• Der Bootloader (z. B. GRUB) bleibt unverschlüsselt, aber alles andere auf der Platte ist geschützt. KDE Neon bildet hier eine Ausnahme, den Neon verschlüsselt auch die Bootloader Partition mit.
• Die gesamte Partition (einschließlich /home, /root, /var, /tmp, /swap) wird mit LUKS verschlüsselt.
• Beim Systemstart wird das Passwort abgefragt, um die Festplatte zu entschlüsseln.

Vorteile

✅ Maximaler Schutz

• Alles außer dem Bootloader ist verschlüsselt, also auch Systemdateien, Logs, Swap und temporäre Dateien.
• Falls ein Angreifer das System stiehlt, kommt er ohne Passwort an gar keine Daten heran.

✅ Schutz vor Cold-Boot-Attacken

• Bei einem erzwungenen Neustart verliert das System den entschlüsselten Speicherzustand, wodurch Angriffe erschwert werden.

✅ Einfache Verwaltung

• Da die gesamte Festplatte verschlüsselt ist, muss man sich keine Gedanken über einzelne Verzeichnisse oder Swap-Partitionen machen.

Nachteile

❌ Boot-Passwort erforderlich

• Vor dem Start des Betriebssystems muss das LUKS-Passwort eingegeben werden. Das kann bei einem Remote-Server ohne KVM oder TPM unpraktisch sein.

❌ Komplexere Einrichtung für Multi-User-Systeme

• Alle Nutzer teilen die gleiche Entschlüsselung, was bedeutet, dass jeder mit Zugriff auf das System grundsätzlich an alles herankommen könnte, wenn das System läuft.

❌ Kein Schutz bei laufendem System

• Ist das System einmal entschlüsselt und läuft, sind die Daten für einen eingeloggten Angreifer zugänglich.

Nur den Home-Ordner verschlüsseln (z. B. mit eCryptfs)

Wie funktioniert es?

• Statt der ganzen Festplatte wird nur /home verschlüsselt.
• Die Entschlüsselung erfolgt automatisch, sobald sich der Benutzer anmeldet.
• eCryptfs ist oft das Standardverfahren für Home-Verschlüsselung, aber neuere Distributionen wie Ubuntu setzen inzwischen auf fscrypt.

Vorteile

✅ Einfach zu benutzen

• Kein Passwort beim Booten nötig, da die Entschlüsselung mit der Benutzeranmeldung geschieht.

✅ Feingranulare Kontrolle

• Jeder Benutzer hat seinen eigenen verschlüsselten Bereich. Andere User auf dem gleichen System haben keinen Zugriff auf fremde Home-Verzeichnisse.

✅ Kein Performance-Verlust für Systemdateien

• Nur der Home-Ordner wird verschlüsselt, was weniger CPU-Overhead bedeutet als eine komplette Festplattenverschlüsselung.

Nachteile

❌ System bleibt unverschlüsselt

• Alles außerhalb des Home-Verzeichnisses bleibt unverschlüsselt, z. B. /tmp, Logs in /var/log, Swap-Partition (falls nicht speziell konfiguriert).
• Sensible Daten, die von Programmen außerhalb von /home gespeichert werden (z. B. Browser-Caches), könnten ungeschützt sein.

❌ Angreifbar bei physischem Zugriff

• Falls ein Angreifer vollen Zugriff auf das System hat, kann er Spuren in unverschlüsselten Bereichen (z. B. Swap oder Logs) nutzen, um Rückschlüsse auf die verschlüsselten Daten zu ziehen.

❌ Multi-User-Komplexität

• Falls mehrere Benutzer mit verschiedenen Passwörtern arbeiten, muss jeder Benutzer sein eigenes Verschlüsselungssetup haben.

Welche Methode sollte man wählen

🔹 Ganze Platte verschlüsseln (LUKS):

• Ideal für Laptops, Server oder Workstations mit sensiblen Daten.
• Wenn der physische Schutz der Daten höchste Priorität hat.
• Falls Swap, /tmp und andere Systemdateien nicht im Klartext sein sollen.

🔹 Nur Home-Verzeichnis verschlüsseln (eCryptfs, fscrypt):

• Geeignet für Multi-User-Systeme, bei denen Benutzer ihre Daten isoliert speichern sollen.
• Wenn man keine Passworteingabe beim Booten möchte.
• Falls nur persönliche Dateien wichtig sind, nicht aber das ganze System.

💡 Empfehlung:

Falls höchstmögliche Sicherheit gefragt ist, sollte die ganze Platte mit LUKS verschlüsselt werden. Wer aber einen guten Kompromiss zwischen Sicherheit und Bequemlichkeit sucht, kann nur den Home-Ordner verschlüsseln – insbesondere auf einem Multi-User-System.

Wer seine Platte zu Beginn mit LUKS verschlüsselt, muss seinen Homeordner natürlich nicht mehr verschlüsseln. Diese Option später im Installer kann man dann also ignorieren.

Fazit

LUKS ist ein leistungsstarkes Tool zur Verschlüsselung von Festplatten und besonders sinnvoll für mobile Geräte, sensible Daten und sicherheitskritische Anwendungen. Wer ein Linux-System mit persönlichen oder geschäftlichen Daten nutzt, sollte ernsthaft in Erwägung ziehen, die gesamte Festplatte oder zumindest sensible Partitionen mit LUKS zu verschlüsseln.

Hier ein Beitrag wie ihr euren Homeordner im Nachhinein verschlüsseln könnt, falls dies bei der Linux Installation nicht ausgewählt worden ist:

The post Was ist LUKS und wann sollte ich meine Festplatte verschlüsseln appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das Tutorial kommt ohne Live-Sticks und ohne neu Partitionierungen der Systemplatten aus, und ist somit eine anfängergfreundliche und denoch sichere Variante.

Vorbereitungen um den Linux Home Ordner mit LUKS verschlüsseln zu können

Wir spielen das aufsetzen des neuen Home Ordners anhand 2 Benutzern durch: Benutzer Wario und Benutzer Dario. Habt ihr nur einen Benutzer, dann lasst die Befehle für Dario einfach weg. Habt ihr mehrere Benutzer, dann fügt die Befehle hinzu mit einem weiteren Benutzer.

Backup erstellen: Vor allem anderen, erstellen wir zuerst ein Backup aller wichtigen Daten eures Home-Ordner. Das Risiko von Datenverlust ist real. Ihr könnt zum Beispiel Linux Timeshift verwenden, oder tut das von Hand mit einem USB Stick oder einem externen Laufwerk.

Da ihr keinen Zugriff auf den Homeordner anderer Benutzer habt, erstellt ihr ein Backup über die Befehlszeile auf einen Stick oder ein externes Laufwerk. Am besten verwendet ihr ein Laufwerk das mit ext4 vorher formatiert worden ist. Damit bleiben alle Berechtigungen und Gruppeneinstellungen eurer Ordner erhalten. kopiert euch den Inhalt des Homesordners mit dem Befehl:

sudo rsync -aAXv /home/wario /media/mario/home_backup
sudo rsync -aAXv /home/dario /media/mario/home_backup

Ersetzt mario mit eurem aktuellen Benutzer auf dem ihr arbeitet.

Cryptsetup und Authentifizerungsmodul installieren: installiert euch das pam_mount Authentifzierungsmodul mit:

sudo apt-get install cryptsetup
sudo apt update
sudo apt install libpam-mount

Temporären Benutzer erstellen: Erstellt euch einen temporären Benutzer damit wir mit diesem Arbeiten können, während wir die Home Ordner der Systembenutzer verschieben:

sudo adduser tempuser
sudo usermod -aG sudo tempuser

Verschlüsselten Home Ordner erstellen

Wechselt auf der Befehlszeile in den temporären Ordner mit:

su - tempuser

Erstellt ein neues Backup auf dem System mit welchem wir direkt arbeiten können:

sudo mkdir /home/wario_backup
sudo mkdir /home/dario_backup

und kopiert die Benutzerdaten erneut mit:

sudo rsync -aAXv /home/wario /home/wario_backup
sudo rsync -aAXv /home/dario /home/dario_backup

Erstellt eine LUKS-verschlüsselte Datei für Wario:

sudo dd if=/dev/zero of=/home/wario.luks bs=1M count=10240

** Bestätigt das löschen des Laufwerks mit YES**

sudo cryptsetup luksFormat /home/wario.luks

**Wählt das selbe Passwort wie das Passwort des Benutzers für das automatische Einbinden während des Starts!**

sudo cryptsetup open /home/wario.luks crypt_home_wario
sudo mkfs.ext4 /dev/mapper/crypt_home_wario

Ändert die Grösse der fett markierten Zahl mit einem Wert eurer Wahl. 10240 entsprechen ca. 10GB Speicher!

Das erstellen des verschlüsselten Verzeichnisses kann eine Weile dauern, wartet ab bis ihr wieder auf der Befehlszeile seid:

Mountet das neue Dateisystem in ein temporäres Verzeichnis:

sudo mkdir /mnt/wario
sudo mount /dev/mapper/crypt_home_wario /mnt/wario

Kopiert die Daten aus dem temporären Backup in das gemountete Verzeichnis mit:

sudo rsync -aAXv /home/wario_backup/ /mnt/wario

Ändert die Berechtigungen nochmals sicherheitshalber korrekt mit:

sudo chown -R wario:wario /mnt/wario

Umount das verschlüsselte Volume:

sudo umount /mnt/wario
sudo cryptsetup close crypt_home_wario

Wiederhollt die Schritte für Dario:

sudo dd if=/dev/zero of=/home/dario.luks bs=1M count=10240
sudo cryptsetup luksFormat /home/dario.luks
sudo cryptsetup open /home/dario.luks crypt_home_dario
sudo mkfs.ext4 /dev/mapper/crypt_home_dario
sudo mkdir /mnt/dario
sudo mount /dev/mapper/crypt_home_dario /mnt/dario
sudo rsync -aAXv /home/dario_backup/ /mnt/dario/
sudo chown -R dario:dario /mnt/dario
sudo umount /mnt/dario
sudo cryptsetup close crypt_home_dario

Alte Home-Ordner entfernen und Mountpoints vorbereiten

Bevor ihr die verschlüsselten Container automatisch einbinden könnt, müsst ihr die alten Home-Ordner entfernen. Andernfalls würden die verschlüsselten Daten beim Login über die bestehenden Ordner gemountet werden, was zu Problemen führt.

Entfernt die alten Home-Ordner mit:

sudo rm -rf /home/wario
sudo rm -rf /home/dario

Die Daten sind bereits in /home/wario_backup und /home/dario_backup sowie auf eurem externen Backup gesichert.

Erstellt nun neue, leere Verzeichnisse als Mountpoints für die verschlüsselten Container:

sudo mkdir /home/wario
sudo mkdir /home/dario

Setzt die korrekten Berechtigungen:

sudo chown wario:wario /home/wario
sudo chown dario:dario /home/dario

Jetzt sind die Mountpoints bereit und pam_mount kann die verschlüsselten Container beim Login korrekt einbinden.

Neue Home Partition automatisch einbinden

Eine gängige Praxis, um die Bequemlichkeit zu erhöhen und dennoch ein gewisses Sicherheitsniveau zu behalten, ist die Verwendung von PAM (Pluggable Authentication Modules). Es gibt ein PAM-Modul namens pam_mount, das automatisch Home-Verzeichnisse beim Benutzerlogin mounten kann, sofern das Login-Passwort und das LUKS-Passwort identisch sind. Dies ermöglicht eine nahtlose Benutzererfahrung, da die Benutzer nicht zweimal ein Passwort eingeben müssen.

Es ist jedoch zu beachten, dass die Verwendung desselben Passworts für mehrere Dienste oder Zwecke (z. B. Anmeldung und Disk-Verschlüsselung) potenzielle Sicherheitsrisiken birgt. Wenn dieses Passwort in irgendeiner Weise kompromittiert wird, ist sowohl der Zugriff auf den Computer als auch der Zugriff auf die verschlüsselten Daten gefährdet. Es ist immer ein Balanceakt zwischen Sicherheit und Bequemlichkeit.

Konfigurieren von pam_mount

Bearbeitet die Datei /etc/security/pam_mount.conf.xml mit einem Texteditor eurer Wahl, z.B.:

sudo nano /etc/security/pam_mount.conf.xml

Fügt direkt nach <pam_mount> die Konfigurationszeilen für eure LUKS-verschlüsseltes Laufwerke hinzu:

<volume user="wario" path="/home/wario.luks" mountpoint="/home/wario" options="defaults" />
<volume user="dario" path="/home/dario.luks" mountpoint="/home/dario" options="defaults" />

Jetzt sind wir soweit fertig und loggen uns aus dem temporären Benutzer aus mit exit und entfernen den Benutzer mit:

sudo deluser tempuser
sudo rm -rf /home/tempuser

Neustart und Überprüfung

Starte das System neu:

sudo reboot

Meldet euch mit den Benutzern an, und überprüft, ob die Home-Ordner korrekt gemountet wurden sind und der Inhalt eurer Daten vorhanden ist.

Falls alles in Ordnung ist, könnt ihr die backup Ordner löschen:

sudo rm -rf /home/wario_backup 
sudo rm -rf /home/dario_backup

Hinweis für Mehrbenutzersysteme

Für ein Mehrbenutzersystem müsst ihr sicherstellen, dass jeder Benutzer seine eigene verschlüsselte LUKS-Datei hat und diese in der pam_mount.conf.xml korrekt konfiguriert ist. Die Schritte müssen für jeden Benutzer wiederholt werden.

Container bzw. Home Ordner nachträglich vergrössern

Solltet ihr feststellen, dass die grösse des Homeordners nicht mehr ausreicht, könnt ihr diesen mit folgenden Schritten vergrössern.

Tempuser erneut erstellen

Da wir hier direkt am Homeordner arbeiten, kann der User wario nicht daran rumspielen, wenn er eingeloggt ist. Deshalb benötigen wir wieder einen tempuser mit sudo rechten:

sudo adduser tempuser
sudo usermod -aG sudo tempuser
sudo su - tempuser

Container Datei aushängen$

Überprüft ob das Verzeichnis aktiv und gemountet ist.

lsblk | grep crypt_home_wario

Falls es gemountet ist, vorher aushängen:

sudo umount /mnt/wario
sudo cryptsetup close crypt_home_wario

Container-Datei vergrößern

Da der Container eine normale Datei ist, kann man ihn mit truncate oder dd erweitern.

Beispiel: Container um 5 GB vergrößern

sudo truncate -s +5G /home/wario.luks

Falls truncate nicht verfügbar ist oder nicht funktioniert, kann man stattdessen dd verwenden:

sudo dd if=/dev/zero bs=1M count=5000 >> /home/wario.luks

Das fügt 5 GB an Daten zur Datei hinzu.

LUKS-Partition vergrößern

Damit LUKS die zusätzliche Größe erkennt, muss das verschlüsselte Volume neu eingehängt und vergrößert werden.

1. Container öffnen: sudo cryptsetup open /home/wario.luks crypt_home_wario
2. LUKS-Header aktualisieren, damit das Volume die neue Größe erkennt: sudo cryptsetup resize crypt_home_wario

Dateisystem anpassen

Da das Dateisystem innerhalb von LUKS liegt, muss es ebenfalls erweitert werden.

Falls der Container mit ext4 formatiert ist:

sudo resize2fs /dev/mapper/crypt_home_wario

Das vergrößert das ext4-Dateisystem, damit es den neuen Platz nutzt.

Überprüfen und abschließen

1. Prüfen, ob die neue Größe übernommen wurde: df -h /dev/mapper/crypt_home_wario
2. Falls alles korrekt ist, kann das Volume sicher geschlossen werden: sudo umount /mnt/wario sudo cryptsetup close crypt_home_wario

Danach kann sich der Benutzer Wario wieder wie gewohnt anmelden, und der Container hat mehr Platz.

Der tempuser kann wieder mit

sudo deluser tempuser 
sudo rm -rf /home/tempuser

gelöscht werden

Hinweise

• Backup vorher erstellen: Falls etwas schiefgeht, können Daten verloren gehen.
• Genügend freien Speicherplatz sicherstellen: Der Container kann nur wachsen, wenn genügend Platz auf der Hauptpartition vorhanden ist.
• Nur in sinnvollen Schritten vergrößern: Es ist effizienter, ihn einmal um 10 GB zu erweitern, statt immer wieder in kleinen Schritten.
• Container darf nicht aktiv genutzt werden: Der Benutzer sollte ausgeloggt sein, und das Volume darf nicht gemountet sein, bevor die Änderungen vorgenommen werden.

Mit diesen Schritten kann der LUKS-Container problemlos nachträglich vergrößert werden.

Fazit

Mit dieser Anleitung könnt ihr die Home-Ordner von mehreren Benutzern auf eurem System mit LUKS verschlüsseln und pam_mount verwenden, um die Volumes automatisch beim Login zu mounten. Diese Methode erhöht die Sicherheit, da der Schlüssel für die Entschlüsselung aus dem Benutzerpasswort abgeleitet wird.

Verschlüsselt ab der ersten Minute Nachträglich verschlüsseln geht, ist aber Fummelei. Bei unseren Linux Laptops ist die Festplattenverschlüsselung schon bei der Bestellung zubuchbar, dann steht sie vom ersten Start an.

The post Linux Home Ordner nachträglich mit LUKS verschlüsseln appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.