Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 19032 invoked from network); 22 Dec 2008 15:40:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Dec 2008 15:40:32 -0000 Received: (qmail 80427 invoked by uid 500); 22 Dec 2008 15:40:32 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 80392 invoked by uid 500); 22 Dec 2008 15:40:31 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 80383 invoked by uid 99); 22 Dec 2008 15:40:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Dec 2008 07:40:31 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 209.85.200.172 as permitted sender) Received: from [209.85.200.172] (HELO wf-out-1314.google.com) (209.85.200.172) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Dec 2008 15:40:22 +0000 Received: by wf-out-1314.google.com with SMTP id 27so2351537wfd.31 for ; Mon, 22 Dec 2008 07:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=i3pEjnrXpofsjjyMEyVie9Dm1kumW6mggBGeQ/mY6o0=; b=I57P33x0fM5hUE0ZIbg8/EvuaQmKXJaC13/7yQcKXPLAkVhoIZzUP+tZwg5lMhoTyi n7ZRDhJO+JjNDeJmjmxw3e71cf8v/OxK2DzOTdCOVUQZfRf9Gm/lqHyzT/vcrWyLl6mK pUb1iFrMXWwpqNkiL1jmSqumnAXDH6aQ5apG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=Jr+YWSIgGDMcyDuZMZgAXR8pAJwiziIwhSflKeCJmpCdBfOa0+Mn99j2TdTBTa7d9X XwQihevF02wHmKmcREqjeQ/GT1NT8r+8rWTNamjxCan4q8J2Zpx9peeqo6VEhiYhzw8v yv5Hhiy6Qj59nxE86Z5w5qFnyIxVuqSOKhfLg= Received: by 10.142.174.13 with SMTP id w13mr2416571wfe.161.1229960400906; Mon, 22 Dec 2008 07:40:00 -0800 (PST) Received: by 10.143.17.1 with HTTP; Mon, 22 Dec 2008 07:40:00 -0800 (PST) Message-ID: Date: Mon, 22 Dec 2008 10:40:00 -0500 From: "Alex Karasulu" To: "Apache Directory Developers List" Subject: Re: [ApacheDS] Setting up my own certificate for SSL In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_83516_7069666.1229960400900" References: <49496318.1010700@labeo.de> <49496A6B.40703@apache.org> <494A624E.3040604@nextury.com> <494A9E73.6050906@labeo.de> <494AABCA.3030206@nextury.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_83516_7069666.1229960400900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Also setting up your own certificate and adding it to the DIT is pretty eas= y even without specific tooling. Note that this use of the external file store is the antiquated way to do it. Certs were designed to be stored in directories in the first place. This file thing is going backwards and often the case when you don't have a directory. Why would a directory stor= e it's certs in a file when it has access to the directory store in the first place. If we consider the big picture the cert in the DIT way is the best option. Alex On Mon, Dec 22, 2008 at 10:37 AM, Alex Karasulu wrote= : > Yes let's make sure these hurried changes don't break StartTLS. For some > reason I think there were some issues I encountered with keeping the > keystore on a file. > > Why change the present setup with the keys in the DIT if it works. I thi= nk > this just going to cause problems down the road. Don't remember how exac= tly > but my gut tells me it's going to. Sorry this is not enough information b= ut > I cannot remember exactly what problems I had with the previous external > file configuration. > > Alex > > > On Thu, Dec 18, 2008 at 3:00 PM, Emmanuel Lecharny w= rote: > >> Stefan Zoerner wrote: >> >>> Emmanuel Lecharny wrote: >>> >>>> Ok, after having looked at the code, I think we should restore the way >>>> ADS 1.5.1 was handling an external keystore. >>>> >>>> What about adding the two missing parameters in server.xml ? : >>>> >>>> >>> enabled=3D"true" >>>> tcpPort=3D"10636" >>>> enableLdaps=3D"true" >>>> nbTcpThreads=3D"8"> >>>> #directoryService >>>> >>>> >>>> should become : >>>> >>>> >>> enabled=3D"true" >>>> tcpPort=3D"10636" >>>> enableLdaps=3D"true" >>>> nbTcpThreads=3D"8" >>>> keystoreFile=3D"/home/user/.keystore"> >>>> certificatePassword=3D"changeit"> >>>> #directoryService >>>> >>>> >>>> wdyt ? >>>> >>> >>> This we be a good option for those users who like the old style of usin= g >>> a keystore file created with standard server tools. For the current >>> questions on the ML and my VSLDAP requirements it would be fine. >>> >>> Disadvantage of this approach is the plain text password in the XML fil= e. >>> It offers an intermediate user the chance of extracting the private key= from >>> the keystore. >>> >> We have no way to crypt the password... This is where this solution is >> weak. >> >>> >>> The new approach has the advantage that the private key is relatively >>> save in the server DIT. >>> >>> Is it planned to support both approaches? >>> >> Definitively, yes. At least, this is what I have implemented, and what I= 'm >> currently testing. >> >>> The keystore is only used if it is provided in the XML. Otherwise the k= ey >>> stored in the DIT is used? >>> >> Taht's it. >> >>> Or should we remove the DIT variant completely? >>> >> No, I think that we should consider ADS as a good KeyStore itself. >> >>> Alex as added in March or April; I don't remember the reason for the >>> change. >>> >> I don't know why Alex removed the previous configuration, but the DIT >> approach was the most easier one for users who don't want to deal with t= he >> burden of creating a certificate, stores it into a keystore, etc. And it= was >> really smooth, as you have nothing to do to make LDAPS working with this >> approach. >> >>> >>> It would be nice to have en extended LDAP operation for key pair >>> creation. Call parameters could carry the parameters needed. It would b= e >>> easy to trigger the functionality via Studio or CL tool. Adding the key= pair >>> with an LDAP request seems not to be a good idea, because the private k= ey >>> should not be transported over the wire. This is perhaps a feature for = the >>> 2.0 >>> >> We can wrap that quickly in the server, if I have a complete description >> of what must be done. I'm not a security expert, and I don't have time t= o >> become one :) Any detailed instruction will though be welcomed, as it wi= ll >> help anyone to implement the feature. >> >> Thanks ! >> >> PS: I will commit what I'm working on (related to SSL) in an hour or so. >> >>> >>> Greetings from Hamburg, >>> Stefan >>> >>> >>> >>> >> >> -- >> -- >> cordialement, regards, >> Emmanuel L=E9charny >> www.iktek.com >> directory.apache.org >> >> >> > ------=_Part_83516_7069666.1229960400900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Also setting up your own certificate and adding it to the DIT is pretty eas= y even without specific tooling.  Note that this use of the external f= ile store is the antiquated way to do it.  Certs were designed to be s= tored in directories in the first place.  This file thing is going bac= kwards and often the case when you don't have a directory.  Why wo= uld a directory store it's certs in a file when it has access to the di= rectory store in the first place.  If we consider the big picture the = cert in the DIT way is the best option.

Alex

On Mon, Dec 22, 2008 at 10:37 AM= , Alex Karasulu <akarasulu@gmail.com> wrote:
Yes let's make sure these hurried changes don't break StartTLS.&nbs= p; For some reason I think there were some issues I encountered with keepin= g the keystore on a file. 

Why change the present setup with t= he keys in the DIT if it works.  I think this just going to cause prob= lems down the road.  Don't remember how exactly but my gut tells m= e it's going to. Sorry this is not enough information but I cannot reme= mber exactly what problems I had with the previous external file configurat= ion.

Alex


On Thu, Dec 18, 2008 at 3:00 PM, Emmanuel Lecharny <elech= arny@gmail.com> wrote:
Stefan Zoerner wrote:
Emmanuel Lecharny wrote:
Ok, after having looked at the code, I think we should restore the way ADS = 1.5.1 was handling an external keystore.

What about adding the two missing parameters in server.xml ? :

 <ldapService id=3D"ldapsService"
            enabled=3D"true"
            tcpPort=3D"10636"
            enableLdaps=3D"true"             nbTcpThreads=3D"8">=
  <directoryService>#directoryService</directoryService><= br>  </ldapService>

should become :

 <ldapService id=3D"ldapsService"
            enabled=3D"true"
            tcpPort=3D"10636"
            enableLdaps=3D"true"             nbTcpThreads=3D"8"
            keystoreFile=3D"/home/user/= .keystore">
            certificatePassword=3D"chan= geit">
  <directoryService>#directoryService</directoryService><= br>  </ldapService>

wdyt ?

This we be a good option for those users who like the old style of using a = keystore file created with standard server tools. For the current questions= on the ML and my VSLDAP requirements it would be fine.

Disadvantage of this approach is the plain text password in the XML file. I= t offers an intermediate user the chance of extracting the private key from= the keystore.
We have no way to crypt the password... This is where this solution is weak= .


The new approach has the advantage that the private key is relatively save = in the server DIT.

Is it planned to support both approaches?
Definitively, yes. At least, this is what I have implemented, and what I= 9;m currently testing.

The keystore is only used if it is provided in the XML. Otherwise the key s= tored in the DIT is used?
Taht's it.

Or should we remove the DIT variant completely?
No, I think that we should consider ADS as a good KeyStore itself.

Alex as added in March or April; I don't remember the reason for the ch= ange.
I don't know why Alex removed the previous configuration, but the DIT a= pproach was the most easier one for users who don't want to deal with t= he burden of creating a certificate, stores it into a keystore, etc. And it= was really smooth, as you have nothing to do to make LDAPS working with th= is approach.


It would be nice to have en extended LDAP operation for key pair creation. = Call parameters could carry the parameters needed. It would be easy to trig= ger the functionality via Studio or CL tool. Adding the keypair with an LDA= P request seems not to be a good idea, because the private key should not b= e transported over the wire. This is perhaps a feature for the 2.0
We can wrap that quickly in the server, if I have a complete description of= what must be done. I'm not a security expert, and I don't have tim= e to become one :) Any detailed instruction will though be welcomed, as it = will help anyone to implement the feature.

Thanks !

PS: I will commit what I'm working on (related to SSL) in an hour or so= .

Greetings from Hamburg,
   Stefan





--
--
cordialement, regards,
Emmanuel L=E9charny
www.iktek.com
directory.apache.= org




------=_Part_83516_7069666.1229960400900--