Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: <3B6846EB.59C1E865@mhsoftware.com>
Date: Wed, 01 Aug 2001 12:14:03 -0600
From: Christopher Cain <ccain@mhsoftware.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [PROPOSAL] Standalone SSL
References: <Pine.BSF.4.21.0108010920380.39986-100000@localhost>
 <3B68376A.C80204C3@mhsoftware.com> <3B684080.AA75F1EA@fujitsu-siemens.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


jean-frederic clere wrote:
> 
> Encrypting server certificates is not bad but it prevents starting the server
> automaticly.
> Storing this password is a nonsense.
> OpenSSL (for example) allows to modify this password or to have no password.
> If the server certificates is encrypted then we should prompt for the password.
> Of course this password should be independant for the other passwords used in
> the system...
> 
> If you are afraid having user passwords stored in the machine you should use
> "user certificates" or something like that....
> (I will go on tomorrow if the thread is still active ;-))

We're in agreement. My initial thought was that either the cert is
encrypted (the secure approach) or not encrypted (the insecure
approach), and if encrypted you are prompted for the password. Since
storing the password in server.xml is essentially the equivalent of not
encryptng it at all, I assumed that we would want to keep the current
approach in place as the "insecure" option both for backwards
compatibility and since the "keytool -genkey" method (which obviously
generates an encrypted keystore) is easy for end users to do. I would
have no objections to the encrypted vs. unencrypted approach you
describe, but that's why I didn't propose it.

As far as the thread still being active tomorrow, I promise I won't let
it die without either a resolution or a fight ;-)

- Christopher