LDAPS funktioniert über ldp.exe und über eine Reihe anderer Programme auf Windows- und Linux-Systemen, die das Stammzertifikat anscheinend überhaupt nicht benötigen. Einige Programme, die JSSE verwenden, können nach dem Importieren der Stamm- und Zwischenzertifizierungsstelle in den Cacerts-Truststore keine Verbindung herstellen.
Ich habe den Import des in NTDS\Personal (aus AD) vorhandenen LDAPS-Zertifikats direkt in cacerts getestet. In bestimmten Anwendungen, die Java verwenden, funktioniert dadurch sicheres LDAP.
In Programmen, die Java verwenden und fehlschlagen, erhalte ich beim Importieren des Stammzertifikats den Fehler:
[Root-Ausnahme ist javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX-Pfadvalidierung fehlgeschlagen: java.security.cert.CertPathValidatorException: Signaturprüfung fehlgeschlagen]
Wenn ich das LDAPS-Zertifikat importiere, erhalte ich manchmal die folgende Fehlermeldung:
[Root-Ausnahme ist javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Zertifikate entsprechen nicht den Algorithmusbeschränkungen]
(sogar nach dem Auskommentieren von java.security)
ODEREs beginnt je nach Programm, das JRE verwendet, zu funktionieren. Das gemeinsame Hindernis besteht jedoch darin, dass JRE die Zertifikatskette aufgrund der Fehler allgemein nicht zu mögen scheint.
MEINE CDP/AIA sind intern per HTTP verfügbar und alle Zertifikate sind von einer vertrauenswürdigen privaten internen zweistufigen Windows-PKI signiert.
openssl s_client -connect -showcerts domain:port
Gibt die richtige Zertifikatskette zurück, aber auch den Fehler:
verify error:num=20:unable to get local issuer certificate
Das hängt offensichtlich damit zusammen, dass OpenSSL das Stammzertifikat nicht erkennt. Daher -cafileerhalte ich sogar mit dem Nachtrag denselben Fehler. Das mag aufschlussreich sein, aber der Fingerabdruck in der Zertifikatskette für das Stammzertifikat ist derselbe wie der, -cafilealso müsste es wohl richtig sein …
An diesem Punkt fange ich an zu denken, dass 70 % aller Anleitungen zum Aktivieren von LDAPS mit Java falsch sind (sie widersprechen sich sicherlich alle genug) und dass die Regeln für JAVA CAPS mehr Sinn ergeben, wenn es darum geht, warum ich das eigentliche LDAPS-Zertifikat importieren muss, anstatt einfach dem Stammzertifikat zu vertrauen.https://docs.oracle.com/cd/E19509-01/820-3399/ggfrj/index.html
Bearbeiten: Siehe Antwort
Klingt das also nach einem Konfigurationsproblem mit meinem Zertifikat oder nach etwas anderem Java-spezifischen Problem?
Antwort1
Es stellte sich heraus, dass ich beim Einrichten der PKI technisch alles richtig gemacht hatte. Die Fehler traten auf, weil meine Zertifikate mit RSASSA-PSS signiert waren. Java 1.8 unterstützt PKCS #1 v2.1 nicht.
Ich musste die gesamte Zertifikatskette von der Root- bis zur ausstellenden Zertifizierungsstelle neu generieren. Dazu war eine Bearbeitung der Datei CAPolicy.inf erforderlich.
AlternateSignatureAlgorithm=1Zu0
Auch die cmd-Zeile
certutil -setreg ca\csp\alternatesignaturealgorithm 0
Muss auch manuell angegeben werden.
Es schien ein Zertifikatsproblem zu sein, aber ich hätte nie gedacht, dass die Signaturkompatibilität das Problem sein könnte. Lektion gelernt.
Verwandtes Problem: Kompatibilität mit Microsoft-Zertifizierungsstellenanbietern
Verwandte Quellen: https://pkisolutions.com/pkcs1v2-1rsassa-pss/