Es ist Freitagabend, 18 Uhr. Euer Webshop zeigt plötzlich eine Zertifikatswarnung, Kunden rufen an. Oder: Ein Entwickler kommt nicht mehr per SSH auf den Produktionsserver. Oder: Das VPN zum zweiten Standort steht, aber kein Traffic fließt. Drei verschiedene Symptome, drei verschiedene Ursachen – aber immer derselbe Ansatz: systematisch eingrenzen.

Dieser Block gibt euch die Diagnosewerkzeuge und Fehlermuster an die Hand, mit denen ihr TLS-, SSH- und VPN-Probleme unter Druck zuverlässig löst. Die Befehle hier ergänzen die Quick Reference in Block 17.

Nach diesem Block könnt ihr:

• TLS-Verbindungsprobleme mit openssl s_client systematisch diagnostizieren
• Zertifikatsketten auf Vollständigkeit und Gültigkeit prüfen
• SSH-Authentifizierungsfehler anhand der Verbose-Ausgabe eingrenzen
• Die häufigsten Fehlermeldungen (certificate verify failed, Permission denied, ERR_CERT_AUTHORITY_INVALID) korrekt interpretieren und beheben
• VPN-Verbindungsprobleme bei WireGuard und IPsec strukturiert analysieren

Systematisch vorgehen

Der häufigste Fehler bei der Fehlersuche: zu schnell zu viel auf einmal ändern. Wer gleichzeitig das Zertifikat tauscht, die Cipher Suite ändert und den Server neustartet, weiß hinterher nicht, was geholfen hat – und hat möglicherweise ein funktionierendes System in ein kaputtes verwandelt.

Besser: eine Ebene nach der anderen. Erst prüfen, ob die Verbindung überhaupt zustande kommt (Netzwerk, Port, Firewall). Dann ob das Zertifikat stimmt (Gültigkeit, Kette, Domain). Dann ob die Konfiguration passt (Cipher Suites, Berechtigungen). openssl s_client und ssh -v sind eure direktesten Werkzeuge – sie zeigen den Handshake Schritt für Schritt, unabhängig vom Browser oder Client.

TLS-Verbindung prüfen

Zurück zum Freitagabend-Szenario: Der Webshop zeigt eine Zertifikatswarnung. Bevor ihr irgendetwas konfiguriert, testet ihr mit openssl s_client direkt gegen den Server. Damit umgeht ihr Browser-Caches, HSTS-Einträge und andere Störvariablen – ihr seht genau das, was der Server liefert.

# TLS-Verbindung testen und Details anzeigen
openssl s_client -connect example.com:443

# Nur Zertifikatsinformationen
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
    openssl x509 -text -noout

# Ablaufdatum prüfen
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
    openssl x509 -dates -noout

# TLS-Version und Cipher Suite anzeigen
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
    grep -E "Protocol|Cipher"

# Bestimmte TLS-Version erzwingen (zum Testen)
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

# Alle unterstützten Ciphers testen (nmap)
nmap --script ssl-enum-ciphers -p 443 example.com

Zertifikat-Probleme

Zertifikatsprobleme haben fast immer eine von drei Ursachen: Das Zertifikat ist abgelaufen, die Zertifikatskette ist unvollständig (Intermediate CA fehlt), oder der Domainname stimmt nicht überein. Die folgenden Befehle decken alle drei ab.

# Zertifikat läuft bald ab?
openssl x509 -in server.crt -dates -noout
# Not After: Feb 16 10:00:00 2025 GMT

# Ist das Zertifikat für die Domain gültig?
openssl x509 -in server.crt -text -noout | grep -A5 "Subject Alternative Name"

# Zertifikatskette vollständig?
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | \
    grep -E "s:|i:"
# s: = Subject (das Zertifikat selbst)
# i: = Issuer (wer hat es signiert)
# Root CA sollte am Ende stehen

# Zertifikat gegen CA verifizieren
openssl verify -CAfile ca.crt server.crt

# Private Key zu Zertifikat passt?
# Beide müssen denselben Modulus haben
openssl rsa -in server.key -modulus -noout | md5sum
openssl x509 -in server.crt -modulus -noout | md5sum
# Gleiche md5-Summe → Key und Zertifikat passen zusammen

Häufige TLS/Zertifikats-Fehlermeldungen

Diese Fehlermeldungen begegnen euch im Berufsalltag regelmäßig. Wer sie lesen kann, spart sich langes Suchen – und wirkt beim Kunden sofort kompetent.

„certificate verify failed” Häufigstes Problem überhaupt. Drei mögliche Ursachen: (1) Zertifikat abgelaufen – openssl x509 -dates -noout prüfen. (2) CA nicht vertrauenswürdig – bei internen CAs: Root-CA-Zertifikat auf dem Client installiert? (3) Zertifikatskette unvollständig – Intermediate CA fehlt in der Serverkonfiguration (häufigster Fehler bei frischen Installationen, Block 06).

„SSL_ERROR_RX_RECORD_TOO_LONG” Der Server antwortet auf Port 443 mit unverschlüsseltem HTTP. Typisch: Apache oder nginx läuft, aber die TLS-Konfiguration (VirtualHost mit SSLEngine on) fehlt oder zeigt auf den falschen Port.

„ssl_error_handshake_failure” Client und Server haben keine gemeinsame Cipher Suite. Passiert oft, wenn ein Server nur TLS 1.3 erlaubt, aber ein alter Client noch TLS 1.2 spricht – oder umgekehrt. Mit nmap --script ssl-enum-ciphers könnt ihr sehen, was der Server anbietet.

„ERR_CERT_COMMON_NAME_INVALID” Der Domainname im Zertifikat stimmt nicht mit der aufgerufenen Domain überein. Häufig nach einem Umzug: Das Zertifikat gilt für www.techwerk.de, aber der Kunde ruft techwerk.de auf. SAN-Eintrag prüfen (Block 06).

„ERR_CERT_DATE_INVALID” Zertifikat ist abgelaufen oder noch nicht gültig. Zwei Ursachen: (1) Let’s Encrypt-Erneuerung ist fehlgeschlagen – sudo certbot renew prüfen. (2) Die Systemuhr des Clients ist falsch – kommt häufiger vor als man denkt, besonders auf VMs.

SSH-Troubleshooting

Zweites Szenario: Ein Entwickler kommt nicht mehr auf den Produktionsserver. „Permission denied”, mehr sagt die Konsole nicht. Die gute Nachricht: SSH-Probleme haben fast immer eine von drei Ursachen – falsche Dateiberechtigungen, fehlender Public Key in authorized_keys, oder ein Host-Key-Konflikt. Der Verbose-Modus (-v) zeigt euch sofort, an welcher Stelle die Authentifizierung scheitert – lest die Ausgabe von oben nach unten.

# Verbindung mit ausführlicher Ausgabe (zeigt jeden Schritt)
ssh -v user@server        # einfach verbose
ssh -vv user@server       # mehr Details
ssh -vvv user@server      # maximale Details (für komplizierte Probleme)

# Typische Ausgaben und ihre Bedeutung:
# "Offering public key" → Client bietet Schlüssel an
# "Server accepts key"  → Authentifizierung erfolgreich
# "Permission denied"   → Schlüssel abgelehnt oder kein passender Schlüssel

Häufige SSH-Probleme und Ursachen:

„Permission denied (publickey)”

# 1. Ist der Public Key auf dem Server eingetragen?
cat ~/.ssh/authorized_keys   # auf dem Server ausführen

# 2. Sind die Berechtigungen korrekt?
ls -la ~/.ssh/
# ~/.ssh/           muss 700 sein
# authorized_keys   muss 600 sein
# id_ed25519        muss 600 sein (Private Key)

# 3. Wird der richtige Schlüssel verwendet?
ssh -i ~/.ssh/id_ed25519 user@server

„WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!”

Diese Warnung ist ernst zu nehmen. Sie bedeutet entweder: Der Server wurde neu aufgesetzt und hat einen neuen Host-Key – oder jemand sitzt zwischen euch und dem Server (MITM). Klärt das zuerst, bevor ihr den Eintrag löscht.

# Server-Schlüssel hat sich geändert (Neuinstallation oder MITM-Verdacht!)
# Erst mit Administrator klären, ob der Server neu aufgesetzt wurde.
# Dann alten Eintrag entfernen:
ssh-keygen -R server.techwerk.intern

# Neuen Host-Key fingerprint vorher verifizieren (per sicherem Kanal)
ssh-keyscan server.techwerk.intern 2>/dev/null | ssh-keygen -lf -

Verbindung hängt oder bricht sofort ab

# SSH-Dienst auf dem Server läuft?
sudo systemctl status sshd

# Firewall blockiert Port 22?
sudo ufw status
sudo firewall-cmd --list-ports

# Auf anderem Port lauschen?
sudo ss -tlnp | grep sshd

# Server-Log prüfen (zeigt Ablehnungsgründe)
sudo journalctl -u sshd -f
# oder:
sudo tail -f /var/log/auth.log

SSH-Server-Konfiguration prüfen

# Konfiguration auf Syntaxfehler prüfen
sudo sshd -t

# Aktive Konfiguration anzeigen
sudo sshd -T | grep -E "passwordauthentication|permitrootlogin|port"

VPN-Troubleshooting

Drittes Szenario: Das VPN zum zweiten Standort steht laut Konfiguration, aber die Kollegin in Berlin kann den Fileserver in München nicht erreichen. VPN-Probleme sind oft subtil: Die Verbindung baut sich auf, aber Traffic fließt nicht. Oder der Handshake schlägt gar nicht erst an. Beides hat unterschiedliche Ursachen – und unterschiedliche Diagnoseschritte.

WireGuard:

# Interface-Status und Verbindungen anzeigen
sudo wg show

# Interface ist aktiv?
ip link show wg0

# Routing prüfen – geht Traffic durch den Tunnel?
ip route show table main

# Paketfluss beobachten
sudo tcpdump -i wg0

# WireGuard-Log (systemd)
sudo journalctl -u wg-quick@wg0 -f

Häufige WireGuard-Probleme:

IPsec (strongSwan/swanctl):

# Aktive Verbindungen anzeigen
sudo ipsec status

# Detaillierte Verbindungsinfo
sudo ipsec statusall

# Verbindung manuell aufbauen
sudo ipsec up verbindungsname

# Log verfolgen
sudo journalctl -u strongswan -f

Allgemeine VPN-Diagnose:

# Erreichbarkeit des VPN-Gateways prüfen
ping vpn.techwerk.de
traceroute vpn.techwerk.de

# DNS-Auflösung im Tunnel funktioniert?
nslookup server.intern 10.0.0.1    # DNS-Server im Tunnel direkt ansprechen

# MTU-Probleme (häufig bei VPN – große Pakete kommen nicht an)
ping -M do -s 1400 10.0.0.1       # Ping mit fester Paketgröße ohne Fragmentierung

Merke: Die häufigsten VPN-Probleme sind: Firewall blockiert das Protokoll oder den Port, falsche Routen (AllowedIPs/Split-Tunnel), MTU-Probleme bei großen Paketen, und abgelaufene Zertifikate bei IPsec mit PKI-Authentifizierung. Wer mit wg show keinen Handshake sieht, fängt bei der Firewall an – nicht bei der Konfigurationsdatei.

Typischer Denkfehler

„Zertifikatsfehler im Browser kann man einfach wegklicken.”

Viele Anwender – und leider auch manche Admins – klicken Zertifikatswarnungen routinemäßig weg. Das ist gefährlich, weil es genau den Schutzmechanismus aushebelt, für den TLS gebaut wurde. Eine Zertifikatswarnung bedeutet konkret: Der Browser kann nicht sicher bestätigen, dass ihr wirklich mit dem Server kommuniziert, den ihr erreichen wollt. Die häufigsten Ursachen sind harmlos (abgelaufenes Zertifikat, fehlende Intermediate CA), aber die Warnung sieht identisch aus, wenn jemand aktiv euren Traffic abfängt (MITM-Angriff). Wer sich angewöhnt, Warnungen wegzuklicken, wird den einen echten Angriff zwischen hundert harmlosen Fällen nicht erkennen. Die richtige Reaktion: Warnung ernst nehmen, Ursache mit openssl s_client diagnostizieren, Problem beheben – nicht umgehen.

Praxis-Impuls

Probiert es selbst:

1. TLS-Verbindung testen: Führt openssl s_client -connect google.com:443 </dev/null aus. Lest die Ausgabe: Welche TLS-Version wird verwendet? Welche Cipher Suite? Wie viele Zertifikate enthält die Kette?
2. Ablaufdatum prüfen: Testet mit openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -dates -noout, wann das Zertifikat einer beliebigen Website abläuft.
3. SSH-Verbose-Modus: Verbindet euch mit ssh -v zu einem eurer Server. Identifiziert in der Ausgabe, welchen Schlüsseltyp der Server anbietet und welche Authentifizierungsmethode euer Client verwendet.
4. Absichtlich scheitern: Versucht openssl s_client -connect example.com:443 -tls1 (TLS 1.0 erzwingen). Die Verbindung sollte scheitern – lest die Fehlermeldung und versteht, warum.

Zusammenfassung

• Systematik schlägt Hektik: Immer eine Ebene nach der anderen prüfen – Netzwerk, Zertifikat, Konfiguration. Nie mehrere Dinge gleichzeitig ändern.
• openssl s_client ist das universelle TLS-Diagnosewerkzeug. Es zeigt Zertifikatskette, TLS-Version, Cipher Suite und Fehlermeldungen unabhängig vom Browser.
• Die drei häufigsten Zertifikatsprobleme sind: abgelaufen, unvollständige Kette (fehlende Intermediate CA) und falscher Domainname (SAN-Eintrag).
• SSH-Probleme löst ihr über den Verbose-Modus (ssh -v) und die Prüfung von Dateiberechtigungen (700 für .ssh/, 600 für Keys und authorized_keys).
• Bei VPN ohne Traffic prüft zuerst Firewall und Routing (AllowedIPs), dann MTU, dann Konfiguration.

Selbsttest

Frage 1: Ein Webserver zeigt ERR_CERT_AUTHORITY_INVALID – nennt drei mögliche Ursachen und den jeweiligen Diagnosebefehl.

Frage 2: Ein Entwickler meldet „Permission denied (publickey)” beim SSH-Login. Beschreibt euren Diagnoseweg in drei Schritten.

Frage 3: Euer WireGuard-VPN baut sich auf, aber Pings an Hosts im entfernten Netz kommen nicht an. Wie geht ihr vor?

Wie geht es weiter?

Dies war das letzte inhaltliche Kapitel der Kryptographie-Reihe. In Block 17 – Quick Reference findet ihr alle wichtigen Befehle und Konfigurationen als kompakte Nachschlagereferenz für den Arbeitsalltag. Der Anhang enthält ein abschließendes Quiz und Praxisaufgaben, mit denen ihr euer Wissen über alle Blöcke hinweg testen könnt. Jetzt ist der richtige Zeitpunkt, das Gelernte in die Praxis zu bringen.