OpenLDAP + TLS

S

Serow

0
Hi, versuch verbringe jetzt schon 2 Tage mit OpenLDAP und TLS ... das LDAP an sich scheint zu funktioineren nur will TLS nicht.

Das hier sollte ja reichen um TLS zu konfigurieren.

cn=config.ldif
Code: 
...
olcTLSCACertificateFile: /etc/pki/CA/certs/cacert.pem
olcTLSCertificateFile: /etc/pki/CA/certs/soc-ldap.crt
olcTLSCertificateKeyFile: /etc/pki/CA/private/soc-ldap.key
...

Ich starte slapd momenten mit

Code: 
slapd -F /etc/openldap/slapd.d/ -h ldaps:/// ldap:/// ldapi:/// -d any
und bekomme bei einem Verbindungsaufbau das hier zu sehen:

Code: 
daemon: activity on 1 descriptor
daemon: activity on:
slap_listener_activate(7): 
daemon: epoll: listen=7 busy
daemon: epoll: listen=8 active_threads=0 tvp=zero
>>> slap_listener(ldaps:///)
daemon: listen=7, new connection on 12
daemon: added 12r (active) listener=(nil)
conn=1000 fd=12 ACCEPT from IP=192.168.0.201:46526 (IP=0.0.0.0:636)
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 12r
daemon: read active on 12
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
connection_get(12)
connection_get(12): got connid=1000
connection_read(12): checking for input on id=1000
connection_read(12): TLS accept failure error=-1 id=1000, closing
connection_closing: readying conn=1000 sd=12 for close
connection_close: conn=1000 sd=12
daemon: removing 12
conn=1000 fd=12 closed (TLS negotiation failure)
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero

Wireshark zeigt mit das Client Hello gefolgt ACK, dann FIN,ACK und RST,ACK. Dh die Kommunikation ist ziemlich schnell zuende^^

Ich habe slapd auch mal mit strace gestartet und dabei festgestellt, dass er die Zertifikatsdateien überhaupt nicht einließt oder sowas. Auch sehr merkwürdig.

Grüße
serow
 
Auf welchem Betriebssystem läuft denn der Server?
Ich hatte vor etwa zwei Jahren ähnliche Probleme unter Debian, auf https://wiki.debian.org/LDAP/OpenLDAPSetup#Configuring_LDAPS sind ein paar mögliche Probleme gelistet. U.a. kann die Ursache sein, dass du das Zertifikat mit OpenSSL und nicht mit gnutls erstellt hast.

Viel Glück, ich habe nach auch etwa zwei Tagen aufgegeben weil LDAP sowieso nur lokal genutzt wurde :wink:
 
Moin

Hast Du in deinem olcTLSCACertificateFile alle Zertifikate der Kette eingetragen?
Kennt dein Client das CA-Zertifikat?
Ich würde noch: "olcTLSVerifyClient: never" erwarten

Was sagt openssl, wenn Du im debugmodus zu deinem LDAP-Server connectest?

Sentrax
 
Hi, das läuft auf CentOS 6.4. Wegen der CA hab ich eignentlich ein Tutorial befolgt in dem die CA mit openssl aufgesetzt wurde.
 
Wo liegt denn der Unterschied zwischen OpenSSL und GNUTLS Zertifikaten? Kann doch nicht sein, dass man mit OpenSSL anfängt seine CA zu bauen und findet dann irgend ein Stück Software, das damit nicht spielen will...
 
@Sentrax: Sorry deine Antwort hatte ich zuerst übersehen:

Code: 
# openssl s_client -connect <FQDN>:636 --showcerts
CONNECTED(00000003)
139906489751368:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
----
no peer certificate available
----
No client certificate CA names sent
----
SSL handshake has read 0 bytes and written 112 bytes
----
New, (None), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
....
#
 
Moin

Das sieht so aus, als stimmten deine Zertifikate nicht.

Überprüfe die bitte alle noch mal.
- CA-Zertifikate in der Chain
- CA-Zertifikat auf dem Client
- Server-Zertifikat

Sentrax
 
Hallo mime,

danke für den Hinweis. Verhält sich aber auf Port 389 ganz genauso.


@Sentrax:

Hier hab alles was public ist, nur um mal reinzuschauen. Die eigentlichen Keys habe ich mal weggelssen.

cacert.pem
Code: 
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

soc-ldap.crt
Code: 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=DE, ST=***, L=*****************, O=***********, OU=*********, CN=********/emailAddress=*************
        Validity
            Not Before: Sep 24 08:33:44 2013 GMT
            Not After : Sep 24 08:33:44 2014 GMT
        Subject: C=DE, ST=***, L=*****************, O=***********, OU=*********, CN=********/emailAddress=*************
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    ....
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                ...
            X509v3 Authority Key Identifier: 
                keyid:...

    Signature Algorithm: sha1WithRSAEncryption
        ...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

soc-ldap.key
Code: 
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----

So sehen die Dinger aus und ich verstehe nicht was OpenLDAP daran auszusetzen haben könnte ...


Grüße
serow
 
Ok, das macht auch mehr Sinn :D tls2 gibt es bei mir nicht, genauso wenig wie tls1_2. Ich habs stattdessen einfach mal mit tls1 probiert:

Code: 
# openssl s_client -tls1 -connect 192.168.0.14:389
CONNECTED(00000003)
###########:error:########:SSL routines:SSL23_WRITE_BYTES:ssl handshake failure:s23_pkt.c:594:
----
no peer certificate available
----
No client certificate CA names sent.
----
SSL handshake has read 0 bytes and written 0 bytes.
----
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
  Protocol: TLSv1
  Cipher: 0000
  Session-ID: 
  Session-ID-ctx:
  Master-Key:
  Key-Arg: None
  Krb5 Principal:None
  PSK identity: None
  PSK identity hint: None
  Start Time: *************
  Timeout: 7200 (sec)
  Verify return code: 0 (ok)
----

Um nochmal auf die Zertifikate zurückzukommen: Der Tatsache, dass ich in strace kein open auf irgendeines der Files sehe, schubst mich gedanklich eher in Richtung einer Fehlkonfiguration statt kaputter Zertifikate oder sowas... Sieht das jemand anders?
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben