[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Problems using TLS
Andrew,
Here is an old post of mine that sounds alot like the problem you are
having. Hope it helps:
Greets,
I have remedied the TLS issue I was having with ldapsearch. Thanks, Kurt,
for the "clue" about the common name in the SSL certificate. That was
fundamental in determining the problem.
To recap, I had openldap-2.0.11 compiled with tls under openssl-0.9.6a. I
could do ldapsearches to regular connections (ldapsearch -x -H
"ldap://192.168.0.1"; -s base -b "dc=example,dc=com"). However, TLS
connections would fail with an ambiguous error (ldapsearch -x -H
"ldaps://192.168.0.1" -s base -b "dc=example,dc=com"). The error would be:
ldap_pvt_gethostbyname_a: host=Geneva, r=0
connection_get(10): got connid=0
connection_read(10): checking for input on id=0
TLS trace: SSL_accept:before/accept initialization
TLS trace: SSL_accept:SSLv3 read client hello A
TLS trace: SSL_accept:SSLv3 write server hello A
TLS trace: SSL_accept:SSLv3 write certificate A
TLS trace: SSL_accept:SSLv3 write server done A
TLS trace: SSL_accept:SSLv3 flush data
TLS trace: SSL_accept:SSLv3 read client key exchange A
TLS trace: SSL_accept:SSLv3 read finished A
TLS trace: SSL_accept:SSLv3 write change cipher spec A
TLS trace: SSL_accept:SSLv3 write finished A
TLS trace: SSL_accept:SSLv3 flush data
connection_get(10): got connid=0
connection_read(10): checking for input on id=0
ber_get_next
ber_get_next on fd 10 failed errno=0 (Success)
connection_read(10): input error=-2 id=0, closing.
connection_closing: readying conn=0 sd=10 for close
connection_close: conn=0 sd=10
TLS trace: SSL3 alert write:warning:close notify
The issue was that the certificate for Geneva (192.168.0.1) has a common
name of Geneva, but the DNS was not set up to resolve the hostname. This
was necessary even though I was connecting directly by IP because of the
hostname in the certificate. I added an entry to /etc/hosts for
'192.168.0.1 geneva', and this works properly now.
The key is to make sure you can resolve the CN in the certificate. To find
out the CN, run (in my case) 'openssl s_client -connect 192.168.0.1:636' and
look at the output:
CONNECTED(00000003)
depth=0
/C=CA/ST=Manitoba/L=Winnipeg/O=SBGH/OU=IS/CN=geneva/Email=jmowat@sbgh.mb.ca
verify error:num=18:self signed certificate
verify return:1
depth=0
/C=CA/ST=Manitoba/L=Winnipeg/O=SBGH/OU=IS/CN=geneva/Email=jmowat@sbgh.mb.ca
verify return:1
---
Certificate chain
0
s:/C=CA/ST=Manitoba/L=Winnipeg/O=SBGH/OU=IS/CN=geneva/Email=jmowat@sbgh.mb.c
a
i:/C=CA/ST=Manitoba/L=Winnipeg/O=SBGH/OU=IS/CN=geneva/Email=jmowat@sbgh.mb.c
a
...
...
Hope this helps anyone who was having similar problems!
As a side note, it may be prudent to change the error in slapd to give a bit
more information back in the event of this error, like 'CN=whatever could
not be resolved, ldapsearch terminating', or something like that. Just a
suggestion :-)
Cheers,
Jason
----- Original Message -----
From: "Andrew C Altepeter" <aaltepet@cs.und.edu>
To: <OpenLDAP-software@OpenLDAP.org>
Sent: Wednesday, July 25, 2001 1:01 PM
Subject: Re: Problems using TLS
> Hi,
>
> One more note: I just noticed that when slapd starts up, it gives another
> error at the beginning of the debug log:
>
> daemon_init: ldaps:///
> daemon_init: listen on ldaps:///
> daemon_init: 1 listeners to open...
> ldap_url_parse_ext(ldaps:///)
> daemon: socket() failed errno=97 (Address family not supported by
> protocol)
> daemon: initialized ldaps:///
> daemon_init: 1 listeners opened
> slapd init: initiated server.
>
> What does that address family not supported mean? Is it normal?
>
> Again, thanks for your help,
> Andy
>
> On Wed, 25 Jul 2001, Andrew C Altepeter wrote:
>
> > Hello everybody!
> >
> > I am working on converting my companies authentication system over to
> > openldap.
> > I have my ldap database up and running, and am able to use the migration
> > tools to port over all of our users. Also, I am able to authenticate to
> > this database via the linux workstations/servers (RH7.1) and on our
> > solaris 8 servers using unencrypted connection (ldap://port 389).
> > However, being our company has over 5,000 users, keeping security in
mind
> > I would like to get ssl/tls working in openldap. I can compile openldap
> > with tls support (./configure --with-tls) and have no problems.
However,
> > when I set up slapd to run ldaps (slapd -h ldaps:///), and then use a
> > client's ldapsearch utility, I get the following error:ldap_bind: Can't
> > contact LDAP server. ldap.conf is configured to look at the correct
port
> > on the server, and I have verified that by using ldapsearch -d 65535.
> > Using nmap I have also verified that ldapssl is running on port 636 on
my
> > ldap server.
> >
> > I did a full debug on the ldap server, when trying to use ldapsearch
from
> > the client, and here is the useful output:
> >
> > connection_get(9)
> > connection_get(9): got connid=0
> > connection_read(9): checking for input on id=0
> > TLS trace: SSL_accept:before/accept initialization
> > tls_read: want=11, got=11
> > 0000: 30 0c 02 01 01 60 07 02 01 03 04 0....`.....
> > TLS trace: SSL_accept:error in SSLv2/v3 read client hello A
> > TLS: can't accept.
> > TLS: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
> > s23_srvr.c:565
> > connection_read(9): TLS accept error error=-1 id=0, closing
> > connection_closing: readying conn=0 sd=9 for close
> > connection_close: conn=0 sd=9
> > daemon: removing 9
> > conn=-1 fd=9 closed
> > daemon: select: listen=6 active_threads=0 tvp=NULL
> > daemon: activity on 1 descriptors
> > daemon: select: listen=6 active_threads=0 tvp=NULL
> >
> > Here is the output from the client ldapsearch:
> >
> > ldap_create
> > ldap_bind_s
> > ldap_simple_bind_s
> > ldap_sasl_bind_s
> > ldap_sasl_bind
> > ldap_send_initial_request
> > ldap_new_connection
> > ldap_int_open_connection
> > ldap_connect_to_host
> > ldap_new_socket: 4
> > ldap_prepare_socket: 4
> > ldap_connect_to_host: Trying 134.129.212.33:636
> > ldap_connect_timeout: fd: 4 tm: -1 async: 0
> > ldap_ndelay_on: 4
> > ldap_is_sock_ready: 4
> > ldap_ndelay_off: 4
> > ldap_delayed_open successful, ld_host is (null)
> > ldap_send_server_request
> > ber_flush: 14 bytes to sd 4
> > 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00
0....`........
> > ldap_write: want=14, written=14
> > 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00
0....`........
> > ldap_result msgid 1
> > ldap_chkResponseList for msgid=1, all=1
> > ldap_chkResponseList returns NULL
> > wait4msg (infinite timeout), msgid 1
> > wait4msg continue, msgid 1, all 1
> > ** Connections:
> > * host: treefrog.aero.und.edu port: 636 (default)
> > refcnt: 2 status: Connected
> > last used: Wed Jul 25 12:24:26 2001
> >
> > ** Outstanding Requests:
> > * msgid 1, origid 1, status InProgress
> > outstanding referrals 0, parent count 0
> > ** Response Queue:
> > Empty
> > ldap_chkResponseList for msgid=1, all=1
> > ldap_chkResponseList returns NULL
> > do_ldap_select
> > read1msg: msgid 1, all 1
> > ber_get_next
> > ldap_read: want=1, got=0
> >
> > ber_get_next failed.
> > ldap_perror
> > ldap_bind: Can't contact LDAP server
> >
> > Now, my biggest question is why the server is giving me this error when
> > setting up the ssl session:
> > TLS: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
> > s23_srvr.c:565
> >
> > On all of my machines, I am using openssl0.9.6b, the latest netscape
sdk,
> > and openldap 2.0.11.
> >
> > Has anyone encountered this problem before and can help me out here?
> > I would really appreciate it.
> >
> > Andy
> >