Alte Schannel-Stacks brechen an einem TLS-1.3-ClientHello kommentarlos ab:
sie nehmen die TCP-Verbindung an, lesen den ClientHello und setzen zurueck,
ohne ein Zertifikat zu schicken. Herunterhandeln hilft dann nicht — TLS 1.3
darf gar nicht erst angeboten werden.
max_tls_version (Default 1.3) deckelt die Hoechstversion; die Validierung
lehnt eine Hoechstversion unterhalb der Mindestversion ab.
check erkennt zusaetzlich zurueckgesetzte Verbindungen und nennt die beiden
plausiblen Ursachen: fehlendes LDAPS-Zertifikat auf dem Server oder
TLS-1.3-Inkompatibilitaet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBHF4R9EAejDJUMdwr6C68
Der bisherige Fehlertext gab den rohen x509-Fehler weiter, ohne zu sagen, was
zu tun ist. check unterscheidet jetzt unbekannte CA, unpassenden Hostnamen,
SHA-1-Signatur, abgelaufenes Zertifikat, zu alte TLS-Version und fehlende
gemeinsame Cipher-Suite und nennt jeweils die passende Stellschraube.
Der technische Originalfehler bleibt erhalten. Reine Netzwerkfehler bekommen
bewusst keinen Hinweis, damit kein falscher Verdacht entsteht.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBHF4R9EAejDJUMdwr6C68
Der Audit-Logger legt sein Verzeichnis per MkdirAll selbst an, check brach
aber ab, wenn es noch nicht existierte — der Pruefer war strenger als die
Laufzeit und blockierte die Erstinbetriebnahme. Fehlt zusaetzlich das
uebergeordnete Verzeichnis, bleibt es ein Fehler: dann steckt fast immer
ein Tippfehler im Pfad.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBHF4R9EAejDJUMdwr6C68
