On 19/02/2012 09:25, Pae Choi wrote: > On 02/14/2012 09:32 AM, Caldarale, Charles R wrote: >>> From: Luca Marchesano [mailto:luca.marches...@ericsson.com] >>> Subject: Keystore password not masked in server.xml file >>> Is there a way to specify the keystore's password in encrypted way? >> Think about it: where are you going to put the encryption key so >> Tomcat can get at it to decode the encrypted password? Eventually, >> something must be in plain text, accessible to Tomcat. Secure your >> Tomcat configuration files so you don't have to worry about random >> users looking at them. >> >> - Chuck >> > > The OP's inquiry was quite reasonable as well as valid in a security > aspect.
No it wasn't. It was illogical. Chris has already pointed to the FAQ entry that discusses this in more detail. I don't propose to repeat those arguments here but I will say the proposal below is nonsense. Mark > The 'password' for > the key store falls in the same category. I remember there were more > than a few times the same and > similar subject addressed, but i guess it's still as it was. > > To give an idea in terms of where to place and how to access, > > 1) The clear-text or enciphered-form password in the code. > 2) The clear-text password in the connector in the server.xml can be > replaced with the API method > name that can provide the password. > > This simple mechanism can be either or both by Tomcat as default and/or > custom-class that implements > the defined API. > > Within the implementation, how the API method provided the password can > be left to the implementation > provider. In that way, each Tomcat will have unique as well as more > secure depends how well implemented > the password provisioning class implemented which can be left to the > implementation provider. > > Anyhow, this is a basic idea where the password can be placed and how it > can be accessed. And it can be > easily implemented with reasonably short amount of time and effort. > > To go further more for multiple certificates for multiple vHosts such as > SNI+OpenSSL(or alternatives), > it will be a bit more challenging, but not so hard about it. > > > Pae > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
