Wie HTTPS eigentlich funktioniert (und was Traefik dir abnimmt)

Das Schloss-Symbol im Browser ist die am meisten benutzte und am wenigsten verstandene Sicherheitsfunktion des Webs. In diesem Konzept-Guide schaust du einmal dahinter – mit echten Befehlen statt grauer Theorie. Danach liest du Zertifikatsfehler wie eine Zutatenliste.

Was bauen wir?

Diesmal keinen neuen Dienst, sondern Verständnis: Am Ende weißt du, was ein TLS-Zertifikat ist, warum dein Browser ihm vertraut, wie Let’s Encrypt kostenlos beweist, dass eine Domain dir gehört, und was beim TLS-Handshake passiert. Jeden Baustein prüfst du selbst mit openssl und curl – die Beispiele sind mit OpenSSL 3.5 auf Debian 13 gegen die echte serverkueche.de ausgeführt und funktionieren gegen jede HTTPS-Website. Genau dieses Wissen setzt Traefik für dich in Automatik um – und wenn dort mal etwas klemmt, weißt du künftig, wo.

Voraussetzungen

• Verständnis, wie eine Domain auf deinen Server zeigt (A-Record, dig)
• Irgendein Linux-Terminal – dein Server oder dein Laptop; gebraucht werden nur Standardwerkzeuge (openssl, curl, dig aus dem Paket dnsutils)
• Kein laufender Webserver nötig – wir schauen uns bestehende Websites an

Schritt für Schritt

Schritt 1: Welche zwei Probleme TLS löst

HTTPS ist normales HTTP, transportiert durch einen TLS-Tunnel (Transport Layer Security). Der Tunnel löst zwei Probleme gleichzeitig:

1. Vertraulichkeit: Niemand zwischen Browser und Server kann mitlesen oder unbemerkt verändern – nicht das WLAN im Café, nicht der Provider.
2. Authentizität: Du redest wirklich mit dem Server hinter DEINE_DOMAIN – nicht mit einem Angreifer, der sich dazwischengeschaltet hat.

Für Punkt 2 braucht es einen Ausweis: das Zertifikat.

Schritt 2: Ein echtes Zertifikat ansehen

openssl s_client baut eine TLS-Verbindung auf und zeigt, was der Server vorlegt. Ersetze DEINE_DOMAIN durch eine beliebige HTTPS-Domain – hier läuft der Befehl gegen serverkueche.de:

echo | openssl s_client -connect DEINE_DOMAIN:443 -servername DEINE_DOMAIN 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Das echo | beendet die Verbindung sofort wieder, der zweite openssl-Aufruf übersetzt das vorgelegte Zertifikat in Klartext:

subject=CN=serverkueche.de
issuer=C=US, O=Let's Encrypt, CN=YR1
notBefore=Jul 16 11:33:26 2026 GMT
notAfter=Oct 14 11:33:25 2026 GMT

Diese Angaben solltest du lesen können:

• subject – für wen der Ausweis gilt. Für welche Hostnamen genau, steht im Feld Subject Alternative Name (hier: serverkueche.de und www.serverkueche.de – eine Subdomain wie blog.serverkueche.de wäre nicht abgedeckt und bräuchte ein eigenes Zertifikat).
• issuer – wer ihn ausgestellt hat: die Zertifizierungsstelle (CA), hier Let’s Encrypt mit ihrem Zwischenzertifikat YR1.
• notBefore/notAfter – die Gültigkeit. Rechne nach: 16. Juli bis 14. Oktober sind 90 Tage, die Standard-Laufzeit von Let’s Encrypt. Deshalb ist automatische Erneuerung keine Komfortfunktion, sondern Pflicht.

Schritt 3: Die Vertrauenskette – warum dein Browser dem Ausweis glaubt

Woher weiß dein Browser, dass YR1 kein Fantasiename ist? Über eine Kette. Lass dir alle Zertifikate der Verbindung zeigen:

echo | openssl s_client -connect DEINE_DOMAIN:443 -servername DEINE_DOMAIN 2>/dev/null | grep -E "^ *[0-9] s:|^ *i:"

 0 s:CN=serverkueche.de
   i:C=US, O=Let's Encrypt, CN=YR1
 1 s:C=US, O=Let's Encrypt, CN=YR1
   i:C=US, O=ISRG, CN=Root YR
 2 s:C=US, O=ISRG, CN=Root YR
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1

Lies es von oben nach unten (s: = subject, i: = ausgestellt von): Das Domain-Zertifikat (0) wurde vom Zwischenzertifikat YR1 unterschrieben (1), das wiederum von einem Root-Zertifikat der ISRG, der Organisation hinter Let’s Encrypt (2). Root-Zertifikate sind der Vertrauensanker: Sie sind in deinem Betriebssystem und Browser fest hinterlegt (der „Root Store“, auf Debian das Paket ca-certificates). Kann der Browser eine lückenlose Unterschriftenkette vom Server-Zertifikat bis zu einem Root aus seinem Store bilden, gilt die Verbindung als vertrauenswürdig – openssl meldet das in der s_client-Ausgabe als:

Verify return code: 0 (ok)

Alles andere als 0 (ok) ist einer der Fehlerfälle aus „Wenn es nicht funktioniert“.

Schritt 4: Wie Let’s Encrypt prüft, dass die Domain dir gehört

Eine CA darf ein Zertifikat nur ausstellen, wenn du die Kontrolle über die Domain nachweist. Das läuft über das ACME-Protokoll, vollautomatisch, in zwei Varianten:

• HTTP-01: Die CA sagt „lege die Datei X unter http://DEINE_DOMAIN/.well-known/acme-challenge/X ab“. Nur wer den Server hinter dem A-Record kontrolliert, kann das. Deshalb muss Port 80 aus dem Internet erreichbar sein – und deshalb steht der dig-Check im Domain-Tutorial vor dem ersten Zertifikat: Zeigt der A-Record ins Leere, findet die CA die Datei nie.
• DNS-01: Statt einer Datei setzt du einen TXT-Record _acme-challenge.DEINE_DOMAIN. Das braucht API-Zugriff auf deine DNS-Zone, funktioniert dafür ohne offenen Port – und ist der einzige Weg zu Wildcard-Zertifikaten (*.DEINE_DOMAIN).

Besteht dein Server die Challenge, unterschreibt Let’s Encrypt dein Zertifikat mit YR1 – und die Kette aus Schritt 3 ist komplett.

Schritt 5: Der Handshake – was bei jedem Verbindungsaufbau passiert

Das Zertifikat beweist die Identität, verschlüsselt wird mit etwas anderem. Beim TLS-Handshake einigen sich Browser und Server in wenigen Millisekunden auf einen gemeinsamen Sitzungsschlüssel. curl zeigt dir das Ergebnis:

curl -sIv https://DEINE_DOMAIN/ 2>&1 | grep -E "SSL connection|HTTP/"

* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* using HTTP/2
HTTP/2 200

Die eine Zeile fasst den ganzen Handshake zusammen: Protokoll TLS 1.3 (der aktuelle Standard), Schlüsselaustausch über die Kurve x25519 – dabei entsteht der Sitzungsschlüssel, ohne dass er je über die Leitung geht –, danach verschlüsselt AES-128-GCM den eigentlichen HTTP-Verkehr, und RSASSA-PSS ist die Unterschrift des Servers mit dem privaten Schlüssel zu seinem Zertifikat. Dieser private Schlüssel ist das eigentliche Geheimnis: Wer ihn hat, kann sich als deine Domain ausgeben.

Schritt 6: Was Traefik dir davon abnimmt

Jetzt kannst du einordnen, was Traefik im Hintergrund alles erledigt:

• ACME-Client: Zertifikat bestellen, HTTP-01-Challenge auf Port 80 beantworten, Kette abholen – beim ersten Start einer neuen App automatisch.
• Speicherung: Zertifikate samt privater Schlüssel landen in acme.json – deshalb besteht Traefik dort auf den strengen Dateirechten (chmod 600).
• Erneuerung: Rund 30 Tage vor Ablauf holt Traefik ohne dein Zutun ein frisches Zertifikat – von der 90-Tage-Laufzeit merkst du nichts.
• Auslieferung: Pro Anfrage wählt Traefik anhand des angefragten Hostnamens (SNI) das passende Zertifikat aus und leitet HTTP auf HTTPS um.

Ohne diese Automatik wäre HTTPS Handarbeit im Monatsrhythmus – abgelaufene Zertifikate sind einer der häufigsten selbstverschuldeten Ausfälle überhaupt.

Wenn es nicht funktioniert

Wartung & Backups

• Bei automatisierter Ausstellung: nichts Monatliches. Genau das ist der Punkt der Traefik-Automatik. Was du stattdessen tust: den Ablauf überwachen – Uptime Kuma prüft bei HTTPS-Monitoren das Zertifikat mit und warnt rechtzeitig vor dem Ablaufdatum. So fällt eine seit Wochen scheiternde Erneuerung auf, bevor Besucher Fehlermeldungen sehen.
• acme.json gehört ins Backup – sie enthält private Schlüssel, also nur verschlüsselt sichern, z. B. mit Restic. Nach einem Server-Neuaufbau müssen sonst alle Zertifikate neu ausgestellt werden, was am Rate-Limit scheitern kann.
• Die Laufzeiten schrumpfen branchenweit: Die CA/Browser-Gremien haben beschlossen, die maximale Zertifikatslaufzeit schrittweise zu senken – von 200 Tagen (ab 2026) über 100 Tage (ab 2027) bis auf 47 Tage ab 2029. Die 90 Tage von Let’s Encrypt sind also nicht knauserig, sondern die Zukunft für alle. Wer heute automatisiert, merkt davon nichts.