Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <511A6E29.3010008@ice-sa.com>
Date: Tue, 12 Feb 2013 17:30:33 +0100
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Need to Specify keystorePass on Command Line
References: 
 <D98668E85CCA834EA5A7B2F7689204C2E557527C6E@CHNMICMBX02.ManTech.com>
 <99C8B2929B39C24493377AC7A121E21FC49E7678FB@USEA-EXCH8.na.uis.unisys.com>
 <D98668E85CCA834EA5A7B2F7689204C2E557527CD1@CHNMICMBX02.ManTech.com>
 <99C8B2929B39C24493377AC7A121E21FC49E767C7C@USEA-EXCH8.na.uis.unisys.com>
 <51157279.4000509@pidster.com>
 <D98668E85CCA834EA5A7B2F7689204C2E5577EE6DE@CHNMICMBX02.ManTech.com>
 <51164F01.6010701@christopherschultz.net>
 <D98668E85CCA834EA5A7B2F7689204C2E5577EE8BA@CHNMICMBX02.ManTech.com>
 <511A0175.6050806@ice-sa.com>
 <D98668E85CCA834EA5A7B2F7689204C2E5577EE91F@CHNMICMBX02.ManTech.com>
In-Reply-To: 
 <D98668E85CCA834EA5A7B2F7689204C2E5577EE91F@CHNMICMBX02.ManTech.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Harris, Jeffrey E. wrote:
> 
>> -----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Sent: Tuesday, February 12, 2013 3:47 AM
>> To: Tomcat Users List
>> Subject: Re: Need to Specify keystorePass on Command Line
>>
>> Harris, Jeffrey E. wrote:
>>> All,
>>>
>>> I understand that there is no good, secure solution.  However, my
>> hands are tied on this matter, and I would appreciate if you would
>> focus on providing technical assistance in implementing a solution
>> within the constraints I have been given.
>> Jeffrey,
>>
>> We all understand that you have been given rules, and are supposed to
>> follow them.
>> But if these rules themselves make no logical sense, nothing in this
>> Universe is going to help you overcome that.
>>
>> What is the concern really, about the password remaining somewhere on
>> that server when the system is shut down ?
>> Is it that the server, in its shut down state, could be subrepticiously
>> broken apart, its disk stolen and then inspected by foreign spooks to
>> discover that password, which could then be used to further nefarious
>> ends, or what /exactly/ ?
>>
>> What is wrong with the following scenario :
>> - a physical Windows server with a console and a keyboard
>> - boot Windows and login as a "tomcat" user (created beforehand)
>> - open a command window
>> - start Tomcat as an application (not a Service) in that command window
>> - tomcat will ask for the passphrase of the keystore. Type it in. (*)
>> - when Tomcat is running, enter CTRL-ALT-DEL and freeze the console (do
>> not logout from
>> Windows)
>> - walk away
>>
>>
>> (*) having made sure beforehand that there is no trojen on that machine
>> which records your
>> keystrokes and writes them to the disk
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> Andre,
> 
> Tomcat will host a web-app that will connect as a proxy to another organization's system to retrieve data that we will use in our applications.  It is the other organization that is mandating the "no password" requirement, and there is no other option than to use their data.  Our customer requires that the Tomcat server be up 24/7 (with minor outages), hence the need to design a solution that satisfies the requirements of both our customer, and the other organization.  Obviously, if we cannot create a way to automate the process, we may have to do something akin to what you do above.
> 
> However, when I run Tomcat from the console, I am never prompted for the password.  Instead, Tomcat just fails to start the listener on the specified SSL port.

Ah, ok. I must confess that I never tried this with Tomcat.
Apache httpd prompts, in similar circumstances.

I suppose that this prompt/not prompt is really a feature of the underlying SSL stack, not 
of Tomcat itself.  So depending on whether you use the Java SSL stack or the OpenSSL 
stack, the behaviour may be different.

That, or else I can imagine another way : instead of connecting to the other system 
directly from your Tomcat webapp, you could set up your own intermediate Apache httpd 
proxy between Tomcat and that other system. The communication between your webapp and this 
httpd proxy could be in clear (if the Apache httpd is on the same host). Then it would be 
that Apache httpd which would run the SSL conversation with the other system, and /it/ 
would prompt.
A bit more complicated, but if that makes it work to everyone's satisfaction..


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org