suche
ESC

Capstone: Zertifikatsfehler diagnostizieren

Abgelaufen, Chain-Lücke, Name-Mismatch oder schwache Cipher — den Fehler systematisch eingrenzen.

Second-Level Security 35 Min +250 XP

Worum geht’s

Ein Dienst meldet einen TLS-/Zertifikatsfehler — aber welchen? Abgelaufen, unvollständige Kette, Name-Mismatch oder veraltete Cipher sehen für Nutzer gleich aus („nicht sicher”), brauchen aber völlig verschiedene Lösungen. Dieser Capstone bündelt C1–C6: Du grenzt den Fehler über einen Entscheidungsbaum ein und belegst ihn an den Tool-Stationen.

Konzept

Eine bewährte Diagnose-Reihenfolge für Zertifikatsfehler:

  1. Gültigkeit zuerst — Not After prüfen. Abgelaufen ist der häufigste und am schnellsten bestätigte Fehler. (Tool: Zertifikat-Decoder)
  2. Name — passt der aufgerufene Host zu einem SAN-Eintrag? Sonst Name-Mismatch. (Tool: Zertifikat-Decoder)
  3. Kette — liefert der Server Leaf + Intermediate(s)? Lücke = „local issuer”-Fehler in frischen Clients. (Tool: Chain-Checker)
  4. Protokoll/Cipher — akzeptiert der Server nur veraltete TLS-Versionen/Cipher? Moderne Clients verweigern dann. (Tool: TLS-Checker)

Jeder Befund hat eine eindeutige Gegenmaßnahme — Zertifikat erneuern, SAN ergänzen, Fullchain ausliefern oder TLS-Konfiguration härten.

Beispiel-Fall

Aufgabe: Monitoring meldet für api.example.com: „certificate has expired”. Vorgehen?

  1. TLS-Checker auf api.example.com → liest das präsentierte Zertifikat und dessen Gültigkeit aus.
  2. Zertifikat-Decoder mit dem PEM → Not After liegt in der Vergangenheit. Befund bestätigt: abgelaufen. SAN passt, Kette ist vollständig — also kein anderer Fehler überlagert.
  3. Ursache: Auto-Renewal (z. B. ACME/Certbot) ist ausgefallen, das alte Zertifikat lief aus.
  4. Maßnahme: Zertifikat erneuern, Webserver neu laden, Renewal-Timer prüfen und einen Alert einrichten, der X Tage vor Not After warnt.

Anwenden

▶ Am Tool ausprobieren

Arbeite die Stationen in dieser Reihenfolge ab — Gültigkeit und Name sind schnell geklärt, Kette und Cipher folgen.

  1. Station 1 — TLS-Checker: Versionen, Cipher und HSTS der Zieldomain prüfen.
  2. Station 2 — Zertifikat-Decoder: Not After (Gültigkeit) und SAN-Liste gegen den Host prüfen.
  3. Station 3 — Chain-Checker: Vollständigkeit der Kette Leaf → Intermediate → Root prüfen.
Tool öffnen: /tls-checker ↗

Szenario

Szenario

Selbsttest

Praxis-Challenge

⚑ Praxis-Challenge

Suche dir eine echte HTTPS-Domain und arbeite die drei Stationen ab: TLS-Checker (Version, Cipher, HSTS), Zertifikat-Decoder (Not After + SAN gegen den Host) und Chain-Checker (Vollständigkeit). Schreibe einen kurzen Diagnose-Report: Welche vier Fehlerklassen kannst du ausschließen, welche (falls vorhanden) liegt vor — und nenne je die konkrete Gegenmaßnahme.

Tool öffnen: /tls-checker ↗

Modul im Speedrun testen →