TLS und Zertifikate
Die wichtigsten Befehle zum Merken
openssl s_client— TLS-Verbindung und Prüfung untersuchen.curl -I https://…— HTTPS-Metadaten mit normaler Zertifikatsprüfung abfragen.
Befehle und Optionen
| Option oder Syntax | Bedeutung |
|---|---|
timeout 10 |
Den Diagnoseprozess auf zehn Sekunden begrenzen. |
-connect example.com:443 |
Netzwerkhost und TCP-Port wählen. |
-servername example.com |
Den gewünschten Namen als TLS-SNI senden. |
-verify_hostname example.com / -verify_return_error |
Zertifikatsnamen prüfen / bei Prüfungsfehlern abbrechen. |
-brief |
Eine kurze Verbindungsübersicht ausgeben. |
< /dev/null |
Eingabeende statt interaktiver Anwendungsdaten liefern. |
curl -I --max-time 10 |
HTTP HEAD mit zehn Sekunden Zeitlimit senden. |
SNI wählt eine Serveridentität aus, prüft aber selbst kein Zertifikat.
Die entscheidenden Konzepte
1. TLS schützt eine Verbindung
Transport Layer Security (TLS) vereinbart Schlüssel und schützt Anwendungsdaten auf dieser Verbindung gegen Mithören und unbemerkte Änderungen. Modernes HTTPS verwendet TLS für HTTP-Verkehr.
Der Handshake handelt Parameter aus und authentifiziert bei durchgeführter Prüfung den Server. Danach schützt symmetrische Kryptografie die Daten. TLS beweist keinen ehrlichen Server, keine fehlerfreie Anwendung und keine Benutzerautorisierung.
2. Ein Zertifikat verbindet Identität und öffentlichen Schlüssel
Ein Serverzertifikat ordnet einem öffentlichen Schlüssel Namen und weitere Einschränkungen zu. Der Server weist beim Authentifizieren den Besitz des passenden privaten Schlüssels nach. Das Zertifikat ist öffentlich; der private Schlüssel muss geheim bleiben.
Die Namensprüfung fragt, ob das Zertifikat den beabsichtigten Hostnamen abdeckt. Eine Verbindung zu einer IP mit anderem SNI macht nicht jedes zurückgegebene Zertifikat für die Anfrage gültig.
3. Vertrauen braucht mehr als das Lesen des Subjects
Der Client baut und prüft nach seiner Konfiguration eine Kette zu einer vertrauenswürdigen Zertifizierungsstelle. Gültigkeitszeiten, Namen, Signaturen und Einschränkungen zählen. Ein angezeigtes Zertifikat hat diese Prüfungen nicht zwangsläufig bestanden.
Ein selbstsigniertes Zertifikat kann in einer kontrollierten Vertrauenskonfiguration passen. Jedem antwortenden Zertifikat zu vertrauen beseitigt dagegen die Authentifizierung. Falsche Uhrzeit oder fehlende Zwischenzertifikate können trotz erreichbarem Server Fehler verursachen.
4. Jeder TLS-Abschnitt hat seine eigene Grenze
Ein Reverse-Proxy kann TLS terminieren und eine andere Verbindung zum Backend öffnen. Prüfung und Verschlüsselung des ersten Abschnitts schützen nicht automatisch den zweiten. Zertifikate laufen zudem unabhängig von Anwendungsdeployments ab und werden erneuert.
Trenne DNS, TCP-Aufbau, TLS-Prüfung und HTTP-Antwort bei der Diagnose. Ein Handshake beweist weniger als eine erfolgreiche Anfrage. Ein HTTP-Fehler kann über eine gültige TLS-Verbindung ankommen.
Ein kleines Beispiel
Optional: Führe die Befehle in einem Linux-Terminal aus. Sie kontaktieren die Beispieldomain mit aktiver Zertifikatsprüfung.
timeout 10 openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error -brief < /dev/null
curl -I --max-time 10 https://example.com/Prüfe in OpenSSL Protokollversion, Cipher, Peer-Identität und Prüfergebnis. Der Befehl aktiviert Namensprüfung und bricht bei Prüfungsfehlern ab. SNI allein würde das nicht leisten.
Curl geht eine Ebene weiter und fragt HTTP-Header ab. Status und TLS-Details hängen von Endpunkt und Vertrauensspeicher ab. Eine EOF-Meldung nach erfolgreicher Aushandlung kann das Schließen der Diagnoseverbindung betreffen. Unterscheide sie vom Zertifikatsfehler.
Timeout begrenzt eine hängende Diagnose. Es werden weder Schlüssel noch Vertrauenseinträge erzeugt. Aufräumen ist nicht erforderlich.
Merke dir: TLS schützt die Verbindung zum authentifizierten vorgesehenen Peer. Ein gültiger Handshake ist keine Anwendungsautorisierung.