Thema: tls
-
Ablauf von TLS-Zertifikaten auf jedem Endpunkt überwachen, nicht nur auf der Hauptwebsite
Ein abgelaufenes Zertifikat ist ein Ausfall mit exakt vorhersagbarem Zeitpunkt; das notAfter-Datum jedes tatsächlich ausgelieferten Zertifikats (Web, API, Mail, interne Panels, Load Balancer) von aussen abfragen, mit ausreichendem Vorlauf für eine manuelle Erneuerung alarmieren und sowohl die Zwischenzertifikate als auch das Endzertifikat prüfen.
-
Der TLS-1.3-Handshake im Überblick
TLS 1.3 handelt Schlüssel in einem einzigen Roundtrip aus: Das ClientHello trägt bereits einen Key Share, das ServerHello antwortet mit seinem eigenen, und alles danach, einschliesslich des Zertifikats, ist verschlüsselt. Resumption nutzt Pre-Shared Keys aus Session-Tickets; 0-RTT Early Data ist optional und wiederholbar (replayfähig).
-
Eine ausgelieferte TLS-Zertifikatskette und ihr Ablaufdatum von der Kommandozeile aus mit openssl prüfen
openssl s_client mit -servername und -showcerts gibt die Zertifikate aus, die ein Server tatsächlich sendet, was das Handbuch als keine verifizierte Kette beschreibt; openssl x509 liest Subject, Issuer, SANs und das notAfter-Datum jedes einzelnen aus, und openssl verify -untrusted baut die Kette unabhängig gegen einen Trust Store neu auf. Jeden Hostnamen prüfen, sowie IPv4 und IPv6 getrennt.
-
Lokales HTTPS für die Entwicklung: eine private CA, Trust Stores und die localhost-Ausnahme
Browser behandeln localhost und Loopback-Adressen bereits als potenziell vertrauenswürdig, sodass lokales HTTPS nur für TLS-spezifisches Verhalten oder Entwicklungsnamen ausserhalb des Loopbacks nötig ist; dafür pro Maschine eine private CA mit einem Werkzeug wie mkcert erstellen, Leaf-Zertifikate für Entwicklungsnamen ausstellen, das Root-Zertifikat im System- und in werkzeugspezifischen Trust Stores installieren und den CA-Schlüssel niemals weitergeben.
Maschinenlesbar: JSON