[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Solaris 8, TLS connect fails (ITS#1266)

On Thu, 2 Aug 2001 Kurt@OpenLDAP.org wrote:

> At 01:02 AM 8/1/2001, muecketb@sbox.tugraz.at wrote:
> >Full_Name: Stocker Gernot
> >Version: 2.0.11
> >OS: Solaris 8
> >URL: ftp://ftp.openldap.org/incoming/
> >Submission from: (NULL) (
> >
> >
> >Hello openldap developers,
> >
> >I compiled openldap 2.0.11 on Solaris 8 with tls support using openssl-0.9.6a.
> >
> >The configuration was OK and ssl was found:
> >./configure --disable-slapd --disable-slurpd  --enable-clients
> >--without-cyrus-sasl --with-tls
> >
> >During compilation I got:
> >
> >gcc -g -O2 -I../../include -I../../include -c tls.c  -fPIC -DPIC -o
> >.libs/tls.lo
> >tls.c:534: warning: initialization from incompatible pointer type
> >tls.c:536: warning: initialization from incompatible pointer type
> >tls.c:538: warning: initialization from incompatible pointer type
> >
> >but compilation proceeded without problems.
> >
> >All programs compiled fine and my own developed under Linux, too.
> >
> >BUG1:
> >While testing the tls ability against a Novell Netware 5 Ldap-Server(Ldapv3 and
> >SSLv3only),
> >I noticed under _Linux_ that only uri-connects (with ldaps://ldaphost) get a
> >positiv result(tested with ldapsearch as well as with my own program).
> >
> >[ that means: ldap_start_tls_s( ld, NULL, NULL ) doesn't work!
> >  but (ldap_initialize(&ld ,"ldaps://ldaphost") ]
> Ask Novell to implement RFC 2830.
> >BUG2:
> >Under _Solaris_ neither with ldapsearch nor with my own program there was an
> >ldaps:// connect possible. The same call with ldap://ldaphost proceeded
> >without problems.
> Sounds like a certificate problem...  see openldap-software
> archives for discussions of common problems here.

About BUG2:
   I have been trying to identify this cause of this problem: Secure
operations with no host given hangs.
   The original behaviour is, if no host is specified then the localhost
is contacted and queried at port 389 or 636 depending upon the type of
   But, when a secure search is done with no host specified, then the
client truly tries to contact the localhost, but , at port 389 and not at
636. This is the case when the LDAP Server is listening on default ports.
Hence, the LDAP server will receive a request on 389.
  When debbuged into the LDAP client code, the new connection is opened
using the parameters, in the structure , LDAPURLDesc, here the default
port is always set to 389 when the host is not specified. I am still in
the process of identifying the actual fix for this problem. I will get
back with the fix if the fix is not already checked in.