On Thu, Apr 03, 2008 at 12:28:56PM -0700, Quanah Gibson-Mount wrote: > > ok, more testing, more news:
> >>> now with the slapd 2.4.7 package (with gnutls) this seems to force > >>> client-certs, too. a TLS query without client-cert won't work - but > >>> commenting the 'security' line out results in working TLS and working > >>> non-TLS queries. > >> The default behavior when TLS is enabled is "TLSVerifyClient never"; > >> 2.4.7 did have a bug related to this, but this was resolved in the > >> 2.4.7-5 package. > > well it seems to me like with gnutls the 'security tls=' value controls > > the tls reqirements, TLSVerifyClient is (more or less?) ignored. but i > > could be missing something ofc... > > all queries done with a server cert and without a client cert: > > security tls=128 > > TLSVerifyClient never > > ldapsearch fails (TLS confidentiality required) > > ldapsearch -ZZ fails (stronger TLS confidentiality required) > This will always fail as long as the keystrength of the cert in question is > so low. It states quite clearly in your log: > conn=0 fd=12 TLS established tls_ssf=32 ssf=32 > I.e., the TLS SSF is 32. So no value > 32 will ever work. This suggests to me that the SSF values haven't been properly normalized for GNUtls. Doesn't the "128" mean, roughly, a symmetric cipher with keylength of 128? Surely the user's "TLSCipherSuite TLS_RSA_AES_256_CBC_SHA1" should satisfy this? -- 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 Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
