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:40:00 GMT
Also setting up your own certificate and adding it to the DIT is pretty easy
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 store
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 <akarasulu@gmail.com> 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 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