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.
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.
AlexOn Thu, Dec 18, 2008 at 3:00 PM, Emmanuel Lecharny <email@example.com> wrote:
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,