21
TLS für LDAPs auf Debian 11 streikt
Hallöchen zusammen, ich mal wieder mit einem Anliegen.
Folgende Umgebung:
Active Directory (2016er Funktionsebene) mit integrierter PKI (einmal Root CA, offline und zweimal Issuing CA).
Domänencontroller spricht nur LDAPs mit seinem Zertifikat (ausgestellt von einer der Issuing CAs und gültig).
Es gibt unter anderem einen Zabbix Server auf Debian 11, auf welchem bis vor kurzem LDAPs noch funktioniert hat. Das Root-CA-Zertifikat liegt dort in /usr/local/share/ca-certificates/ und ist mittelsins System übernommen worden (es liegt in /etc/ssl/certs/ als einzelne Datei und auch in der /etc/ssl/certs/ca-certificates.crt ist es drin).
Wir haben nun den alten Domänencontroller abgelöst und durch einen neuen (logischerweise mit neuem Hostname) ersetzt. Auch ein paar Linux-Updates gab es in der Zwischenzeit. Seither funktioniert die Authentifizierung nicht mehr und schlägt fehl mit dem Fehler "Can't bind to LDAP Server". Den FQDN habe ich natürlich entsprechend in Zabbix geändert. Einergibt ein "Can't contact LDAP server (-1)".
In der /etc/ldap/ldap.conf steht drin, das sollte also eigentlich passen.
Ein ergibt eine einwandfreie Zertifikatskette (Verification: OK), das Zertifikat vom Domaincontroller ist auf den FQDN ausgestellt.
Ich bin grad etwas am verzweifeln, was ich hier übersehe, denn mit der Option und funktioniert es (sowohl mit ldapsearch als auch im Zabbix), ich vermute also die Zertifikatsprüfung basiert hier irgendwie nicht auf der /etc/ssl/cets/ca-certificates.crt.
Hat hier einer eine Idee? Falls noch genauere Infos nötig sind stelle ich diese gerne noch zur Verfügung.
EDIT: Auf anderen Systemen (z.B. der Firewall) funktioniert die Authentifizierung einwandfrei.
Danke schonmal und Viele Grüße!
Ketanest
Folgende Umgebung:
Active Directory (2016er Funktionsebene) mit integrierter PKI (einmal Root CA, offline und zweimal Issuing CA).
Domänencontroller spricht nur LDAPs mit seinem Zertifikat (ausgestellt von einer der Issuing CAs und gültig).
Es gibt unter anderem einen Zabbix Server auf Debian 11, auf welchem bis vor kurzem LDAPs noch funktioniert hat. Das Root-CA-Zertifikat liegt dort in /usr/local/share/ca-certificates/ und ist mittels
update-ca-certificates --fresh Wir haben nun den alten Domänencontroller abgelöst und durch einen neuen (logischerweise mit neuem Hostname) ersetzt. Auch ein paar Linux-Updates gab es in der Zwischenzeit. Seither funktioniert die Authentifizierung nicht mehr und schlägt fehl mit dem Fehler "Can't bind to LDAP Server". Den FQDN habe ich natürlich entsprechend in Zabbix geändert. Ein
ldapsearch -x -H ldaps://FQDN:636 In der /etc/ldap/ldap.conf steht
TLS_CACERT /etc/ssl/certs/ca-certificates.crtEin
openssl s_client -connect FQDN:636 Ich bin grad etwas am verzweifeln, was ich hier übersehe, denn mit der Option
TLS_REQCERT allowTLS_REQCERT neverHat hier einer eine Idee? Falls noch genauere Infos nötig sind stelle ich diese gerne noch zur Verfügung.
EDIT: Auf anderen Systemen (z.B. der Firewall) funktioniert die Authentifizierung einwandfrei.
Danke schonmal und Viele Grüße!
Ketanest
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6972800536
Url: https://administrator.de/contentid/6972800536
Ausgedruckt am: 19.11.2024 um 05:11 Uhr
21 Kommentare
Neuester Kommentar
Mach das ganze doch mal etwas "Verboser"
Cheers briggs
ldapsearch -d 5 -x -H ldaps://FQDN:636 
Gern:
Ketanest
ldap_url_parse_ext(ldaps://FQDN:636)
ldap_create
ldap_url_parse_ext(ldaps://FQDN:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP FQDN:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying IP-Address:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
TLS: peer cert untrusted or revoked (0x100002)
TLS: can't connect: (unknown error code).
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Ketanest
Setze mal testweise eine Umgebungsvariable und führe anschließend ldapsearch erneut aus.
Und in der
https://linux.die.net/man/5/ldap.conf
env LDAPTLS_CACERT=/path/to/certUnd in der
ldap.conf die Konfiguration entsprechend anpassen TLS_CACERT <filename> Direktivehttps://linux.die.net/man/5/ldap.conf
TLS_CACERT <filename>
Specifies the file that contains certificates for all of the Certificate Authorities the client will recognize.
Leider nicht -> gleicher Fehler.
EDIT: Das TLS_CACERT war ja schon korrekt gesetzt in der ldap.conf. Hab auch mal versucht, direkt das Root-CA-Zertifkat anzugeben, ohne Erfolg.
EDIT: Das TLS_CACERT war ja schon korrekt gesetzt in der ldap.conf. Hab auch mal versucht, direkt das Root-CA-Zertifkat anzugeben, ohne Erfolg.
Hatte meinen Kommentar noch etwas angepasst. Teste die Konfigurationsoption
TLS_CACERT in der ldap.confZitat von @6247018886:
Hatte meinen Kommentar noch etwas angepasst. Teste die Konfigurationsoption
Hatte meinen Kommentar noch etwas angepasst. Teste die Konfigurationsoption
TLS_CACERT in der ldap.confJop hab ich gesehen, ich meinen auch.
Zitat von @6247018886:
env LDAPTLS_CACERT=/path/to/certDu meintest hier vermutlich
export LDAPTLS_CACERT=/path Zitat von @ketanest112:
Du meintest hier vermutlichoder?
Nein, env geht auch, wenn man auf der gleichen Zeile direkt dahinter den ldapsearch Befehl einkippt.Zitat von @6247018886:
env LDAPTLS_CACERT=/path/to/certDu meintest hier vermutlich
export LDAPTLS_CACERT=/path
Da es ja funktioniert, wenn ich die Config-Option ins die /etc/ldap/ldap.conf reinschreibe, nimmt er die Datei offensichtlich schon für die Config her, nur scheint der Parameter für die CA-Zertifikate nicht zu greifen. Leseberechtigungen hab ich auch schon geprüft für die ca-certificates.crt, die passen auch soweit.
TLS_REQCERT allowZitat von @6247018886:
Zitat von @ketanest112:
Du meintest hier vermutlichoder?
Nein, env geht auch, wenn man auf der gleichen Zeile direkt dahinter den ldapsearch Befehl einkippt.Zitat von @6247018886:
env LDAPTLS_CACERT=/path/to/certDu meintest hier vermutlich
export LDAPTLS_CACERT=/path Ah verstehe, hab auch das mal versucht aber gleicher Fehler.
Wie hast du die Certs in der Datei angeordnet? Die Chain inkl. ROOT aneinhander gehängt, oder nur die Intermediates.
Reihenfolge beachtet? Gibt das Syslog Hinweise? Welche Updates wurden genau gefahren?
Reihenfolge beachtet? Gibt das Syslog Hinweise? Welche Updates wurden genau gefahren?
Platziere das Root und die Intermediates auch in
/etc/openldap/certs oder /etc/openldap/cacerts directory, je nach System. Das die Config das explizit angegebene Cert ignoriert ist seltsam da muss IMHO was mit dem Cert nicht stimmen. Mit welchen Parametern wurde das erstellt?
Hallo,
kann denn der Linux Rechner auf die Sperrlisten zugreifen?
Grüße
lcer
kann denn der Linux Rechner auf die Sperrlisten zugreifen?
Grüße
lcer
Zitat von @6247018886:
Wie hast du die Certs in der Datei angeordnet? Die Chain inkl. ROOT aneinhander gehängt, oder nur die Intermediates.
Reihenfolge beachtet? Gibt das Syslog Hinweise? Welche Updates wurden genau gefahren?
Wie hast du die Certs in der Datei angeordnet? Die Chain inkl. ROOT aneinhander gehängt, oder nur die Intermediates.
Reihenfolge beachtet? Gibt das Syslog Hinweise? Welche Updates wurden genau gefahren?
Es ist nur das Root-Zertifikat. EDIT: Aber selbst wenn ich die Intermediates dazu packe (egal in welcher Reihenfolge): gleicher Fehler.
Syslog spuckt nix dazu aus. Updates hab ich die "normalen" System-Updates gemacht mit apt-get update und upgrade.
Zusätzlich zum System sind n paar Pakete noch installiert (dnsutils, ldap-utils und so n kram) und eben der Zabbix (bestehend aus ner MySQL-Datenbank, apache2, php als apache-Modul mit diversen PHP-Modulen und dem Zabbix-Server selbst).
Zitat von @6247018886:
Platziere das Root und die Intermediates auch in
Platziere das Root und die Intermediates auch in
/etc/openldap/certs oder /etc/openldap/cacerts directory, je nach System. Das die Config das explizit angegebene Cert ignoriert ist seltsam da muss IMHO was mit dem Cert nicht stimmen. Mit welchen Parametern wurde das erstellt?Bei mir ist es /etc/ldap, da gibts aber keine Unterverzeichnisse. Aber selbst wenn ich die anlege und die Config dahingehend anpasse ändert es nicht.
Was genau meinst du mit Parametern? Ist ein Auto-Deploy Zertifikat über die Windows-PKI. 2048 bit RSA.
Guter Punkt. Im Zertifkat gibt es zwei Sperrlisten-Verteilungspunkte: http und LDAP. Auf die Sperrliste, die über HTTP erreichbar ist, kann jeder im Netzwerk zugreifen, auf LDAP natürlich nur authentifizierte Clients. Kann das tatsächlich ein Problem sein, wenn eins davon nicht geht? Nen OCSP-Responder gibts übrigens auch.
Ketanest
Zumindest eine der angegebenen Stellen sollte für den Client immer erreichbar sein.
Was genau meinst du mit Parametern? Ist ein Auto-Deploy Zertifikat über die Windows-PKI. 2048 bit RSA.
Meinte die Usage und ExtendedUsage Felder etc. OK, dann sollte das wohl passen wenn die Vorlage auch stimmig ist.Zitat von @6247018886:
Zumindest eine der angegebenen Stellen sollte für den Client immer erreichbar sein.
Ja, habs nochmal geprüft, die CRL via http kann man vom Debian aus herunterladen.Zumindest eine der angegebenen Stellen sollte für den Client immer erreichbar sein.
Was genau meinst du mit Parametern? Ist ein Auto-Deploy Zertifikat über die Windows-PKI. 2048 bit RSA.
Meinte die Usage und ExtendedUsage Felder etc. OK, dann sollte das wohl passen wenn die Vorlage auch stimmig ist.Response Verify Failure
Verify error:unable to get local issuer certificate
FQDN.crt: good
This Update: Apr 24 16:46:01 2023 GMT
Next Update: May 2 05:06:01 2023 GMTZitat von @ketanest112:
Achso, ja das war die Vorlage von der Windows PKI. Was mich etwas wundert, ich hab mal ne OCSP-Prüfung gemacht, die ergab:
Zitat von @6247018886:
Zumindest eine der angegebenen Stellen sollte für den Client immer erreichbar sein.
Ja, habs nochmal geprüft, die CRL via http kann man vom Debian aus herunterladen.Zumindest eine der angegebenen Stellen sollte für den Client immer erreichbar sein.
Was genau meinst du mit Parametern? Ist ein Auto-Deploy Zertifikat über die Windows-PKI. 2048 bit RSA.
Meinte die Usage und ExtendedUsage Felder etc. OK, dann sollte das wohl passen wenn die Vorlage auch stimmig ist.Response Verify Failure
Verify error:unable to get local issuer certificate
FQDN.crt: good
This Update: Apr 24 16:46:01 2023 GMT
Next Update: May 2 05:06:01 2023 GMTAh hat sich gerade erledigt, hab die Zertifikate durcheinander gebracht. Jetzt sagt er mir "nur" noch:
Verify error:unhandled critical extension
Hallo,
nur interessehalber - geht es wieder? Ich hatte gestern ein Smartcard Anmeldeproblem (Sperrliste konnte nicht überprüft werden) auf einem Windows-System - und heute geht es wieder - ohne dass ich etwas getan hätte .... ?
Grüße
lcer
nur interessehalber - geht es wieder? Ich hatte gestern ein Smartcard Anmeldeproblem (Sperrliste konnte nicht überprüft werden) auf einem Windows-System - und heute geht es wieder - ohne dass ich etwas getan hätte .... ?
Grüße
lcer
Zitat von @lcer00:
Hallo,
nur interessehalber - geht es wieder? Ich hatte gestern ein Smartcard Anmeldeproblem (Sperrliste konnte nicht überprüft werden) auf einem Windows-System - und heute geht es wieder - ohne dass ich etwas getan hätte .... ?
Grüße
lcer
Hallo,
nur interessehalber - geht es wieder? Ich hatte gestern ein Smartcard Anmeldeproblem (Sperrliste konnte nicht überprüft werden) auf einem Windows-System - und heute geht es wieder - ohne dass ich etwas getan hätte .... ?
Grüße
lcer
Leider nicht. Werde wohl damit vorlieb nehmen, dass das Zertifikat nicht geprüft wird... Nicht geil aber geht halt aktuell nicht anders.
Danke trotzdem an euch alle!
VG
Ketanest
