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

Re: TLS SSL overload

Thanks to all on this.  I'm going to try taking the
key off now... just for further info, actually,
it did ask me for my pass phrase when I started
it up, and I typed it in, and it accepted it, which
is why I ignored the advice... I had scanned the
passage below in the man pages while I was reading
something else, but as it so readily accepted the passphrase,
I figured maybe docs were out of date or something.  Sorry.

Hope it's as simple as this to fix.

Thanks agiain.

Bill



Howard Chu wrote: 
All correct, Richard. But you can stop guessing by reading the 2.1 man pages
and Admin guide where all of these points are already spelled out for you.
http://www.openldap.org/software/man.cgi
http://www.openldap.org/doc/admin21/

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support


-----Original Message-----
From: owner-openldap-software@OpenLDAP.org
[mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Richard
Levitte - VMS Whacker
Sent: Wednesday, October 30, 2002 7:17 AM
To: bd@emtex.com
Cc: openldap-software@OpenLDAP.org
Subject: Re: TLS SSL overload


In message <3DBFEAFC.2020307@emtex.com> on Wed, 30 Oct 2002
14:21:48 +0000, billd <bd@emtex.com> said:

bd> Created a private key with 3des encryption
bd>
bd> openssl genrsa -des3 -out ncc1701a.key 1024

I think you're doing a mistake here.  To open that key, you will need
to feed slapd the pass phrase, and if I understand correctly, it
didn't ask you for one.  Also, in my man page, I find this:

      TLSCertificateKeyFile <filename>
             Specifies  the  file  that contains the slapd
server private key
             that matches the certificate stored  in  the
TLSCertificateFile
             file.   Currently,  the private key must not be
protected with a

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
             password, so it is of critical importance that
it  is  protected
             ^^^^^^^^
             carefully.

I believe that could be at least part of your problem.

However, it's really simply to take away the protection:

openssl rsa -in ncc1701a.key -out ncc1701a-noprot.key

Then you just have to configure slapd to use ncc1701a-noprot.key
instead of ncc1701a.key.

bd> openssl req -new -key ncc1701a -x509 -out ncc1701a.crt

This might give you another problem: creating a self-signed
certificate will make it a CA certificate, at least with the main
distribution of OpenSSL (the basicConstraints extension will have the
critical value TRUE for the CA choice).  Such certificates can't
generally be used as server certificates, and it's possible that's yet
another reason why things don't work right for you.  I'd chek this
last, however, as this is pure guesswork on my part.

bd> This asked me for some input, I think the important
bd> one is the common name, so I put emtex.com... not sure
bd> about this, should it be ncc1701a.emtex.com or emtex.com or
bd> dn=emtex,dn=com...

On server certificates, the common name should be the servers name,
i.e. ncc1701a.emtex.com.

I currently run 2.0.23, and the man page for it doesn't mention
TLSCACertificateFile, so I'm not sure about the semantics for that
one.  *Usually*, the CA certificate file is a collection of CA
certificates against which client certificates should be verified.

--
Richard Levitte   \ Spannvägen 38, II \ LeViMS@stacken.kth.se
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
                   \      SWEDEN       \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis                -- poei@bofh.se
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.