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
