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. 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...
Alex
On Mon, Dec 22, 2008 at 11:03 AM, Stefan Zoerner <[email protected]> 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
