RE: solaris 9 ldap client with tls?

["Brian K. Jones" <jonesy@CS.Princeton.EDU>]

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 :-)

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'. 

At this point, it looks as if Solaris is finally attempting to create a
TLS connection. Great. However, the connections are failing, and I have
no idea how to figure out what the real problem is here. All of the
certificates were created on the same box, and all of my Linux boxes are
happily going about their business (encrypted). The Sun box won't budge.
I don't even care about matching up the signing authority, quite
honestly. I really just want the encryption - not so much the
identification. 

BTW, FWIW, 'verifying' the key using /usr/dt/bin/netscape succeeds. The
debug output from slapd follows:

TLS trace: SSL_accept:SSLv3 flush data
tls_read: want=5 error=Resource temporarily unavailable
TLS trace: SSL_accept:error in SSLv3 read client certificate A
TLS trace: SSL_accept:error in SSLv3 read client certificate A
daemon: select: listen=6 active_threads=1 tvp=idle
daemon: select: listen=7 active_threads=1 tvp=idle
daemon: activity on 1 descriptors
daemon: activity on: 11r
daemon: read activity on 11
connection_get(11)
connection_get(11): got connid=3
connection_read(11): checking for input on id=3
tls_read: want=5, got=5
  0000:  15 03 01 00 02                                     .....
tls_read: want=2, got=2
  0000:  02 2a                                              .*
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=3, closing

Any help appreciated. 
brian.

On Thu, 2003-06-26 at 13:38, Smith, Steve wrote:
> > 
> > --On Thursday, June 26, 2003 11:39 AM -0400 "Brian K. Jones" 
> > <jonesy@CS.Princeton.EDU> wrote:
> > > 3. All of the TLS docs I've seen relating to Solaris 
> > clients insist that
> > > you have a cert7.db file and a key3.db file. I'm thoroughly 
> > confused by
> > > this and am wondering if anyone has any insight as to how to
> > > create/manage/administer these files - if they have to be created on
> > > each individual client, where they go, do they expire... and why Sun
> > > says that Netscape should have anything at all to do with my LDAP
> > > client.
> > 
> > That would likely be because SunOne directory server is 
> > simply a later 
> > version of Netscape directory server.  From your comments, 
> > I'd say a lot of 
> > the information you are reading from is based on the 
> > assumption you are 
> > using a SunOne directory server for your ldap lookups.
> > 
> > --Quanah
> > 
> The key3.db and cert7.db files are a hangover from the netscape
> ldap server that became iplanet and SunOne, and are in the form
> the Sun ldap client wants to see. You can create these using
> /usr/dt/bin/netscape on one of the clients, but can re-use the
> resulting files on all the clients to that particular ldap server.
> The expiry time is set when you create the initial certs at the
> server end, so can be set to many years if you prefer.  They work
> fine with the openldap server.
> 
> > --
> > Quanah Gibson-Mount
> > Senior Systems Administrator
> > ITSS/TSS/Computing Systems
> > Stanford University
> > GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
> > 
> 
> 
> ********************************************************************** 
> 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. 
> 
> **********************************************************************