FYI I just hit another issue where ldap wouldn't start with errors like this:
TLS init def ctx failed: -207
slapd stopped.
connections_destroy: nothing to destroy.'
This turned out to be due to a PKCS#8 key, using openssl rsa -in
old.key -text (and then cutting and pasting the PRIVATE RSA KEY
this bug should be closed.
I had the same problem today and I simply commented out the TLS suite portion.
That allowed things to work just fine.
(see comment # 19
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/217159/comments/19
)
The documentation should be updated not to say to use
I _think_ that the problem was that the LDAP server certificate was just a
regular SSL certificate and it needed recreating as a server certificate
(build-key-server from easy-rsa tools):
nsCertType = server
extendedKeyUsage=serverAuth
keyUsage = digitalSignature,
Seems that the last commenter was able to fix his problem. I'm going to
mark this bug invalid. Please open a new bug if you encounter a similar
problem.
** Changed in: openldap (Ubuntu)
Status: Incomplete = Invalid
--
slapd + gnutls fails
https://bugs.launchpad.net/bugs/217159
You
FYI I've compiled up 2.4.16 (took 2.4.15 from debian and updated
source), added a patch from
http://209.85.229.132/search?q=cache:idWE3JHeQOUJ:www.openldap.org/its/index.cgi/Software%2520Bugs%3Fid%3D6053%3Bpage%3D1+main:+TLS+init+def+ctx+failed:+-50cd=1hl=enct=clnkgl=uklr=lang_en
(Subject: gnutls
http://www.openldap.org/its/index.cgi/Software
Bugs?id=6053;expression=gnutls is a better link to that patch
compiled with openssl rather than gnutls and it's happier..
Aha!!! Found it :-) openssl client then complained that the ceritficate
was not suitable for the purpose. In short, I had
FWIW I've got the same on a debian box I've just upgraded from etch to lenny:
slapd 2.4.11-1
libldap-2.4-2 2.4.11-1
libgnutls26 2.4.2-6+lenny1
certs are not blacklisted (checked ca and server), gnutls-serv works
fine.
tracign with openssl shows a very quick reply:
openssl s_client -connect
Could you please include the information requested at
https://wiki.ubuntu.com/DebuggingOpenldap#ssl-client-failure?
Thank you,
--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com
--
slapd + gnutls fails
https://bugs.launchpad.net/bugs/217159
You received this bug notification because you
sure:
/etc/ldap/ldap.conf:
BASE dc=opsera,dc=com
URI ldap://foo.opsera.com
TLS_CACERT /etc/ssl/certs/ca.opsera.com.crt
TLS_REQCERT demand
TLS_CACERT file:
-BEGIN CERTIFICATE-
MIIEUTCCAzmgAwIBAgIJAI+dj7GhDEy1MA0GCSqGSIb3DQEBBQUAMHgxCzAJBgNV
Unfortunately I've decommissioned the machine. However I do know that I
didn't manually specify any TLSCipherSuite directives in the slapd.conf.
The hardy slapd.conf man (5) file still references the TLSCipherSuite
format accepted by OpenSSL (e.g.: TLSCipherSuite HIGH:MEDIUM:+SSLv2),
which
@elvis:
According to the slapd log:
TLS: can't accept: Could not negotiate a supported cipher suite..
Could you post your slapd.conf file? Becareful to not include any
sensitive information such as passwords.
--
slapd + gnutls fails
https://bugs.launchpad.net/bugs/217159
You received this bug
On Thu, Feb 26, 2009 at 04:48:11AM -, elvis wrote:
I've created x509 certificates and signed them against our company CA.
These work perfectly for Apache on Hardy (adding the CA cert to by
browser shows connection to Apache as working and verified).
Experiments with gnutls-cli show the
As above:
client: ldapsearch -x -H ldaps://localhost:636 -D *** -w ***
server:
slap_listener(ldaps:///)
connection_get(13): got connid=1
connection_read(13): checking for input on id=1
connection_read(13): TLS accept failure error=-1 id=1, closing
connection_closing: readying conn=1 sd=13 for
Oh, and the gnutls-cli stuff:
I opened the listening server with:
gnutls-serv --x509cafile my_ca.cer --x509keyfile myclient.pem --x509certfile
myclient.cer
It returns:
Set static Diffie Hellman parameters, consider --dhparams.
Processed 1 CA certificate(s).
Echo Server ready. Listening to port
This is run with:
/usr/sbin/slapd -h ldaps:/// -g openldap -u openldap -f /etc/ldap/slapd.conf
-d15
Connecting from either ldapsearch -x -H ldaps://... or gnutls-cli,
slapd returns:
slap_listener(ldaps:///)
daemon: listen=8, new connection on 13
daemon: added 13r (active) listener=(nil)
I am also having problems with Hardy slapd 2.4.9-0ubuntu0.8.04.2 and
TLS.
It seems OpenLDAP on Hardy is now compiled against GnuTLS, and not
OpenSSL as it was in old versions.
I've created x509 certificates and signed them against our company CA.
These work perfectly for Apache on Hardy (adding
Ronald van Engelen wrote on 2008-09-08:
I'm having the same problems:
I didn't catch Brian May's statement:
This bug report started of by saying that the server having problems with the
client certificate.
My comment is about clients (nss) not able to use ldaps; I will try to
solve this
Could you try using the debug option when running ldapsearch on the
client ?
ldapsearch -x -d 1
** Changed in: openldap (Ubuntu)
Sourcepackagename: openldap2.3 = openldap
Status: New = Incomplete
--
slapd + gnutls fails
https://bugs.launchpad.net/bugs/217159
You received this bug
Hi,
Can you try the version of openldap in my ppa archive?
http://launchpad.net/~zulcss/+archive
Thanks
chuck
--
slapd + gnutls fails
https://bugs.launchpad.net/bugs/217159
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap2.3
There seems to be some confusion here.
TLS_REQCERT on the client tells the client if it should check the server
certificate or not.
This is different whether or not the server checks the client
certificate or not.
I am having problems with the client checking the server certificate
(#231321),
... but TLS_REQCERT never in the client confs helps, but makes me
wonder:
$ man ldap.conf
TLS_REQCERT level
never The client will not request or check any server certificate.
This probably should not be the case. Previously allow has worked, which
is still a bit dubious.
allow The server
$ cat /etc/ldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
URI ldaps://127.0.0.1/
BASE dc=nnn,dc=nnn
TLS_REQCERT never
$ cat /etc/ldap.conf
base dc=nnn,dc=nnn
uri ldaps://127.0.0.1/
timelimit 120
cannot choose slapd for some reason for this bug report. :/
--
slapd + gnutls fails
https://bugs.launchpad.net/bugs/217159
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap2.3 in ubuntu.
--
Ubuntu-server-bugs mailing list
23 matches
Mail list logo
