Christopher Cain at [EMAIL PROTECTED] 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.

The only thing is that apache uses getpass(), so securing the password when
you type it, as it's not read from stdin, but ioctling your tty device.
Asking for your cert on stdin is not _that_ secure.

When the service code is in place, under UNIX, you'll be able to use a
configuration file owned and readable only by "root", since it's read by the
JVM process when it's still running as root...

    Pier

Reply via email to