hi Russell, its pretty unclear which syntax to use with the TLSCipherSuite parameter of slapd.conf ...
The old SSL syntax used with 2.3x versions of slapd was pretty clear with that and could be adapted from the openssl documentation. Today I switched a testing platform from etch to lenny (fresh install) and tried to configure the TLS setup as I did before with the latest slapd version (2.3x) under etch .. But in slapd version 2.4.11 the "TLSCipherSuite" parameter isn't working probably because its not clear how the cipher spec string should look like because the new openldap series (2.4x) is using gnutls instead of openssl. When I comment this parameter everything is working fine but I'd like to restrict the available ciphers to a (safer) minimum (based on a pattern like e.g. "HIGH" as I can do with openssl). In my old slapd.conf for example I could have specified "TLSCipherSuite HIGH:MEDIUM:+SSLv2" which was working like a charm (under 2.3x). But if a list of ciphers is specified as mentioned by slapd.conf(5) for example: TLSCipherSuite TLS_DHE_PSK_SHA_3DES_EDE_CBC_SHA1:TLS_DHE_PSK_SHA_AES_256_CBC_SHA1 or even with a whitespace instead of the colon, its still not working. When the ciphers are separated by whitespaces I'm able to start slapd but I'm not able to connect and even gnutls-cli-debug can't connect to the ldap host (neither via implicit SSL connection via port 636 nor via STARTTLS over port 389). As I already mentioned above - when I remove the TLSCipherSuite parameter from slapd.conf everything (including gnutls-cli-debug) is working again (tested with ldap-utils, jxplorer, ldapadmin [...])... The gnutls syntax is described within the gnutls-cli(1) manpage and it further says that "NORMAL:!AES-128-CBC" for example should be fine to use. I tried many combinations but nothing seemed to work ... To me it looks like that slapd is expecting the old SSL syntax which is obviously deprecated since the openldap 2.4 release which makes openssl needless and introduces gnutls as the default implementation for SSL/TLS handling. I searched the web for about 2 hours to find a solution and I dont want to exclude the possibility that I maybe missed something. But if thats so then it was never harder to find a piece of documentation then this time .. If found this thread at "http://www.openldap.org/its/index.cgi/?findid=6251"; but the suggestions also didn't worked for me (maybe because its about version 2.4.17).. Message #24 of "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541256"; describes my problem at best but at the end of this report a statement from Howard Chu says that it wasn simply a bad decision to implement gnutls with openlda .. the reasons are given within that thread but is there something we can do to fix this behaviour? Any suggestions? best regards jan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
