Emmanuel Lecharny wrote:
Overwriting the keys for uid=admin,ou=system did not work out
as expected so that we had to use our own ldapserver class.
This overwriting is really hard, because one has to modify at least
three attribute values (private key, public key, cetificate). The
biggest problem is the private key. If you use keytool to create your
keypair, which would be a good choice to recommend, because it is part
of JDK, you are not able to export your private key out of the keystore.
The tool does not provide this functionality, I guess for security
reasons.
I therefore had to use tools normally not available to an admin ...
I think we have to modify the way the server is initialized. Allowing
the server to use an external keystore should be possible. I will try to
modify the server in order to add such a configuration possible.
Hopefully, this will be added to the upcoming 1.5.5 version.
This would be nice, at least for some users. And for me from an VSLDAP
point of view.
The main advantage of the current implementation is that the private key
is in the DIT and therefore save (if the server is). But if someone
wants to modify it, s/he has to store it with an LDAP client, which is
obviously a bad thing (exporting the key and sending it over the wire).
A disadvantage of the keystore approach is that you have to provide a
password in order to access the private key. The password must be
written somewhere in the configuration, which is bad as well, because it
threats the private key.
My favorite would be an extended operation, which stores the key pair in
the DIT and creates a certificate and perhaps a certificate signing
request (CSR). This would really be great, because the parameters of the
extended operation could contain the parameters for key creation etc.,
and it would be easy to write a UI for studio etc. Perhaps something for
the 2.0 ...
Greetings from Hamburg,
Stefan
