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 Tue, 23 Dec 2008 12:47:49 GMT
Hi Emmanuel,

On Tue, Dec 23, 2008 at 4:24 AM, Emmanuel Lecharny <elecharny@gmail.com>wrote:

> Alex Karasulu wrote:
>
>> I agree with you.  You're right that this is not the best solution for our
>> users currently.  I'm thinking that we should run faster into the future
>> with the tooling to support cert management in the DIT rather than
>> reverting
>> back to the use of the keystore file.
>>
>> When you scratch the itch with the keystore file no one will come to the
>> table to really create the tooling.  Once the pressure is gone, the
>> advance
>> will never happen.  Let the users complain. Let them also get involved and
>> affect change is what I say.
>>
>>
> As much as I agree with you on the global imagine, I think that we should
> also allow 'antiquated' users to play with there keystore file, if it's just
> a matter of a few lines of code to be injected in the server (and so far, it
> costed me less than an hour to restore those lines). Writing the tooling to
> store a certificate at the right place in the DiT, plus all the associated
> tests, will cost a couple of days.
>
> I don't have time for more than that right now, and if you consider that
> the current documentation tells the users how to use the keystore, that also
> mean to update the documentation.
>
> On a more general base, I think that Stefan and Christine, plus a few
> others, have spent a considerable amount of time writing this doco, and we
> should respect this effort.


Absolutely, I respect this very much.  My suggestions are not intended to
disrespect their dedication to the documentation pages, I apologize if my
comments insinuated that in any way.

That mean we should check the current doco to see if we will outdate it when
> doing some modification on the server, and if so,n immediately reflect the
> change in the doco.
> Now, this is not easy too, as we are always working on new features which
> will be released days or even weeks (months ?) after, so the doco will
> _never_ reflect the next version, or if it does, users won't have the
> current version doco. Unless we find a way to have versionned documentation.
>
> Kiran proposed to work on the tooling, and I think it will solve everthing,
> but it will take time. Hopefully, we will have them for 1.5.5, but this is
> not guaranteed...


OK this is not that much a big deal.  I just wanted my view point to come
across with ample consideration.  Seeing how I've been absent recently, I
know I have no right to weigh in heavily on one direction or another.  I had
enough time to comment but obviously not enough to write the tooling :-) or
update the documentation.

Anyways I have talked this too much and you guys know what you're doing
better than I to manage the project.  I humbly defer the judgment call to
you guys for these reasons as well as your having serious validity in your
counter argument.

Cheers,
Alex


>  Alex
>>
>> On Mon, Dec 22, 2008 at 11:03 AM, Stefan Zoerner <stefan@labeo.de> wrote:
>>
>>
>>
>>> Hi Alex!
>>>
>>> Alex Karasulu wrote:
>>>
>>>
>>>
>>>> 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.
>>>>
>>>>
>>>>
>>> I see the problems with the keystore file, but the current DIT solution
>>> is
>>> IMHO not sufficient to work with for our users.
>>>
>>> Sun Java System Directory Server for instance offers tooling to create a
>>> key pair in the DIT, export a CSR (certificate signing request), and
>>> import
>>> a certificate signed from a third party.
>>>
>>> Our current implementation creates a key pair and stores it in some
>>> attributes in an entry automatically . Currently, there is no
>>> (documented)
>>> way to influence on how keys and certificate look like.
>>>
>>> I don't think that it is "pretty easy" setting up your own certificate.
>>> At
>>> least I don not have any idea on how to accomplish this task without
>>> custom
>>> application development.
>>>
>>> I have started like this:
>>>
>>> 1. Create key pair with keytool
>>> 2. Store public and private key in DIT
>>> 3. Create certificate
>>> 4. (optional) Sign certificate
>>> 5. Store (signed) certificate in DIT
>>>
>>> My problem is step 2, You can't export a private key from a keystore with
>>> keytool (AFAIK). I had to write a program for this step.
>>>
>>> Perhaps you can outline a better solution and I will document it step by
>>> step in the wiki.
>>>
>>> My favorite for the future would be an extended operation for key pair
>>> creation. It would be easy to trigger it with studio.
>>>
>>> Greetings from Hamburg,
>>>   Stefan
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny
> www.iktek.com
> directory.apache.org
>
>
>

Mime
View raw message