Bug#462588: Same problem
Steve Langasek wrote: Please try setting 'TLSVerifyClient allow' in your slapd.conf, and let us know whether that fixes the problem for you. In my tests, I see that the default client certificate handling for 2.4.7 with GnuTLS does not match what's documented in the slapd.conf manpage; I think we have another bug here that will need tracking down. You are right, this fixes the problem. Thanks! Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: Same problem
On Sun, Feb 03, 2008 at 05:29:47PM -0800, Russ Allbery wrote: I'm pretty sure I don't want to implement support for migrating the full set of OpenSSL cipher specs in shell. :P Do you think converting the above aliases would be good enough coverage? Or do we need to provide some upgrade handling for all the possibilities, and therefore we're doomed to add yet another debconf error message here? In the latter case I'm probably not going to spend the effort on auto-migrating any of the values. I would just comment out the cipher list directive completely on upgrade and document the need to correct it manually if desired in NEWS.Debian. The most common use of this directive is to restrict use of weak ciphers, which GnuTLS doesn't support in the first place. My natural inclination here then is to still make this a debconf error message, when one of these TLSCipherSuite lines is detected. It's not nice to translators, but an untranslatable NEWS.Debian file isn't nicer to users than an untranslated debconf template anyway, and with a debconf error we can directly notify the users whose configs have had to be changed. It is unforunate that GnuTLS doesn't support the same general keywords as OpenSSL, and it seems like that would be easy enough for GnuTLS to add. Maybe a wishlist bug against GnuTLS is in order? Filed as bug #464625. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
A patch has been committed to the package svn tree to fix handling of cipher lists, which leaves this issue: On Tue, Jan 29, 2008 at 11:09:32AM -0800, Steve Langasek wrote: I'm not sure if we should also try to migrate the OpenSSL-specific cipher specs to GNUTLS equivalents as part of the package upgrade. I had a poke around http://www.openssl.org/docs/apps/ciphers.html, which lists all the various keywords recognized by OpenSSL. Mapping these onto the known GnuTLS ciphers using 'openssl ciphers -v' and 'gnutls-cli -l', here's what I get: MEDIUM - TLS_ANON_DH_ARCFOUR_MD5:TLS_RSA_ARCFOUR_SHA1:TLS_RSA_ARCFOUR_MD5 HIGH - TLS_ANON_DH_AES_256_CBC_SHA1:TLS_DHE_RSA_AES_256_CBC_SHA1:TLS_DHE_DSS_AES_256_CBC_SHA1:TLS_RSA_AES_256_CBC_SHA1:TLS_ANON_DH_AES_128_CBC_SHA1:TLS_DHE_RSA_AES_128_CBC_SHA1:TLS_DHE_DSS_AES_128_CBC_SHA1:TLS_RSA_AES_128_CBC_SHA1:TLS_ANON_DH_3DES_EDE_CBC_SHA1:TLS_DHE_RSA_3DES_EDE_CBC_SHA1:TLS_DHE_DSS_3DES_EDE_CBC_SHA1:TLS_RSA_3DES_EDE_CBC_SHA1 LOW - empty list DEFAULT: MED+HIGH, w/o ANON_DH, w/ TLS_RSA_EXPORT_ARCFOUR_40_MD5 EXP,EXPORT,EXPORT40 - TLS_RSA_EXPORT_ARCFOUR_40_MD5 eNULL,NULL - TLS_RSA_NULL_MD5 aNULL - TLS_ANON_DH_AES_256_CBC_SHA1:TLS_ANON_DH_AES_128_CBC_SHA1:TLS_ANON_DH_3DES_EDE_CBC_SHA1:TLS_ANON_DH_ARCFOUR_MD5 SSLv2 - empty list But this is only a partial list of the most relevant aliases; there are also aliases for each authentication, key exchange, and encryption algorithm, and OpenSSL supports various forms of negation and sorting that aren't supported here by GnuTLS. I'm pretty sure I don't want to implement support for migrating the full set of OpenSSL cipher specs in shell. :P Do you think converting the above aliases would be good enough coverage? Or do we need to provide some upgrade handling for all the possibilities, and therefore we're doomed to add yet another debconf error message here? In the latter case I'm probably not going to spend the effort on auto-migrating any of the values. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Bug#462588: Bug#462588: Bug#462588: Same problem
On Wed, Jan 30, 2008 at 12:42:01AM +0100, T.A. van Roermund wrote: So my FQDN (server-timo.van-roermund, double checked with hostname -f) is now part of subjectAltName. However, it still doesn't work. Please try setting 'TLSVerifyClient allow' in your slapd.conf, and let us know whether that fixes the problem for you. In my tests, I see that the default client certificate handling for 2.4.7 with GnuTLS does not match what's documented in the slapd.conf manpage; I think we have another bug here that will need tracking down. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: Same problem
Steve Langasek [EMAIL PROTECTED] writes: I'm pretty sure I don't want to implement support for migrating the full set of OpenSSL cipher specs in shell. :P Do you think converting the above aliases would be good enough coverage? Or do we need to provide some upgrade handling for all the possibilities, and therefore we're doomed to add yet another debconf error message here? In the latter case I'm probably not going to spend the effort on auto-migrating any of the values. I would just comment out the cipher list directive completely on upgrade and document the need to correct it manually if desired in NEWS.Debian. The most common use of this directive is to restrict use of weak ciphers, which GnuTLS doesn't support in the first place. It is unforunate that GnuTLS doesn't support the same general keywords as OpenSSL, and it seems like that would be easy enough for GnuTLS to add. Maybe a wishlist bug against GnuTLS is in order? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Bug#462588: Same problem
Quanah Gibson-Mount wrote: Ok. Does your certificate have a proper cn, matching the fqdn of your server? That's the only other case where I can reproduce the described behavior, but I don't know if that's a behavior change relative to the OpenSSL version. (I would have hoped that OpenSSL would also refuse to negotiate SSL/TLS with a server whose cn doesn't match the hostname being connected to, since this subverts the SSL security model.) OpenLDAP compiled with OpenSSL behaves the same way. i.e, the cn in the cert must match the servername (or the fields on subjectAltName, etc). FQDN: server-timo.van-roermund.nl CN: van-roermund.nl Will that be the problem? If so, then the behaviour of GnuTLS *is* different from the behavious of OpenSSL. I will test it and let you know. Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Bug#462588: Same problem
--On Tuesday, January 29, 2008 12:09 PM -0800 Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jan 29, 2008 at 08:27:03PM +0100, T.A. van Roermund wrote: Steve Langasek wrote: Well, I can reproduce the problem when using this value for TLSCipherSuite. But why would you set this value, rather than leaving TLSCipherSuite blank to use the default? I don't see the point of listing *all* the cipher types if you don't intend to exclude some of them. If I leave it blank, it still doesn't work. The behaviour is then exactly equal to the current situation. Ok. Does your certificate have a proper cn, matching the fqdn of your server? That's the only other case where I can reproduce the described behavior, but I don't know if that's a behavior change relative to the OpenSSL version. (I would have hoped that OpenSSL would also refuse to negotiate SSL/TLS with a server whose cn doesn't match the hostname being connected to, since this subverts the SSL security model.) OpenLDAP compiled with OpenSSL behaves the same way. i.e, the cn in the cert must match the servername (or the fields on subjectAltName, etc). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
On Sat, Jan 26, 2008 at 12:33:28PM +0100, T.A. van Roermund wrote: # all cipher suites as currently supported by gnutls, # constructed using command: # gnutls-cli -l | grep -E ^TLS | cut -d\ -f1 | xargs echo TLSCipherSuite TLS_ANON_DH_ARCFOUR_MD5 TLS_ANON_DH_3DES_EDE_CBC_SHA1 TLS_ANON_DH_AES_128_CBC_SHA1 TLS_ANON_DH_AES_256_CBC_SHA1 TLS_PSK_SHA_ARCFOUR_SHA1 TLS_PSK_SHA_3DES_EDE_CBC_SHA1 TLS_PSK_SHA_AES_128_CBC_SHA1 TLS_PSK_SHA_AES_256_CBC_SHA1 TLS_DHE_PSK_SHA_ARCFOUR_SHA1 TLS_DHE_PSK_SHA_3DES_EDE_CBC_SHA1 TLS_DHE_PSK_SHA_AES_128_CBC_SHA1 TLS_DHE_PSK_SHA_AES_256_CBC_SHA1 TLS_SRP_SHA_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_AES_128_CBC_SHA1 TLS_SRP_SHA_AES_256_CBC_SHA1 TLS_SRP_SHA_DSS_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_RSA_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_DSS_AES_128_CBC_SHA1 TLS_SRP_SHA_RSA_AES_128_CBC_SHA1 TLS_SRP_SHA_DSS_AES_256_CBC_SHA1 TLS_SRP_SHA_RSA_AES_256_CBC_SHA1 TLS_DHE_DSS_ARCFOUR_SHA1 TLS_DHE_DSS_3DES_EDE_CBC_SHA1 TLS_DHE_DSS_AES_128_CBC_SHA1 TLS_DHE_DSS_AES_256_CBC_SHA1 TLS_DHE_RSA_3DES_EDE_CBC_SHA1 TLS_DHE_RSA_AES_128_CBC_SHA1 TLS_DHE_RSA_AES_256_CBC_SHA1 TLS_RSA_NULL_MD5 TLS_RSA_EXPORT_ARCFOUR_40_MD5 TLS_RSA_ARCFOUR_SHA1 TLS_RSA_ARCFOUR_MD5 TLS_RSA_3DES_EDE_CBC_SHA1 TLS_RSA_AES_128_CBC_SHA1 TLS_RSA_AES_256_CBC_SHA1 Before, using OpenSSL, everything worked perfectly. Now, LDAPS is completely broken. Well, I can reproduce the problem when using this value for TLSCipherSuite. But why would you set this value, rather than leaving TLSCipherSuite blank to use the default? I don't see the point of listing *all* the cipher types if you don't intend to exclude some of them. Anyway, the documented syntax for TLSCipherSuite is $cipher1:$cipher2, not $cipher1 $cipher2; but setting such values gives me a hang on startup (which should be investigated). I see that if I leave the cipher list blank, gnutls-cli negotiates TLS_RSA_AES_256_CBC_SHA; so if I set TLSCipherSuite TLS_RSA_AES_256_CBC_SHA, it works just fine. The full list of ciphers that gnutls clients appear to negotiate by default is: TLS_DHE_RSA_AES_256_CBC_SHA, TLS_DHE_RSA_AES_128_CBC_SHA, TLS_DHE_RSA_3DES_EDE_CBC_SHA, TLS_DHE_DSS_AES_256_CBC_SHA, TLS_DHE_DSS_AES_128_CBC_SHA, TLS_DHE_DSS_3DES_EDE_CBC_SHA, TLS_DHE_DSS_RC4_128_SHA, TLS_RSA_AES_256_CBC_SHA, TLS_RSA_AES_128_CBC_SHA, TLS_RSA_3DES_EDE_CBC_SHA, TLS_RSA_RC4_128_SHA, TLS_RSA_RC4_128_MD5 So if you don't want to use the default cipher settings, you can perhaps choose one of these ciphers individually that meets your needs. The fact that ldap_pvt_tls_set_option() hangs indefinitely when given a list of more than one cipher is certainly a bug which should be fixed. I'm not sure if we should also try to migrate the OpenSSL-specific cipher specs to GNUTLS equivalents as part of the package upgrade. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
Steve Langasek wrote: Well, I can reproduce the problem when using this value for TLSCipherSuite. But why would you set this value, rather than leaving TLSCipherSuite blank to use the default? I don't see the point of listing *all* the cipher types if you don't intend to exclude some of them. If I leave it blank, it still doesn't work. The behaviour is then exactly equal to the current situation. Anyway, the documented syntax for TLSCipherSuite is $cipher1:$cipher2, not $cipher1 $cipher2; but setting such values gives me a hang on startup (which should be investigated). I can confirm that, the reason why I left out the : is this hang. I thought that maybe gnutls parses the string differently and needs spaces in between, that's why I replaced those characters with spaces. Anyway, do you file a bug report for this hang? I see that if I leave the cipher list blank, gnutls-cli negotiates TLS_RSA_AES_256_CBC_SHA; so if I set TLSCipherSuite TLS_RSA_AES_256_CBC_SHA, it works just fine. How exactly do you find out? Then I might try the same on my PC. The full list of ciphers that gnutls clients appear to negotiate by default is: TLS_DHE_RSA_AES_256_CBC_SHA, TLS_DHE_RSA_AES_128_CBC_SHA, TLS_DHE_RSA_3DES_EDE_CBC_SHA, TLS_DHE_DSS_AES_256_CBC_SHA, TLS_DHE_DSS_AES_128_CBC_SHA, TLS_DHE_DSS_3DES_EDE_CBC_SHA, TLS_DHE_DSS_RC4_128_SHA, TLS_RSA_AES_256_CBC_SHA, TLS_RSA_AES_128_CBC_SHA, TLS_RSA_3DES_EDE_CBC_SHA, TLS_RSA_RC4_128_SHA, TLS_RSA_RC4_128_MD5 So if you don't want to use the default cipher settings, you can perhaps choose one of these ciphers individually that meets your needs. None of thise ciphers seems to work (at least in combination with Thunderbird). I'm not sure if we should also try to migrate the OpenSSL-specific cipher specs to GNUTLS equivalents as part of the package upgrade. That might be a good idea. Best regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Bug#462588: Bug#462588: Same problem
--On Tuesday, January 29, 2008 10:18 PM +0100 T.A. van Roermund [EMAIL PROTECTED] wrote: FQDN: server-timo.van-roermund.nl CN: van-roermund.nl Will that be the problem? If so, then the behaviour of GnuTLS *is* different from the behavious of OpenSSL. I will test it and let you know. That would be a problem if server-timo.van-roermud.nl is not in subjectAltName for the certs. Standard OpenLDAP 2.3 against OpenSSL would also not accept that cert. I don't know why the previous debian package would have allowed it, unless it was related to the old hacked libldap libraries (are those replaced now?). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Same problem
--On Tuesday, January 29, 2008 11:09 AM -0800 Steve Langasek [EMAIL PROTECTED] wrote: Anyway, the documented syntax for TLSCipherSuite is $cipher1:$cipher2, not $cipher1 $cipher2; but setting such values gives me a hang on startup (which should be investigated). Filed upstream: http://www.OpenLDAP.org/its/index.cgi?findid=5341 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Same problem
On Tue, Jan 29, 2008 at 08:27:03PM +0100, T.A. van Roermund wrote: Steve Langasek wrote: Well, I can reproduce the problem when using this value for TLSCipherSuite. But why would you set this value, rather than leaving TLSCipherSuite blank to use the default? I don't see the point of listing *all* the cipher types if you don't intend to exclude some of them. If I leave it blank, it still doesn't work. The behaviour is then exactly equal to the current situation. Ok. Does your certificate have a proper cn, matching the fqdn of your server? That's the only other case where I can reproduce the described behavior, but I don't know if that's a behavior change relative to the OpenSSL version. (I would have hoped that OpenSSL would also refuse to negotiate SSL/TLS with a server whose cn doesn't match the hostname being connected to, since this subverts the SSL security model.) I see that if I leave the cipher list blank, gnutls-cli negotiates TLS_RSA_AES_256_CBC_SHA; so if I set TLSCipherSuite TLS_RSA_AES_256_CBC_SHA, it works just fine. How exactly do you find out? Then I might try the same on my PC. Running as root on the client: # tcpdump -i eth1 -n host borges and '(port ldap or port ldaps)' \ -s 1500 -w ~vorlon/ldaps.pcap then attempt to connect to the server from the client, ctrl-C out of tcpdump, and analyze the resulting packet capture with wireshark -r ldaps.pcap (as a non-root user). If you're testing with localhost, then you'll want to do, e.g., # tcpdump -i lo -n port ldap or port ldaps -s 1500 -w ldaps.pcap The full list of ciphers that gnutls clients appear to negotiate by default is: TLS_DHE_RSA_AES_256_CBC_SHA, TLS_DHE_RSA_AES_128_CBC_SHA, TLS_DHE_RSA_3DES_EDE_CBC_SHA, TLS_DHE_DSS_AES_256_CBC_SHA, TLS_DHE_DSS_AES_128_CBC_SHA, TLS_DHE_DSS_3DES_EDE_CBC_SHA, TLS_DHE_DSS_RC4_128_SHA, TLS_RSA_AES_256_CBC_SHA, TLS_RSA_AES_128_CBC_SHA, TLS_RSA_3DES_EDE_CBC_SHA, TLS_RSA_RC4_128_SHA, TLS_RSA_RC4_128_MD5 So if you don't want to use the default cipher settings, you can perhaps choose one of these ciphers individually that meets your needs. None of thise ciphers seems to work (at least in combination with Thunderbird). If you're seeing this behavior even when TLSCipherSuite is left blank, then I think your failure is different than the cipher negotiation problem, and I suspect the cn problem above, or a problem with a lack of a CA configured on the client side. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Bug#462588: Bug#462588: Bug#462588: Same problem
Quanah Gibson-Mount [EMAIL PROTECTED] writes: I don't know why the previous debian package would have allowed it, unless it was related to the old hacked libldap libraries (are those replaced now?). They are, but they weren't used for the server anyway, so I'm not sure that explains it. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Bug#462588: Bug#462588: Bug#462588: Same problem
Quanah Gibson-Mount wrote: That would be a problem if server-timo.van-roermud.nl is not in subjectAltName for the certs. I changed the certificate (self signed), it now looks like this (only the relevant parts): Certificate: Data: cut Signature Algorithm: sha1WithRSAEncryption Issuer: C=NL, ST=Noord-Brabant, L=Eindhoven, O=van-roermund.nl, CN=van-roermund.nl/[EMAIL PROTECTED] cut Subject: C=NL, ST=Noord-Brabant, O=van-roermund.nl, CN=van-roermund.nl/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) cut X509v3 extensions: X509v3 Basic Constraints: CA:FALSE cut X509v3 Subject Alternative Name: DNS:van-roermund.nl, DNS:server-timo.van-roermund.nl, DNS:www.van-roermund.nl, DNS:imap.van-roermund.nl, DNS:smtp.van-roermund.nl, DNS:ftp.van-roermund.nl So my FQDN (server-timo.van-roermund, double checked with hostname -f) is now part of subjectAltName. However, it still doesn't work. Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
Quanah Gibson-Mount wrote: Have you verified that port 636 is open? I.e., telnet localhost 636 The port is open: $ telnet localhost 636 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. And: $ netstat --listening --numeric --program | grep slapd tcp0 0 127.0.0.1:389 0.0.0.0:* LISTEN 23763/slapd tcp0 0 0.0.0.0:636 0.0.0.0:* LISTEN 23763/slapd (And ldapsearch is still unable to connect.) Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Same problem
Quanah Gibson-Mount wrote: Have you verified whether or not you can connect using LDAPS via the command line tools? (ldapsearch, ldapwhoami, etc). Yes I did: $ ldapsearch -H ldaps://localhost:636/ -X cn=admin ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) The relevant line in /etc/default/slapd: SLAPD_SERVICES=ldap://127.0.0.1:389/ ldaps:/// And the relevant lines in /etc/ldap/slapd.conf: TLSCertificateFile /etc/ssl/private/mykey.crt TLSCertificateKeyFile /etc/ssl/private/mykey.key # original cipher suite string #TLSCipherSuite HIGH:-SSLv2:-RSA # cipher suite string as used before with OpenSSL #TLSCipherSuite HIGH:MEDIUM:-SSLv2 # all cipher suites as currently supported by gnutls, # constructed using command: # gnutls-cli -l | grep -E ^TLS | cut -d\ -f1 | xargs echo TLSCipherSuite TLS_ANON_DH_ARCFOUR_MD5 TLS_ANON_DH_3DES_EDE_CBC_SHA1 TLS_ANON_DH_AES_128_CBC_SHA1 TLS_ANON_DH_AES_256_CBC_SHA1 TLS_PSK_SHA_ARCFOUR_SHA1 TLS_PSK_SHA_3DES_EDE_CBC_SHA1 TLS_PSK_SHA_AES_128_CBC_SHA1 TLS_PSK_SHA_AES_256_CBC_SHA1 TLS_DHE_PSK_SHA_ARCFOUR_SHA1 TLS_DHE_PSK_SHA_3DES_EDE_CBC_SHA1 TLS_DHE_PSK_SHA_AES_128_CBC_SHA1 TLS_DHE_PSK_SHA_AES_256_CBC_SHA1 TLS_SRP_SHA_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_AES_128_CBC_SHA1 TLS_SRP_SHA_AES_256_CBC_SHA1 TLS_SRP_SHA_DSS_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_RSA_3DES_EDE_CBC_SHA1 TLS_SRP_SHA_DSS_AES_128_CBC_SHA1 TLS_SRP_SHA_RSA_AES_128_CBC_SHA1 TLS_SRP_SHA_DSS_AES_256_CBC_SHA1 TLS_SRP_SHA_RSA_AES_256_CBC_SHA1 TLS_DHE_DSS_ARCFOUR_SHA1 TLS_DHE_DSS_3DES_EDE_CBC_SHA1 TLS_DHE_DSS_AES_128_CBC_SHA1 TLS_DHE_DSS_AES_256_CBC_SHA1 TLS_DHE_RSA_3DES_EDE_CBC_SHA1 TLS_DHE_RSA_AES_128_CBC_SHA1 TLS_DHE_RSA_AES_256_CBC_SHA1 TLS_RSA_NULL_MD5 TLS_RSA_EXPORT_ARCFOUR_40_MD5 TLS_RSA_ARCFOUR_SHA1 TLS_RSA_ARCFOUR_MD5 TLS_RSA_3DES_EDE_CBC_SHA1 TLS_RSA_AES_128_CBC_SHA1 TLS_RSA_AES_256_CBC_SHA1 Before, using OpenSSL, everything worked perfectly. Now, LDAPS is completely broken. Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Bug#462588: Same problem
--On Saturday, January 26, 2008 12:33 PM +0100 T.A. van Roermund [EMAIL PROTECTED] wrote: Quanah Gibson-Mount wrote: Have you verified whether or not you can connect using LDAPS via the command line tools? (ldapsearch, ldapwhoami, etc). Yes I did: $ ldapsearch -H ldaps://localhost:636/ -X cn=admin ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Have you verified that port 636 is open? I.e., telnet localhost 636 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: [Pkg-openldap-devel] Bug#462588: Same problem
--On Saturday, January 26, 2008 1:01 AM +0100 T.A. van Roermund [EMAIL PROTECTED] wrote: Hi, I have the same problem. Following your suggestion, I listed all the cipher suites using gnutls-cli -l and tried all of them. Now, slapd does start, but still Thunderbird cannot connect to the daemon, no matter which cipher suite was selected. Have you verified whether or not you can connect using LDAPS via the command line tools? (ldapsearch, ldapwhoami, etc). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462588: Same problem
Hi, I have the same problem. Following your suggestion, I listed all the cipher suites using gnutls-cli -l and tried all of them. Now, slapd does start, but still Thunderbird cannot connect to the daemon, no matter which cipher suite was selected. Regards, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
