directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@gmail.com>
Subject Re: [ApacheDS] Setting up my own certificate for SSL
Date Mon, 22 Dec 2008 15:37:26 GMT
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 think
this just going to cause problems down the road.  Don't remember how exactly
but my gut tells me it's going to. Sorry this is not enough information but
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 <elecharny@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="ldapsService"
>>>             enabled="true"
>>>             tcpPort="10636"
>>>             enableLdaps="true"
>>>             nbTcpThreads="8">
>>>   <directoryService>#directoryService</directoryService>
>>>  </ldapService>
>>>
>>> should become :
>>>
>>>  <ldapService id="ldapsService"
>>>             enabled="true"
>>>             tcpPort="10636"
>>>             enableLdaps="true"
>>>             nbTcpThreads="8"
>>>             keystoreFile="/home/user/.keystore">
>>>             certificatePassword="changeit">
>>>   <directoryService>#directoryService</directoryService>
>>>  </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.
>> 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 key
>> 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 the
> 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 be easy to
>> trigger the functionality via Studio or CL tool. Adding the keypair with an
>> LDAP request seems not to be a good idea, because the private key 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 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├ęcharny
> www.iktek.com
> directory.apache.org
>
>
>

Mime
View raw message