directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Toward a 2.0 GA
Date Thu, 17 Jan 2019 14:54:13 GMT

On 17/01/2019 15:14, Shawn McKinney wrote:
>> On Jan 16, 2019, at 3:54 PM, Emmanuel Lécharny <> wrote:
>> The Server, when started, will try to load the Keystore content:
>> o If there is no provided KeyStore file, the server will use create its own Keystore,
based on the default SUN provider.
>> o Otherwise, the server will try to load the provided KeyStore, using the paswword
that has to be provided too. There are two parameters used to configure the server : ads-keystoreFile
that will contain tha path to the KeyStore and ads-certificatePassword (which should most
certainly be renamed ads_keyStorePassword)
> Hi Emmanuel,
> Thinking out loud here so forgive the naive comment, but shouldn’t the server use the
a. default Java keystore (if found), or b. what’s passed to it, and only if not (a or b)
c. create a new?

The server is currently trying to load a keystore that is passed to it 
as a parameter, and if not, it creates an internal keystore that fetches 
the admin user Certificate. There is no such thing as a 'default java 
keystore', unless you mean the one you manage using keytool - but then 
you have to tell the app where this keystore is -. Correct me if I'm wrong.

The rational, when this part of the server was implemented, was to make 
dead simple to have TLS working: wze create the certificate 'on the 
fly', and store it in a keystore that is wrapped around the server 
itself, for the storage. Somehow, it makes sense. There is even an 
extended operation that allows a client to create a certificate 

So passing an existing Keystore is a way to use signed certificates, 
instead of self-signed ones generated by teh server at startup. Funny 
enough, you can also reconfigure the server to use a signed certificate 
without using a keytstore, but it's a 2 steps init :

- first start the server as is

- change the admin certificate/public/private key to replace them with 
the signed one

- restart the server

In any case, I do think we have to have a serious conversation about all 
those aspects which are critically important from a security PoV !!!

FTR, I'm checking the code provided by Daniel Fisher (DIRAPI-72) which 
point to the code that can be used to verify the server name on the 
startTLS extended operation. It's based on the class.

View raw message