[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: solaris 9 ldap client with tls?



A quick, baffling discovery:

using 'ldaplist' on my Solaris 9 client creates a successful TLS
connection to the ldap server using the same ldapclient info the rest of
the tools fail with. 

Now I'm completely confused. 

On Thu, 2003-06-26 at 16: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 :-)
> 
> 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. 
> > 
> > **********************************************************************
-- 

Brian K. Jones
System Administrator
Dept. of Computer Science, Princeton University
jonesy@cs.princeton.edu
http://www.linuxlaboratory.org
http://phat.sourceforge.net
Voice: (609) 258-6080