Christopher,
I can sympathize with your concerns, and would always set up production
systems running under a username no one has access to (so they cannot read
server.xml etc. anyway).
My question is, though, where do you stop? Is the password to your
certificates file really any more sensitive than the username/password for
logging on to your database? Or the login information for the directory
server containing your users and roles (assuming use of JNDIRealm)? Or
all the other sensitive configuration information that needs to be passed
on to web apps (or web containers) to make them work?
It's just not clear to me that a "prompt the user at startup
time" approach is scalable to cover all the sensitive information you
might wish to protect.
Craig
PS: I'll also work on why the attributes don't work for you -- they did
for me when this was originally coded, and I cannot recall any changes
that should have made them stop.
On Tue, 31 Jul 2001, Christopher Cain wrote:
> First, just a quick follow-up on the previous thread. Using the keystore
> defaults for the TC4 SSL standalone config works as planned. Trying to
> override the keystoreFile and/or keystorePass defaults, unfortunately,
> does not work (different exceptions for each).
>
> It makes me extremely nervous to have a default password on my certs. Of
> course, it also gets me nothing to change it to a solid password and
> then type that into server.xml. How would you feel about changing the
> SSL process to be more like the Apache approach, where the user is
> prompted on the command line for the store/key password at startup? The
> one drawback is that the web server/container cannot restart without
> human intervention (although the only real-world scenerio I've ever
> encountered where it was really an issue is a clean automated
> shutdown/restart from UPS program, for example).
>
> IMHO, that is a VERY small penalty for not having to store your cert
> password in plaintext in server.xml. In fact, the current solution is
> completely unimplementable in a production system. I'm sure I don't have
> to tell you that one would have to be completely insane to store the
> password to their official cert/private key in the clear in a config
> file. Since I have an immediate need for this functionality, I am
> volunteering to do it. So the only question is, how does everyone feel
> about switching to the Apache approach? I assume that there is not a
> spec issue which would preclude this.
>
> To be fair, I should tell you that I am one of those crypto freaks, so
> please keep that in mind when I start ranting about having a solid
> crypto design =) The primary OSS project I am involved in is a java
> crypto library, so this issue is near and dear to my heart.
>
> Regards,
>
> Christopher
>
