Hi Christopher (and Konstantin), took some time to reply as I wanted to test your suggestions:
- "a parameterized server.xml that pulls the password [...]": If I understood your hint correctly it boils down to passing secrets as JVM args (using -D or env vars). I do not think that would satisfy my use case as it implies passing secrets on command line or environment. Not acceptable for us. - "external XML entities": I gave it a try to this as it looked really promising; but I couldn't get it working. If I got it right your suggestion was I should load the keystore password from a file by declaring the file as an external entity in server.xml and then reference it in the keystorePass/keyPass *attribute* of the relevant Connector entity: (PLS know that my DTD/XML-fu doesn't seems to be up to the task so I might be missing something obvious) I looks like loading external entities as attribute values it's forbidden by design [1] ([2] to know about the test I made). *If I'm not wrong* than the only way to do what I'm trying to do is a patch. If you agree than I'll open an RFE BUG. Hope this makes sense, regards, luca [1] Last point of section 4.4.4 "Forbidden" at http://www.w3.org/TR/REC-xml/#sec-external-ent [2] My test on loading an external file as an attribute value: After the first few test I realised I needed a way to test the actual value tomcat parsed from the external entity, so instead of trying to set the keystorePass/keyPass attr value I switched to the server attribute of the Connector entity. You can see the value tomcat assigned to this attr with wget -S. Test1 (External entities DO NOT WORK as attrs values): echo hello > /tmp/server cat server.xml: <!DOCTYPE server-xml [ <!NOTATION KSPASS SYSTEM "text/plain"> <!ENTITY xxx SYSTEM "/tmp/server" NDATA KSPASS> [...] <Connector port="8282" protocol="HTTP/1.1" connectionTimeout="20000" server="&xxx;" redirectPort="8443" /> (note that NOTATION suff seems to be required otherwise the thing would try to parse the value as a *valid* xml) catalina.out: "SEVERE: Parse Fatal Error at line 65 column 29: The external entity reference "&xxx;" is not permitted in an attribute value." Test2 (Entities WORK as attrs values): cat server.xml: <!DOCTYPE server-xml [ <!NOTATION KSPASS SYSTEM "text/plain"> <!ENTITY yyy "bla bla bla"> [...] <Connector port="8282" protocol="HTTP/1.1" connectionTimeout="20000" server="&yyy;" redirectPort="8443" /> wget -S http://wi0.devenv.dev:8282/: --2015-04-15 23:32:52-- http://wi0.devenv.dev:8282/ Resolving wi0.devenv.dev (wi0.devenv.dev)... 192.168.122.222 Connecting to wi0.devenv.dev (wi0.devenv.dev)|192.168.122.222|:8282... connected. HTTP request sent, awaiting response... HTTP/1.1 404 Not Found Content-Length: 0 Date: Wed, 15 Apr 2015 21:32:52 GMT Server: bla bla bla 2015-04-15 23:32:52 ERROR 404: Not Found. ----- Original Message ----- > From: "Christopher Schultz" <ch...@christopherschultz.net> > To: "Tomcat Users List" <users@tomcat.apache.org> > Sent: Tuesday, April 14, 2015 7:13:53 PM > Subject: Re: RFE: read keystorePass from file > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Luca, > > On 4/14/15 1:07 PM, Luca Menegus wrote: > > Hi, I'd like to suggest the addition of an option that would allow > > reading the keystore password (the password protecting the private > > key used by secure connectors) from file. > > > > My use case: > > > > I manage tomcat configuration including server.xml with a > > Configuration System (Ansible). This allows me to template and > > store tomcat configuration in a Source Control System (as I do for > > other services). The problem is that I need a secure tomcat > > connector and the only way to provide a password to protect private > > keys seems to be to write it in server.xml. Which means that the > > password end up being committed to SCM ( defeating the purpose of > > protecting the keystore with a password). If tomcat could read the > > password from a file than I could generate it randomly on the > > target host and store it on a file only tomcat can read. > > > > > > I hope my suggestion could be considered and I'm ready to further > > discuss my use case if further information are required. > > > > Regards, Luca > > > > PS: this has nothing to do with obfuscating the password (which > > has already been discussed on this list) > > This seems reasonable, but you do have another option: a parameterized > server.xml that pulls the password value in from another place. > Examples include an ant-based build with filtering or external XML > entities. > > If you'd still like this feature, please open a Bugzilla enhancement > request. > https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%209 > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJVLUrRAAoJEBzwKT+lPKRYojIP/3IiPp9yeixqM+TJSuq25umH > sdnLalXOtJYDrM78zoA8Q+E8YtseCf8CcZII6QFgWVUVTRTZYD//tJEuhKwbhhA5 > I894oqL1G6k3z4yfExX7TsE5+RE6mBEfoMKCpF4nIXbcfaSlqXoZ1ZcNhmPjS0Jz > 4yJK9GWayNmRN7211vLSXd6DrvZ5WsubqNxlq/E5td/kR7cIALNx8mTylD6GvgF8 > 7TCSPY2ZiUPJQu27rrutwnYU/p9ea9GPNr6lFcF6yt2NDt0TMWkhFAe8UXveIzVT > HdIuhCyENGhTjy7tE6kpyvgB9E85SXN1nkx4mkyzoOqhjeJFfo+1OLujcNnCmtOH > yrcmVUG2zzboiSh7xy1ehegC54jc3P8J3jTglem1JtWs5c3Yr64EORu7CotbsPxs > FRAN/8+loo0b/mZzuxJdDt3h0eQsYsF00h7zOT0Pn2rU/dEo79TBSwglnESIivFx > +6DxHyKF4kuoppcSD9HjJRwOGLrA5x5Ck1aEgAOCjdLdJaQDkhZ7X8FkFgTyuwzz > 5slSYAHq0JJsoglXBaVSv/gBLuaCxzMomsjIsD+kJ4X7e/bVxvbA6BjtaywTMx7L > VwBv8EygkZV7/ap9k15n/4+nk80/wyVTgZD0ig3ceQX/kVs1zTLtIYOxdzjOj6cs > OuvJXECVb1iUjTaipAjf > =1teY > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
