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. Alex On Thu, Dec 18, 2008 at 3:00 PM, Emmanuel Lecharny <[email protected]>wrote: > 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 > > >
