[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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