[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: solaris 9 ldap client with tls?
I think the client cert error may be a red herring.
Here's some log for a successful connection. It
seesm to check for client TLS but then not worry
about it when it fails.
connection_get(13): got connid=2
connection_read(13): checking for input on id=2
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:error in SSLv3 read client certificate A
TLS trace: SSL_accept:error in SSLv3 read client certificate A
connection_get(13): got connid=2
connection_read(13): checking for input on id=2
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_read(13): unable to get TLS client DN error=49 id=2
connection_get(13): got connid=2
connection_read(13): checking for input on id=2
ber_get_next
ber_get_next: tag 0x30 len 55 contents:
do_bind
...
Steve
PS. If you send me your server slapd.conf and client
/var/ldap/ldap_client_cred
and /var/ldap/ldap_client_file contents I'll look them over if you like.
> -----Original Message-----
> From: Brian K. Jones [mailto:jonesy@CS.Princeton.EDU]
> Sent: 27 June 2003 14:42
> To: Greg Matthews
> Cc: Smith, Steve; 'Quanah Gibson-Mount'; LDAP Mailing List
> Subject: RE: solaris 9 ldap client with tls?
>
>
> I'm thoroughly depressed. It shouldn't take a week to get one client
> running when everything else in the entire environment works
> flawlessly.
>
> So now I've imported the *server* cert, as opposed to the root
> certificate (which makes no sense to me, but whatever) using netscape,
> and netscape is fine with the certificate, so I removed the old
> /var/ldap/*.db and replaced those with the new ones created after I
> imported the new 'ldap.cert'.
>
> I also made sure they were 'chmod 444'. I then restarted nscd, and
> ldap.client. 'ldapclient list' outputs this:
>
> NS_LDAP_FILE_VERSION= 2.0
> NS_LDAP_BINDDN= cn=Manager,dc=my,dc=domain,dc=com
> NS_LDAP_BINDPASSWD= {NS1}ef1aeda337bf1f19
> NS_LDAP_SERVERS= ldap.my.domain.com
> NS_LDAP_SEARCH_BASEDN= dc=my,dc=domain,dc=com
> NS_LDAP_AUTH= tls:simple
> NS_LDAP_SEARCH_REF= FALSE
> NS_LDAP_CREDENTIAL_LEVEL= proxy
> NS_LDAP_SERVICE_SEARCH_DESC=
> passwd:ou=People,dc=my,dc=domain,dc=com?sub
> NS_LDAP_SERVICE_SEARCH_DESC=
> group:ou=Groups,dc=my,dc=domain,dc=com?sub
>
> The output I'm getting on the client side when I try to do a
> simple 'su'
> is this:
>
> Jun 27 09:32:03 sunfire-07 nscd[1719]: libsldap: Status: 85 Mesg:
> openConnection: simple bind failed - Timed out
> Jun 27 09:32:03 sunfire-07 nscd[1719]: libsldap: Status: 85 Mesg:
> openConnection: simple bind failed - Timed out
> Jun 27 09:32:03 sunfire-07 last message repeated 1 time
> Jun 27 09:32:03 sunfire-07 nscd[1719]: libsldap: Status: 7 Mesg:
> Session error no available conn.
> Jun 27 09:32:03 sunfire-07 last message repeated 1 time
> Jun 27 09:32:03 sunfire-07 nscd[1719]: libsldap: Status: 7 Mesg:
> Session error no available conn.
> su: Unknown id: jonesy
>
> And on the server side (slapd -d 127) I get:
>
> TLS trace: SSL3 alert read:fatal:bad certificate
> TLS trace: SSL_accept:failed in SSLv3 read client certificate A
> TLS: can't accept.
> TLS: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad
> certificate s3_pkt.c:1052
> connection_read(11): TLS accept error error=-1 id=17, closing
>
> Where I'm really confused is that it would appear that the problem is
> that the server is asking for a client cert, and rejecting
> it. If that's
> wrong, then the client is asking for the server certificate, and
> rejecting it. My real problem is that I COULD CARE LESS about
> server or
> client identity in this case, as I have a lot of control over the
> machines that will use this server. I just want encryption!!!!
>
> I thank everyone for their patience as I work through this mess.
>
> brian.
>
>
>
>
>
>
> On Fri, 2003-06-27 at 04:29, Greg Matthews wrote:
> > On Thu, 2003-06-26 at 21:11, Brian K. Jones wrote:
> > > Hi all.
> > >
> > > I think I'm on the right track here, but no major
> breakthroughs yet.
> > > I'll document what I've done here, so others can see, and
> so I can get
> > > more help :-)
> >
> > yes you're on the right track!
> >
> > >
> > > I created a CA on the ldap server, and also a key. These
> are called
> > > ca.cert, and ca.key. The ldap server also has 'ldap.cert' and
> > > 'ldap.key'. The difference, of course, is that the 'ca'
> files are the
> > > root ca and cert, and the 'ldap' files are the *server*
> ca and cert.
> > >
> > > >From what I understood through my reading and the help
> I've gotten here,
> > > I needed to:
> > >
> > > a) make sure my ldap server is listening on 636, because
> that's what Sun
> > > will be looking to for a TLS connection.
> > >
> > > b) import the certificate from the server using netscape,
> and copy the
> > > resulting 'cert7.db' and 'key3.db' files into /var/ldap.
> Note that I
> > > assumed this meant to import the 'ca.cert' file, so that
> the 'ldap.cert'
> > > file could be verified against the signing authority as
> put forth in
> > > 'ca.cert'. Also, /var/ldap/*.db is all 'chmod 444'.
> >
> > this assumption is wrong. You are thinking of how Linux (padl?)
> > authenticates the cert. The certificate you take from the
> server is the
> > *server* certificate and not the CA cert. I dont know why
> Solaris does
> > it this way - see my earlier email, you point your browser
> at the slapd
> > server which offers its certificate (ldap.cert in your case).
> >
> > good luck!
> >
> > GREG
>
**********************************************************************
This is a commercial communication from Commerzbank AG.
This communication is confidential and is intended only for the person to
whom it is addressed. If you are not that person you are not permitted to
make use of the information and you are requested to notify
<mailto:LONIB.Postmaster@commerzbankib.com> immediately that you have
received it and then destroy the copy in your possession.
Commerzbank AG may monitor outgoing and incoming e-mails. By replying to
this e-mail you consent to such monitoring. This e-mail message and any
attached files have been scanned for the presence of computer viruses.
However, you are advised that you open attachments at your own risk.
This email was sent either by Commerzbank AG, London Branch, or by
Commerzbank Securities, a division of Commerzbank. Commerzbank AG is a
limited liability company incorporated in the Federal Republic of Germany.
Registered Company Number in England BR001025. Our registered address in
the UK is 23 Austin Friars, London, EC2P 2JD. We are regulated by the
Financial Services Authority for the conduct of investment business in the
UK and we appear on the FSA register under number 124920.
**********************************************************************