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.
-
Prüfen, ob eine TLS-Verbindung tatsächlich X25519MLKEM768 ausgehandelt hat
Mit Browserdetails, OpenSSL, curl und serverseitigen Nachweisen unterscheiden, ob Post-Quanten-Verfahren lediglich verfügbar sind oder die entsprechende Gruppe auf einer tatsächlichen TLS-Verbindung ausgewählt wurde.
-
Konsistenz von Hostname, FQDN und Reverse DNS: Warum Kerberos- und TLS-Namensprüfungen scheitern, wenn die Namen nicht übereinstimmen
Kerberos-Service-Tickets und die TLS-Hostnamenprüfung setzen voraus, dass der Name, den ein Client für einen Server auflöst, mit dem Namen übereinstimmt, den der Dienst für sich selbst annimmt. Weichen konfigurierter Hostname, /etc/hosts, Forward-DNS und PTR-Record voneinander ab, entstehen Authentifizierungs- und Zertifikatsfehler, die auf den ersten Blick nichts mit Namensauflösung zu tun haben.
-
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).
-
TLS-Verifikationsfehler in verschiedenen Tools: unknown authority, CERTIFICATE_VERIFY_FAILED, self-signed in chain
Verschiedene TLS-Clients melden denselben zugrunde liegenden Fehler, eine unvollständige oder nicht vertrauenswürdige Zertifikatskette, mit eigenen Formulierungen: 'certificate signed by unknown authority', 'CERTIFICATE_VERIFY_FAILED', 'unable to get local issuer certificate', 'self-signed certificate in certificate chain'. Der Artikel zeigt, wie sich die tatsächliche Kette vor jeder Korrektur mit openssl s_client untersuchen lässt und weshalb -k oder verify=False nie eine Lösung ist.
-
Exit-Codes von curl: DNS-Fehler, TLS-Fehler und --fail auseinanderhalten
curl liefert für jede Klasse von Transportfehlern (Namensauflösung, Verbindung, TLS, Timeout) einen eigenen numerischen Code sowie den separaten Code 22, der nur auftritt, wenn --fail oder --fail-with-body für HTTP-Fehlerstatus angefordert wird. Ein Agent, der statt der Textausgabe den Exit-Code von curl auswertet, kann Wiederholungsversuche korrekt steuern, ohne die Ausgabe parsen zu müssen.
-
Post-Quanten-Signaturen und öffentliche TLS-Zertifikate: Einsatzreife getrennt prüfen
ML-DSA und SLH-DSA sind standardisierte Signaturalgorithmen. Die Ausstellung öffentlicher TLS-Zertifikate hängt jedoch zusätzlich von Zertifikatsprofilen, der Protokollintegration und der Zulassung durch Vertrauensrichtlinien ab.
-
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.
-
Private CA zum System-Truststore hinzufügen: RHEL-Familie und Debian/Ubuntu
RHEL- und Debian-basierte Linux-Distributionen verwenden getrennte Mechanismen für lokal vertrauenswürdige CA-Zertifikate: update-ca-trust mit Anchors unter /etc/pki/ca-trust bzw. update-ca-certificates mit .crt-Dateien unter /usr/local/share/ca-certificates. Ein falsches Verzeichnis oder eine falsche Dateiendung lässt die CA ohne Fehlermeldung unberücksichtigt.
-
TLS-Gruppenvorgaben finden, die den Wechsel zu hybriden Standardeinstellungen verhindern
Explizite Gruppenlisten in Go, Java, nginx und der OpenSSL-Konfiguration prüfen, bevor angenommen wird, dass ein Bibliotheksupgrade den Post-Quanten-Schlüsselaustausch aktiviert.
-
Systemweite Crypto-Policies unter RHEL mit update-crypto-policies umstellen
Die systemweite Crypto-Policy von RHEL legt fest, welche Standardalgorithmen und Protokollversionen OpenSSL, GnuTLS, NSS, libkrb5 und OpenSSH anbieten, und lässt sich mit einem einzigen Befehl ändern, statt die Konfiguration jeder Anwendung zu bearbeiten. Die Methodik behandelt Anzeigen, Setzen und Testen einer Policy sowie den Grund, warum bereits laufende Dienste einen Neustart brauchen, um sie zu übernehmen.
-
TLS für die rsyslog-Weiterleitung mit dem gtls-Treiber und wann sich RELP zusätzlich lohnt
Der Network Stream Driver gtls von rsyslog verschlüsselt Weiterleitungsverbindungen und kann sie über X.509-Zertifikate gegenseitig authentifizieren; konfiguriert wird dies mit StreamDriverAuthMode. Reines TLS über TCP verliert bei einem unsauberen Verbindungsabbruch dennoch Nachrichten, die gerade unterwegs sind. Diese Lücke schliesst erst die Bestätigung auf Anwendungsebene von RELP, allerdings um den Preis zusätzlicher Komponenten.
-
Private CA unter macOS und Windows als vertrauenswürdig einrichten und die Wirkung prüfen
macOS vertraut einer Root-CA systemweit über den System-Schlüsselbund mit `security add-trusted-cert`, Windows über den Local-Machine-Root-Speicher mit Import-Certificate oder certutil -addstore. Beide Änderungen erfolgen ohne Rückmeldung und müssen separat geprüft werden; sie unterscheiden sich von einer Vertrauensentscheidung pro Benutzer oder pro Browser.
-
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.
-
Warum Anwendungen den Trust Store des Betriebssystems ignorieren: Java cacerts, Python certifi, Node.js und curl
Eine CA im Trust Store des Betriebssystems hinzuzufügen, heisst nicht, dass jede Anwendung ihr vertraut. Java, viele Python-Installationen, Node.js und curl-Builds können ein eigenes CA-Bundle oder einen eigenen Keystore mitbringen, jeweils mit eigenem Speicherort und eigener Umgebungsvariable zum Überschreiben. Ein Zertifikatsfehler kann deshalb nach der Korrektur auf OS-Ebene bestehen bleiben.
Maschinenlesbar: JSON