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

RE: SSL Connection problems



Dave,

Ah, good one to know, well I tired it, and according to the output I did
have an SSL session going and started up:


<certificate and other things appeared here>
-----END CERTIFICATE-----
subject=/C=CA/ST=ON/L=Ottawa/O=CCRS/OU=GAD/CN=grumbler/Email=jdoyon@nrcan.gc
.ca
issuer=/C=CA/ST=ON/L=Ottawa/O=CCRS/OU=GAD/CN=grumbler/Email=jdoyon@nrcan.gc.
ca
---
No client certificate CA names sent
---
SSL handshake has read 778 bytes and written 315 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 1028 bit
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DES-CBC3-SHA
    Session-ID:
7D5B6ABA46ED4F2174D109AE413DFEE980237018A6475434816DCA9C4F7DCF50
    Session-ID-ctx: 
    Master-Key: <hidden>
    Key-Arg   : None
    Start Time: 1004366534
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

So I guess it's OpenSSL itself ... Of course I wasn't sure what LDAP
commands I could send using this client (If any) ...

Do note that I use a self-signed certificate.

The plot thickens ...

In the mean time I have made no progress in trying to track down this
problem!

Thanks for the help! Anybody have any other suggestions?

J.F.


-----Original Message-----
From: D.M.Lewney@sussex.ac.uk [mailto:D.M.Lewney@sussex.ac.uk]
Sent: Monday, October 29, 2001 5:35 AM
To: Doyon, Jean-Francois
Cc: 'openldap-software@OpenLDAP.org'
Subject: Re: SSL Connection problems


"Doyon, Jean-Francois" wrote:
> 
> Hello,
> 
> Here is my setup:
> 
> RedHat 6.2 (Severely upgraded and modified and improved)
> openssl-0.9.5a-7.6.x from RPM
> OpenLDAP 2.0.11 built from source
> slapd running listening to SSL port 636 only ...
> 
> This server runs fine, I can connect to it, do searches, etc ... no
problem,
> I can also connect to it using PerLDAP tied to netscape's SDK ... From the
> same machine, and I also have remote machines connecting to it.
> 
> Now I have a new box:
> 
> RedHat 7.0 (or is it 7.1? I forget :)
> OpenSSL 0.9.6-3 from rpm
> OpenSSL 2.0.17 then 2.0.18 then 2.0.11 ...
> 
> This machine will NOT establish a TLS/SSL connection! It works fine over
> non-SSL however ... using the exact same ldapsearch string on the 2 boxes,
> works on one, doesn't on the other.
> 
> Here it is:
> 
> ldapsearch -H ldaps://hidden:636 -D "hidden" -w '"hidden" --b o=CGDI
> uid=JDoyon
> 
> on the first machine (the server) it works, on the RH7.1 box I get:
> 
> ldap_bind: Can't contact LDAP server
> 
> If I add a -ZZ then I get:
> 
> ldap_start_tls: Can't contact LDAP server
> ldap_bind: Can't contact LDAP server
> 
> If I only use -Z then I get:
> 
> ldap_start_tls: Can't contact LDAP server
> 
> I checked the openssl.cnf file and everything is the same.
> 
> With the slapd logging at -1 here's what the server log file looks like:
> 
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: new connection on 9
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: conn=18 fd=9 connection
from
> IP=132.156.10.94:56292 (IP=132.156.10.123:31746) accepted.
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: added 9r
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: activity on:
> Oct 26 11:54:57 grumbler slapd[18848]:
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: select: listen=6
> active_threads=0 tvp=NULL
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: activity on 1 descriptors
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: activity on:
> Oct 26 11:54:57 grumbler slapd[18848]:  9r
> Oct 26 11:54:57 grumbler slapd[18848]:
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: read activity on 9
> Oct 26 11:54:57 grumbler slapd[18848]: connection_get(9)
> Oct 26 11:54:57 grumbler slapd[18848]: connection_get(9): got connid=18
> Oct 26 11:54:57 grumbler slapd[18848]: connection_read(9): checking for
> input on id=18
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: select: listen=6
> active_threads=0 tvp=NULL
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: activity on 1 descriptors
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: activity on:
> Oct 26 11:54:57 grumbler slapd[18848]:  9r
> Oct 26 11:54:57 grumbler slapd[18848]:
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: read activity on 9
> Oct 26 11:54:57 grumbler slapd[18848]: connection_get(9)
> Oct 26 11:54:57 grumbler slapd[18848]: connection_get(9): got connid=18
> Oct 26 11:54:57 grumbler slapd[18848]: connection_read(9): checking for
> input on id=18
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: select: listen=6
> active_threads=0 tvp=NULL
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: activity on 1 descriptors
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: activity on:
> Oct 26 11:54:57 grumbler slapd[18848]:  9r
> Oct 26 11:54:57 grumbler slapd[18848]:
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: read activity on 9
> Oct 26 11:54:57 grumbler slapd[18848]: connection_get(9)
> Oct 26 11:54:57 grumbler slapd[18848]: connection_get(9): got connid=18
> Oct 26 11:54:57 grumbler slapd[18848]: connection_read(9): checking for
> input on id=18
> Oct 26 11:54:57 grumbler slapd[18848]: ber_get_next on fd 9 failed errno=0
> (Success)
> Oct 26 11:54:57 grumbler slapd[18848]: connection_read(9): input error=-2
> id=18, closing.
> Oct 26 11:54:57 grumbler slapd[18848]: connection_closing: readying
conn=18
> sd=9 for close
> Oct 26 11:54:57 grumbler slapd[18848]: connection_close: conn=18 sd=9
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: removing 9
> Oct 26 11:54:57 grumbler slapd[18848]: conn=-1 fd=9 closed
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: select: listen=6
> active_threads=0 tvp=NULL
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: activity on 1 descriptors
> Oct 26 11:54:57 grumbler slapd[18848]: daemon: select: listen=6
> active_threads=0 tvp=NULL
> 
> I tried many versions of OpenLDAP, no luck ... And the domain name used
DOES
> match the CN in the certificate.
> 
> I'm out of ideas, could it be a problem with OpenSSL itself?
> 
> Oh and on neither lcient do I specify a cert in ldap.conf or anywhere, so
I
> don't think it's that either ... looks like the client (the one that
works)
> just trusts what it's given ... (Although with PerLDAP I do use a cert7.db
> file)
> 
> Help !!!!
> 
> Thanks :)
> 
> Jean-François Doyon
> Internet Service Development and Systems Support
> GeoAccess Division
> Canadian Center for Remote Sensing
> Natural Resources Canada
> http://atlas.gc.ca
> Phone: (613) 992-4902
> Fax: (613) 947-2410

Try

/path/to/openssl s_client -connect yourserver:636  

This should tell you whether your certificate is OK.
-- 
Dave
--
Dave Lewney
Principal Systems Programmer, Computing Service
University of Sussex, Brighton BN1 9QJ. Tel: 01273 678354 Fax: 01273
271956