Alex,
On 1/21/23 08:24, a.grub...@bluewin.ch wrote:
Then how do you manage the webserver certitficate in Tomcat? Where do you store
the password? I would like to do it of course always without, but the
architecture is like that I have.
Webserver certificate.p12
Webserver certificate.p12.pwd Password_today Password
tomorrow
Tomcat/conf/server.xml
I would like to reference the pwd file in server.xml. You cannot enter the
server and get to the directory until you do the sudo to its technical user.
How can you do this? When you have an automated certificate approach running,
renewing certificates which are in the range to renew.
How to avoid setting ; in a password? This also causes or can cause issues.
Thank you for your advice. More security is better, but it must be in the
position to be handled easy. Every manual change I want to avoid.
FWIW any Tomcat servers I run which use automatically-provisioned
certificates (e.g. via ACME) write those certificates to unencrypted key
stores. No passwords whatsoever. Such passwords only give the illusion
of security IMHO.
-chris
-----Ursprüngliche Nachricht-----
Von: Mark H. Wood <mw...@iupui.edu>
Gesendet: Freitag, 20. Januar 2023 14:43
An: users@tomcat.apache.org
Betreff: Re: AW: AW: Password in Tomcat 9.x
On Thu, Jan 19, 2023 at 07:33:04PM +0100, a.grub...@bluewin.ch wrote:
I asked Thomas as well, if he knows if this could be solved with placing the
path to the file - in my opinion, this is a easy, safe possiblitiy to allocate
any certs. That would be very helpful to have such tomcat.
I think there has been something missing in this discussion. Several people
have advised removing the password from the credentials file.
This is not just giving up and trading security for practicality.
Storing a cleartext password on the same system with the password-protected
object is equivalent to having no password, because anyone who can get the
protected object can get the password from the same place.
The only way that encrypting the container can increase security is to provide
the password from outside the system whenever it is needed -- e.g. have an
operator type it in. The purpose of encrypting the container seems to be to
protect it *in transit from one system to another*, after which a human will
decrypt it for use.
So: it is unlikely that anyone will do more work on the code for no more
benefit.
When I think about it, this is just another layer of the reason that these
credentials containers *can* be encrypted: such a file contains all of the
materials which are needed to evade security, so there must be an external
source of control to protect the contents: something which is not part of the
materials and can be kept separate from them, carried by different means.
--
Mark H. Wood
Lead Technology Analyst
University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
