May 01, 2023, updated at May 02, 2023 (UTC)

2961

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 mittels

update-ca-certificates --fresh

ins 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. Ein

ldapsearch -x -H ldaps://FQDN:636

ergibt ein "Can't contact LDAP server (-1)".

In der /etc/ldap/ldap.conf steht

TLS_CACERT /etc/ssl/certs/ca-certificates.crt

drin, das sollte also eigentlich passen.
Ein

openssl s_client -connect FQDN:636

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

TLS_REQCERT allow

und

TLS_REQCERT never

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

Please also mark the comments that contributed to the solution of the article

Content-Key: 6972800536

Url: https://administrator.de/contentid/6972800536

Printed on: April 27, 2024 at 06:04 o'clock

21 Comments

Latest comment

Mach das ganze doch mal etwas "Verboser"

ldapsearch -d 5 -x -H ldaps://FQDN:636

Cheers briggs

Gern:

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.
env LDAPTLS_CACERT=/path/to/cert

Und in der ldap.conf die Konfiguration entsprechend anpassen TLS_CACERT <filename> Direktive
https://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.

Hatte meinen Kommentar noch etwas angepasst. Teste die Konfigurationsoption TLS_CACERT in der ldap.conf

Zitat von @6247018886:

Hatte meinen Kommentar noch etwas angepasst. Teste die Konfigurationsoption TLS_CACERT in der ldap.conf

Jop hab ich gesehen, ich meinen auch.

Zitat von @6247018886:
env LDAPTLS_CACERT=/path/to/cert

Du meintest hier vermutlich

export LDAPTLS_CACERT=/path

oder?

Zitat von @ketanest112:

Zitat von @6247018886:
env LDAPTLS_CACERT=/path/to/cert

Du meintest hier vermutlich

export LDAPTLS_CACERT=/path

oder?

Nein, env geht auch, wenn man auf der gleichen Zeile direkt dahinter den ldapsearch Befehl einkippt.

Da es ja funktioniert, wenn ich die Config-Option

TLS_REQCERT allow

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.

Zitat von @6247018886:

Zitat von @ketanest112:

Zitat von @6247018886:
env LDAPTLS_CACERT=/path/to/cert

Du meintest hier vermutlich

export LDAPTLS_CACERT=/path

oder?

Nein, env geht auch, wenn man auf der gleichen Zeile direkt dahinter den ldapsearch Befehl einkippt.

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?

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

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?

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 /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.

Zitat von @lcer00:

Hallo,

kann denn der Linux Rechner auf die Sperrlisten zugreifen?

Grüße

lcer

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

Zitat von @ketanest112:
Kann das tatsächlich ein Problem sein, wenn eins davon nicht geht?

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:

Zitat von @ketanest112:
Kann das tatsächlich ein Problem sein, wenn eins davon nicht geht?

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.

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.

Achso, ja das war die Vorlage von der Windows PKI. Was mich etwas wundert, ich hab mal ne OCSP-Prüfung gemacht, die ergab:

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 GMT

Zitat von @ketanest112:

Zitat von @6247018886:

Zitat von @ketanest112:
Kann das tatsächlich ein Problem sein, wenn eins davon nicht geht?

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.

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.

Achso, ja das war die Vorlage von der Windows PKI. Was mich etwas wundert, ich hab mal ne OCSP-Prüfung gemacht, die ergab:

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 GMT

Ah 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

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

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

German Question Debian Windows Server