FusionDirectory: OpenLDAP mit SSL oder TLS

859
Richard Żak

Ich habe mich umgesehen und viel online gefunden, wie Sie TLS für OpenLDAP einrichten. Die Grundidee besteht darin, die olcTLS-Elemente hinzuzufügen, um cert, key, cacert einzuschließen cn=config.

Beim Verwenden von FusionDirectory wird jedoch versucht, zu verwenden ldapmodify, dass cn=configes nicht existiert, und wenn ich versuche zu erstellen cn=config, wird mir (als LDAP-Administrator angemeldet) angezeigt, dass ich nicht über die Rechte zum Erstellen der Datei verfügt. Ich habe diese Anweisungen befolgt.

Also habe ich die Datei bearbeitet /etc/ldap/slapd.d/cn=config.ldif, um folgende Elemente hinzuzufügen:

olcTLSCACertificate: /etc/ssl/certs/ca.cert olcTLSCertificateFile: /etc/ssl/certs/fd.cert olcTLSCertificateKeyFile: /etc/ssl/private/fd.key olcTLSCipherSuite: SECURE256 olcTLSVerifyClient: try 

Ich habe auch bearbeitet /etc/default/slapd, um aufzunehmenSLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

  • Ich habe den openldap-Benutzer zur Gruppe ssl-cert hinzugefügt.
  • Ich habe Slapd neu gestartet.
  • Mit ldapvi cn=configkann nicht gefunden werden.
  • Aber slapcat -n0 | grep -i tlszeigt die olcTLS * Einträge ich in die Datei gewaltsam hinzugefügt.
  • Mit Wireshark kann ich feststellen, dass der Server, wenn der Client START_TLS anfordert, in Ordnung ist und unterstützte Verschlüsselungen anzeigt. Der Client beginnt mit einem SSL-Hallo und der Server antwortet mit TCP FIN.
  • nmapZeigt an, dass die Ports 389 und 636 offen sind, und zeigt auch die Zertifikatinformationen (Aussteller: commonName = MyServer / organizationName = Testing), öffentlichen Schlüsseltyp: rsa, öffentliche Schlüsselbits: 4096 und die MD5- und SHA1-Hashes des Zertifikats. Es ist also in der Lage, das Zertifikat und den Schlüssel zu lesen. Die Berechtigungen sind in Ordnung.

SSL- (636) und TLS (389) -Verbindungen schlagen jedoch fehl. Unverschlüsselte 389 Verbindungen funktionieren einwandfrei, mit der Ausnahme, dass ich in Wireshark zu viele Informationen sehe und es mir unangenehm ist.

Also, was ist der Deal hier?

  • OS ist Debian Jessie 8.7
  • FusionDirectory 1.0.20
  • OpenLDAP 2.4.40
  • Mit gnomint mit TLS-Erweiterungen erstellte Zertifikate .

Bearbeiten Sie den 15. Mai 2017:

Ich lief openssl s_client -connect host.local -showcertsund es zeigte das Zertifikat, verhandelte Chiffren usw.

Client Certificate Types: RSA sign, DSA sign, ECDSA sign Requested Signature Algorithms:  RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512 Shared Requested Signature Algorithms:  RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512 Peer signing digest: SHA512 Server Temp Key: ECDH, P-521, 521 bits --- SSL handshake has read 4512 bytes and written 511 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 5120 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 37EAADA00459F296BE972FB57B4A5.... Session-ID-ctx:  Master-Key: 0F865CBEDA755F84E783..... Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1494883911 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- 

Funktioniert jedoch ldapsearchnicht:

# ldapsearch -H ldaps://host.local:636 -xLL -v ldap_initialize( ldaps://host.local:636/??base ) ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) 

Der SSL-Teil funktioniert also, der Rest aber nicht.

1

0 Antworten auf die Frage