Alex Karasulu wrote:
I agree with you. You're right that this is not the best solution for ourAs 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.
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.
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...
On Mon, Dec 22, 2008 at 11:03 AM, Stefan Zoerner <firstname.lastname@example.org> wrote:
Alex Karasulu wrote:
Also setting up your own certificate and adding it to the DIT is prettyI see the problems with the keystore file, but the current DIT solution is
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
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
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,