Die Ubuntu-LDAP-Authentifizierung funktioniert auf meinem Client nicht, wenn die Option „SSL start_tls“ in der Datei ldap.conf aktiviert ist. Ich kann mich authentifizieren, wenn ich „SSL start_tls“ auskommentiere.
Ich habe das Zertifikat des LDAP-Servers aktualisiert und seitdem können sich Benutzer auf meinem Ubuntu 10.04-Client-Rechner nicht mehr authentifizieren, wenn SSL aktiviert ist. Die aufgetretenen Änderungen:
Cert upgraded from 1024 to 2048 bit
now is a wildcart cert and use it to be a self-signed cert
encryption algorithm is now shaw512 (use to be md5)
Mein Auth.log enthält einige Fehler:
nss-ldap: do_open: do_start_tls fehlgeschlagen:stat=-1
Die neuen Zertifikate funktionieren, weil ich einige andere Clients habe, die sich mit den neuen Zertifikaten authentifizieren (alte CentOS-Maschinen).
Hat jemand eine Idee, warum ich auf meinem Client kein SSL mehr mit LDAP verwenden kann?
Antwort1
Gibt es eine Signaturhierarchie (d. h. nicht selbstsigniert)? „Wildcard“ und „selbstsigniert“ schließen sich nicht aus. Ein kommerzielles Wildcard-Zertifikat hat eine Hierarchie, d. h. eine oder mehrere Zwischenzertifizierungsstellen und eine Stammzertifizierungsstelle.
sha-512 oder md5 sindHashesin der Zertifikatsignatur verwendet werden, sind sie nichtVerschlüsselungsalgorithmen. Diese dienen der Überprüfung der Zertifikatsintegrität, die für eine Verbindung verwendete Verschlüsselung wird unabhängig davon ausgehandelt.
Ich denke, die wahrscheinlichsten Ursachen sind entweder, dass sha512 (genauer gesagt „sha512WithRSAEncryption“) in Ubuntu 10 nicht unterstützt wird; oder dass auf der Maschine ein oder mehrere CA-Zertifikate (Zwischen- oder Root-Zertifikat) fehlen, sodass die vollständige Kettenüberprüfung nicht abgeschlossen werden kann.
Sie können prüfen, ob OpenSSL mit dem neuen Zertifikat des Servers umgehen kann, indem Sie (auf dem Ubuntu 10-Computer) Folgendes ausführen:
openssl x509 -in newservercert.crt -noout -text
obwohl das möglicherweise nicht schlüssig ist. Das Folgende könnte auch hilfreich sein:
ldapsearch -x -Z -v -h your.ldap.server
(Es besteht eine geringe Chance, dass GnuTLS statt OpenSSL verwendet wird, da kann ich leider nicht helfen!)
Sie können ein Kettenproblem wahrscheinlich bestätigen oder verneinen, indem Sie Folgendes zu Ihrer Datei /etc/ldap/ldap.conf hinzufügen:
TLS_REQCERT never
Wenn das hilft, sollten Sie die fehlenden Teile der Kette beschaffen und sie Ihrem lokalen Speicher hinzufügen. Wie das geht, hängt von der Client-Konfiguration ab. Beginnen Sie damit, in den Anweisungen in /etc/ldap/ldap.conf nach „TLS_CACERT“ und/oder TLS_CACERTDIR zu suchen.
Zu den weniger wahrscheinlichen Ursachen gehören:
- Unfähigkeit, CRLs zu prüfen (prüfen Sie ldap.conf, um zu sehen, ob es aktiviert ist)
Und unter der Annahme, dass sich sonst nichts geändert hat, sind der Vollständigkeit halber auch unwahrscheinliche Ursachen aufgeführt:
- Server-Protokollversion oder Verschlüsselungssatz werden vom Client nicht unterstützt
- Änderungen bei den unterstützten SASL-Mechanismen
Antwort2
Ich bin nicht sicher, ob Sie diese Frage gelöst haben. Ich bin auf die gleiche Situation gestoßen. 12.04 stellt über TLS eine Verbindung zum LDAP-Server her, 10.04 jedoch nicht. Meine Lösung besteht darin, eine Zeile hinzuzufügen /etc/ldap/ldap.conf:
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
und der 10.04-Client kann über TLS eine Verbindung zum LDAP-Server herstellen.