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