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

RE: TLS SSL overload



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