Yes let's make sure these hurried changes don't break StartTLS. For some reason I think there were some issues I encountered with keeping the keystore on a file.
Why change the present setup with the keys in the DIT if it works. I think this just going to cause problems down the road. Don't remember how exactly but my gut tells me it's going to. Sorry this is not enough information but I cannot remember exactly what problems I had with the previous external file configuration.
Stefan Zoerner wrote:We have no way to crypt the password... This is where this solution is weak.
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 ? :
should become :
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.
Definitively, yes. At least, this is what I have implemented, and what I'm currently testing.
The new approach has the advantage that the private key is relatively save in the server DIT.
Is it planned to support both approaches?
The keystore is only used if it is provided in the XML. Otherwise the key stored in the DIT is used?
No, I think that we should consider ADS as a good KeyStore itself.
Or should we remove the DIT variant completely?
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.
Alex as added in March or April; I don't remember the reason for the change.
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.
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
PS: I will commit what I'm working on (related to SSL) in an hour or so.
Greetings from Hamburg,