Ldap + Tls

[LamePL]

DISTRI: Debian "Etch"
openLDAP+phpldapadmin

Ich habe folgendes Problem:

Ich habe mir einen LDAP-Server aufgesetzt, der ohne Verschlüsselung wunderbar funktionert. Da ich aber nach wie vor ein Fan von Sicherheit bin, möchte ich Verschlüsselung natürlich auch (gerade) in diesem Bereich einsetzen. Wie es in mehreren Verschiedenen HowTOs (z.B. http://www.linux-club.de/ftopic28221.html) beschrieben ist habe ich folgerndermaßen CAs und Keys für TLS erstellt

# /usr/lib/ssl/misc/CA.pl -newca
# /usr/lib/ssl/misc/CA.pl -newreq
# /usr/lib/ssl/misc/CA.pl -signcert

... sie entsprechend in die einzelnen Verzeichnisse kopiert

# cp demoCA/ca.cert /etc/ssl/certs
# cp newcert.pem /usr/local/etc/openldap/certs/servercrt.pem
# cp newreq.pem /usr/local/etc/openldap/certs/serverkey.pem

... und die Konfigurationsdateien angepasst


slapd.conf:

TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCertificateFile /usr/local/etc/openldap/certs/servercrt.pem
TLSCertificateKeyFile /usr/local/etc/openldap/certs/serverkey.pem
TLSCACertificateFile /etc/ssl/certs/cacert.pem
TLSVerifyClient allow

ldap.conf:

TLS_CACERT /etc/ssl/certs/cacert.pem

Resultat:

# tail /var/log/syslog

Oct 26 20:17:37 XXXXXX slapd[3805]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 17:48:39) $ ^Iroot@XXXXXX:/usr/src/openldap-2.3.28/servers/slapd
Oct 26 20:17:37 XXXXXX slapd[3805]: main: TLS init def ctx failed: -1
Oct 26 20:17:37 XXXXXX slapd[3805]: slapd stopped.
Oct 26 20:17:37 XXXXXX slapd[3805]: connections_destroy: nothing to destroy.
Oct 26 20:25:29 XXXXXX slapd[3814]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 17:48:39) $ ^Iroot@XXXXXX:/usr/src/openldap-2.3.28/servers/slapd
Oct 26 20:25:29 XXXXXX slapd[3814]: main: TLS init def ctx failed: -1
Oct 26 20:25:29 XXXXXX slapd[3814]: slapd stopped.
Oct 26 20:25:29 XXXXXX slapd[3814]: connections_destroy: nothing to destroy.

Was sollen mir diese Zeilen sagen bzw. wie kann ich dieses Problem lösen?
ich habe bereits gegooglet, konnte mit den Dingen die ich dort fand nichts anfangen oder sie haben nicht funktioniert (wie z.B. die Sache mit den Zugriffsrechten). Das System hat auch keinen User 'ldap', wie es in den meisten Dokus beschrieben ist.

Ich hoffe mir kann jemand helfen...

[cane]

Unter welchem user rennt denn der ldap-server?

das mal angesehen:
http://www.mail-archive.com/openldap-software@openldap.org/msg04201.html

mfg
cane

[LamePL]

Danke erstmal für die prompte Antwort!

Es läuft als root und die Zertifikatsdateien:

-rwxr-x--- 1 root root 3208 2006-10-26 19:04 cacert.pem
-rwxr-x--- 1 root root 3242 2006-10-26 19:06 servercrt.pem
-rwxr-x--- 1 root root 700 2006-10-26 19:05 serverkey.pem

# openssl x509 -in /etc/ssl/certs/cacert.pem -noout -text ist erfolgreich und zeigt mir den Inhalt des Zertifikats.

Könnte es sein, dass 'slapd' nicht als root ausgeführt werden darf? Mit Zugriffsrechten denke ich kann das jedenfalls nichts zu tun haben, 'slapd' ist dann ja root und der darf bekanntlich alles.

[cane]

http://www.openldap.org/lists/openldap-software/200304/msg00984.html

Die certs könnten das Problem sein --> setz mal den Loglevel hoch...

Wenn Du ein Fan von Sicherheit bist --> warum benutzt Du dann Etch das sicherheitstechnisch IMO nur sporadisch geupdated wird und nicht mal ein eigenes Security-Team hat?

mfg
cane

[LamePL]

Also, ich benutze Etch, weil ich mit Debian (bis vor 1 Woche wars noch Sarge) bisher immer gut gefahren bin und keinerlei sicherheitstechnische Probleme hatte (bisher). Außerdem denke ich, dass es jetzt langsam Zeit geworden ist mein System auf testing umzustellen (zum Testen). Sarge kann ich jederzeit wieder raufhauen, hab nen Backup davon.

Problem mit den Certs kann sein.Nur wie finde ich das heraus? Ich kennen keine anderen Wege um Zertifikate zu erstellen. Könnte mir jemand ein kurzes HowTO posten? Ich habe schon mehreres probiert, war aber bis auf die o.g. Methode erfolglos :(

Achja, slapd.conf -> loglevel 3968 ergibt genau den selben output:

Oct 26 23:17:21 XXXXXX slapd[4078]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 17:48:39) $ ^Iroot@XXXXXX:/usr/src/openldap-2.3.28/servers/slapd
Oct 26 23:17:21 XXXXXX slapd[4078]: main: TLS init def ctx failed: -1
Oct 26 23:17:21 XXXXXX slapd[4078]: slapd stopped.
Oct 26 23:17:21 XXXXXX slapd[4078]: connections_destroy: nothing to destroy.

Noch etwas... An diesem Problem ist nicht Etch schuld! Ich habe auf der Arbeit genau die gleichen Probleme mit SLES9. Ebenfalls OpenLDAP in Kombi mit phpLDAPadmin

[cane]

Unter SLES hast Du aber sicherlich die CA von SLES benutzt und damit Certs erzeugt, oder?

Generier mal so:
http://www.openssl.org/docs/HOWTO/certificates.txt

mfg
cane

[LamePL]

So, nun habe ich allem anschein nach gültige Zertifkate (slapd startet wieder). Nur finde ich keine für den Client. Ich bekomme den folgenden Output:

TLS trace: SSL_accept:SSLv3 flush data
tls_read: want=5 error=Resource temporarily unavailable
TLS trace: SSL_accept:error in SSLv3 read client certificate A
TLS trace: SSL_accept:error in SSLv3 read client certificate A
daemon: select: listen=7 active_threads=0 tvp=NULL
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, err: 19, subject: /C=DE/ST=Germany/L=Bremen/O=NordIT/OU=NordIT/CN=nitlinc1.nit.de/emailAddress=pmikulastik@nordit.de, issuer: /C=DE/ST=Germany/L=Bremen/O=NordIT/OU=NordIT/CN=nitlinc1.nit.de/emailAddress=pmikulastik@nordit.de
TLS certificate verification: Error, self signed certificate in certificate chain
daemon: activity on 1 descriptor
daemon: activity on: 11r
daemon: read active on 11
connection_get(11)
connection_get(11): got connid=1
connection_read(11): checking for input on id=1
tls_read: want=5, got=5
0000: 15 03 01 00 02 .....
tls_read: want=2, got=2
0000: 02 30 .0
TLS trace: SSL3 alert read:fatal:unknown CA
TLS trace: SSL_accept:failed in SSLv3 read client certificate A
TLS: can't accept.
TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca s3_pkt.c:1052
connection_read(11): TLS accept failure error=-1 id=1, closing
connection_closing: readying conn=1 sd=11 for close
connection_close: conn=1 sd=11
daemon: removing 11
conn=1 fd=11 closed (TLS negotiation failure)
daemon: select: listen=7 active_threads=0 tvp=NULL
daemon: activity on 1 descriptor
daemon: activity on:
daemon: select: listen=7 active_threads=0 tvp=NULL
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS: can't connect.
ldap_perror
ldap_bind: Can't contact LDAP server (-1)
additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Kann mir jemand sagen welche von den hier (http://www.faveve.uni-stuttgart.de/it/auth/ldap-server.php) erstellen Dateien ich wo eintragen muss?? Ich kapiert das nicht!

[arccosx]

Kann mir jemand sagen welche von den hier (http://www.faveve.uni-stuttgart.de/it/auth/ldap-server.php) erstellen Dateien ich wo eintragen muss?? Ich kapiert das nicht!


So wie ich das verstehe, müsste das danach wie folgt aussehen:

ldap.conf:


# OpenLDAP SSL options
# Require and verify server certificate (yes/no)
# Default is to use libldap's default behavior, which can be configured in
# /etc/openldap/ldap.conf using the TLS_REQCERT setting. The default for
# OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes".
tls_checkpeer yes

# CA certificates for server certificate verification
# At least one of these are required if tls_checkpeer is "yes"
tls_cacertfile /etc/ssl/CA/ca.cert.pem

#tls_cacertdir /etc/ssl/certs
slapd.conf:


TLSCertificateFile /etc/ssl/certs/ldap.cert.pem
TLSCACertificateFile /etc/ssl/CA/ca.cert.pem
TLSCertificateKeyFile /etc/ssl/private/ldap.key.pem
Habe mich am gleichen HowTo entlanggehangelt, aber bei mir kommt danach leider immernoch der "TLS negotiation failure".
Um dem ganzen Problem ein Ende zu bereiten, kannst du in der ldap.conf den Eintrag


tls_checkpeer yes
auf


tls_checkpeer no
setzen.
Die Verbindung bleibt verschlüsselt. Das einzige Risiko, dass du jetzt noch eingehst ist eine "Man in the Middle" Attacke.

Hoffe das hilft dir.

Wenn jemand allerdings eine Lösung kennt, ohne tls_checkpeer auszuschalten, wäre auch ich ihm dafür dankbar :D