RE: Tomcat answers on port 80, not on 443

[Beyer, Gregory L]

Thank you, Chris.   You've cut it down to the crux which, in my ignorance of 
felix vs Tomcats role,  I didn't understand.  Essentially, chasing the solution 
in Tomcat is a red herring.  Looking at the apps config file, it references 
"org.apache.felix.https" several times which is a strong sign that Felix Is 
_supposed_ to handle the SLL, but it's not working as it should.  I'll go back 
to the app's developer with the problem.

__
Gregory Beyer
gbey...@gatech.edu

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, October 28, 2015 3:31 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat answers on port 80, not on 443

Gregory,

On 10/27/15 1:57 PM, Beyer, Gregory L wrote:
> Still struggling with this.   I'm amazed that implementing SSL in
> Tomcat is so difficult.  It's not in straight Apache, or IIS.  Is 
> Tomcat really so different an animal?

No, Tomcat is not so different an animal. But you aren't using Tomcat.
You are using Apache Felix + your application + who knows what else + Tomcat 
and asking why "Tomcat" won't configure your TLS correctly.

Configuring a  in Tomcat's conf/server.xml file is fairly 
straightforward. Instead, you have decided to create a  with no TLS 
configuration and then expect Tomcat to somehow infer the /real/ TLS 
configuration information from some arbitrary file where you just happen to 
have specified the keystore path on the disk.

This is a question that YOU need to answer before anyone can offer you help 
here: is Apache Felix responsible for configuring Tomcat's TLS connector or 
not? If you don't know the answer, find someone on your team who DOES know the 
answer and I suspect you'll have 50% of the way to your solution.

> I tried changing \\Program files  to \\progra~1\ -- no joy.:-(

This shouldn't matter.

> A question I posed last week that got overlooked -- Am I supposed to 
> import the .keystore into my cacerts file?  When I open the cacerts 
> file that came with the java install,  it contains  30-40 certifs
> (key-pairs?)   that I didn't create.

You should pretty much never modify cacarts.

-chris

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

Re: Tomcat answers on port 80, not on 443

[Christopher Schultz]

Gregory,

On 10/27/15 1:57 PM, Beyer, Gregory L wrote:
> Still struggling with this.   I'm amazed that implementing SSL in
> Tomcat is so difficult.  It's not in straight Apache, or IIS.  Is
> Tomcat really so different an animal?

No, Tomcat is not so different an animal. But you aren't using Tomcat.
You are using Apache Felix + your application + who knows what else +
Tomcat and asking why "Tomcat" won't configure your TLS correctly.

Configuring a  in Tomcat's conf/server.xml file is fairly
straightforward. Instead, you have decided to create a  with
no TLS configuration and then expect Tomcat to somehow infer the /real/
TLS configuration information from some arbitrary file where you just
happen to have specified the keystore path on the disk.

This is a question that YOU need to answer before anyone can offer you
help here: is Apache Felix responsible for configuring Tomcat's TLS
connector or not? If you don't know the answer, find someone on your
team who DOES know the answer and I suspect you'll have 50% of the way
to your solution.

> I tried changing \\Program files  to \\progra~1\ -- no joy.:-(

This shouldn't matter.

> A question I posed last week that got overlooked -- Am I supposed to
> import the .keystore into my cacerts file?  When I open the cacerts
> file that came with the java install,  it contains  30-40 certifs
> (key-pairs?)   that I didn't create.

You should pretty much never modify cacarts.

-chris

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

RE: Tomcat answers on port 80, not on 443

[Beyer, Gregory L]

Still struggling with this.   I'm amazed that implementing SSL in Tomcat is so 
difficult.  It's not in straight Apache, or IIS.  Is Tomcat really so different 
an animal? 

I tried changing \\Program files  to \\progra~1\ -- no joy.:-(

A question I posed last week that got overlooked -- Am I supposed to import the 
.keystore into my cacerts file?  When I open the cacerts file that came with 
the java install,  it contains  30-40 certifs (key-pairs?)   that I didn't 
create.

__
Gregory Beyer
gbey...@gatech.edu

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Saturday, October 24, 2015 8:06 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat answers on port 80, not on 443

André,

On 10/23/15 4:16 PM, André Warnier (tomcat) wrote:
> On 23.10.2015 16:53, Beyer, Gregory L wrote:
> ...
> ##
> # Inbound SSL Settings
> ##
> 
> org.apache.felix.https.enable=true
> org.osgi.service.http.port.secure=443
>  org.apache.felix.https.keystore=E:\\Program
> Files\\Connector\\.keystore
>  org.apache.felix.https.keystore.password=REDACTED
>  org.apache.felix.https.keystore.key.password= REDACTED
>  org.apache.felix.https.truststore=C:\\Program
> Files\\Java\\jre1.8.0_60\\lib\\security\\cacerts
>  org.apache.felix.https.truststore.password= REDACTED
>>
>> Question  -- Does anyone think " Program Files"  (space) above is 
>> contributing to the problem?
>>
> 
> Maybe, maybe not.  It would depend on how "Felix" parses its 
> configuration files.
> 
> 
> But in any case, admitting spaces in file names is certainly one of 
> the stupidest and most costly ideas in the history of computing.
> A close second would be making this a standard program installation 
> directory in some widely-distributed operating systems.
> A close third would be using the same thing in the standard 
> installation path of some popular open-source software.
> oh well..
> 
> 
> Getting back on-topic however : I do not know anything about Felix, 
> and I have not really followed this thread.  But assuming that this 
> Felix is a web application running under Tomcat, the fact that it has 
> the above in its own configuration file, rather than in some Tomcat 
> configuration file, would tend to make one suspect that Felix is 
> opening its own listening socket, of which Tomcat knows nothing. No ?
> 
> And in such a case, there would be some conflict if one simultaneously 
> to deploying this web application, would try to open a Tomcat 
> Connector on the same port.
> One of them is bound to fail.

Felix is an OSGi thingy, which means it can ... do all kinds of things you 
didn't expect it to do. Like turning a server daemon (Tomcat) into a small 
component in a larger system in a single JVM where the daemon is no longer 
completely in charge of the process.

So it's plausible that Felix would be configuring the  even if it 
had never been configured through server.xml.

-chris

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

Re: Tomcat answers on port 80, not on 443

[Christopher Schultz]

André,

On 10/23/15 4:16 PM, André Warnier (tomcat) wrote:
> On 23.10.2015 16:53, Beyer, Gregory L wrote:
> ...
> ##
> # Inbound SSL Settings
> ##
> 
> org.apache.felix.https.enable=true
> org.osgi.service.http.port.secure=443
>  org.apache.felix.https.keystore=E:\\Program
> Files\\Connector\\.keystore
>  org.apache.felix.https.keystore.password=REDACTED
>  org.apache.felix.https.keystore.key.password= REDACTED
>  org.apache.felix.https.truststore=C:\\Program
> Files\\Java\\jre1.8.0_60\\lib\\security\\cacerts
>  org.apache.felix.https.truststore.password= REDACTED
>>
>> Question  -- Does anyone think " Program Files"  (space) above is
>> contributing to the problem?
>>
> 
> Maybe, maybe not.  It would depend on how "Felix" parses its
> configuration files.
> 
> 
> But in any case, admitting spaces in file names is certainly one of the
> stupidest and most costly ideas in the history of computing.
> A close second would be making this a standard program installation
> directory in some widely-distributed operating systems.
> A close third would be using the same thing in the standard installation
> path of some popular open-source software.
> oh well..
> 
> 
> Getting back on-topic however : I do not know anything about Felix, and
> I have not really followed this thread.  But assuming that this Felix is
> a web application running under Tomcat, the fact that it has the above
> in its own configuration file, rather than in some Tomcat configuration
> file, would tend to make one suspect that Felix is opening its own
> listening socket, of which Tomcat knows nothing. No ?
> 
> And in such a case, there would be some conflict if one simultaneously
> to deploying this web application, would try to open a Tomcat Connector
> on the same port.
> One of them is bound to fail.

Felix is an OSGi thingy, which means it can ... do all kinds of things
you didn't expect it to do. Like turning a server daemon (Tomcat) into a
small component in a larger system in a single JVM where the daemon is
no longer completely in charge of the process.

So it's plausible that Felix would be configuring the  even
if it had never been configured through server.xml.

-chris

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

Re: Tomcat answers on port 80, not on 443

[tomcat]

On 23.10.2015 16:53, Beyer, Gregory L wrote:
...
##
# Inbound SSL Settings
##

org.apache.felix.https.enable=true
org.osgi.service.http.port.secure=443
org.apache.felix.https.keystore=E:\\Program Files\\Connector\\.keystore
org.apache.felix.https.keystore.password=REDACTED
org.apache.felix.https.keystore.key.password= REDACTED
 	org.apache.felix.https.truststore=C:\\Program 
Files\\Java\\jre1.8.0_60\\lib\\security\\cacerts

org.apache.felix.https.truststore.password= REDACTED


Question  -- Does anyone think " Program Files"  (space) above is contributing 
to the problem?



Maybe, maybe not.  It would depend on how "Felix" parses its configuration 
files.


But in any case, admitting spaces in file names is certainly one of the stupidest and most 
costly ideas in the history of computing.
A close second would be making this a standard program installation directory in some 
widely-distributed operating systems.
A close third would be using the same thing in the standard installation path of some 
popular open-source software.

oh well..


Getting back on-topic however : I do not know anything about Felix, and I have not really 
followed this thread.  But assuming that this Felix is a web application running under 
Tomcat, the fact that it has the above in its own configuration file, rather than in some 
Tomcat configuration file, would tend to make one suspect that Felix is opening its own 
listening socket, of which Tomcat knows nothing. No ?


And in such a case, there would be some conflict if one simultaneously to deploying this 
web application, would try to open a Tomcat Connector on the same port.

One of them is bound to fail.

[...]


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

RE: Tomcat answers on port 80, not on 443

[Beyer, Gregory L]

mpl.run(FrameworkStartLevelImpl.java:304)
 ~[org.apache.felix.main-4.2.1.jar:na]
at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_60]
2015-10-23 09:34:11 [o.e.j.u.c.AbstractLifeCycle] WARN   - FAILED 
SslSelectChannelConnector@0.0.0.0:443: java.security.UnrecoverableKeyException: 
Cannot recover key
java.security.UnrecoverableKeyException: Cannot recover key
at sun.security.provider.KeyProtector.recover(Unknown Source) 
~[na:1.8.0_60]
at sun.security.provider.JavaKeyStore.engineGetKey(Unknown Source) 
~[na:1.8.0_60]



Second Question - am I supposed to import the .keystore into my cacerts file?  
When I open the cacerts file that came with the java install,  it contains  
30-40 certifs (key-pairs?)   that I didn't create.

Thanks all for any leads or answers to my SSL noob questions you can provide.

__
Gregory Beyer
gbey...@gatech.edu

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Friday, October 16, 2015 10:54 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat answers on port 80, not on 443

2015-10-15 20:48 GMT+03:00 Beyer, Gregory L <gregory.be...@business.gatech.edu>:
>
> Hello,
>
> I'm trying to get my web app, which is otherwise running fine on port 80 to 
> respond on SSL.   Sorry if this is a resend.  I only just started getting 
> list messages so my first may not have gone.  Don't intend to bump.
>
> Scenario:
>
> The server in question is a Windows12 web application host running Tomcat 
> 8.0.26.   Running on Tomcat is a java application which accepts port 80  
> connections from another host across the 'net.  I have firewall rules 
> configured to allow port 80 and 443 traffic between the servers.   80 This is 
> working fine.   I'm not running IIS - only Tomcat.
>
> However, we don't want to have our data stream exposed clear text over the 
> internet - we need to use SSL.
>
> I have used %JAVA_HOME%\bin\keytool to generate a keystore and then have 
> configured the InBound SSL Settings in my apps config.properties file with 
> the path to the keystore and the password.  The # lines are variations on the 
> path to the truststore that I have attempted unsuccessfully.  I'm using the 
> default certificate, below.  Webclients will not be connecting so we don't 
> need a commercial certificate.  This is a server to server web call.
>
> ##
> # Inbound SSL Settings
> ##
>
> org.apache.felix.https.enable=true
> org.osgi.service.http.port.secure=443
> org.apache.felix.https.keystore=E:\keystore\scilexcon
> #org.apache.felix.https.keystore=./keystore/scilexcon
> org.apache.felix.https.keystore.password=redacted
> org.apache.felix.https.keystore.key.password= redacted 
> org.apache.felix.https.truststore=E:\keystore\scilexcon
> #org.apache.felix.https.truststore=C:\Program 
> Files\Java\jre1.8.0_60\lib\security\cacerts
> #org.apache.felix.https.truststore=./keystore/scilexcon
> org.apache.felix.https.truststore.password= redacted
>

1)
Is above a *.properties file?  If so then '\' works as an escape symbol and 
must be doubled (\\). Usually people just use '/' instead, it usually works 
with Java.

> ./keystore/scilexcon

2)
"." is the current directory when you start a program. It may be different 
depending on you you start it. (E.g. for Tomcat started explicitly via 
startup.bat vs started as a service  it may be different).

> I've also configured the java runtime of my application with the trustore 
> path:
>
> -Djavax.net.ssl.trustStore=E:\keystore\scilexcon
>
>
>
> An http connect to my connect runtime is successful.  http://
> https:// times out
>
> Netstat -a reveals that port 443 is listening on 
>
>
> Documents I have used so far is one documenting the Inbound SSL 
> connections of my apps config file, and the SLL documentation of 
> Apache Tomcat  http://8080/docs/ssl-howto.html
>
> In my server.xml, I've unremmed the connector section and changed the 
> connector port to 443:
>
>
> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>clientAuth="false" sslProtocol="TLS" />
>
>
>  Define an AJP 1.3 Connector on port 8009 -->
> 
>
> I've looked through my logs, but don't find anything to indicate why it just 
> clocks until timing out.  Maybe I'm missing something?
>
> Having read the SSL howto, I don't think I've missed anything.

3)
https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Common_Troubleshooting_Scenario

Try connecting with a web browser or a standard tool (like wget, openssl 
client) to check that HTTPS w

Re: Tomcat answers on port 80, not on 443

[Christopher Schultz]

Gregory,

On 10/15/15 1:48 PM, Beyer, Gregory L wrote:
> ##
> # Inbound SSL Settings
> ##
> 
> org.apache.felix.https.enable=true
> org.osgi.service.http.port.secure=443
> org.apache.felix.https.keystore=E:\keystore\scilexcon
> #org.apache.felix.https.keystore=./keystore/scilexcon
> org.apache.felix.https.keystore.password=redacted
> org.apache.felix.https.keystore.key.password= redacted
> org.apache.felix.https.truststore=E:\keystore\scilexcon
> #org.apache.felix.https.truststore=C:\Program 
> Files\Java\jre1.8.0_60\lib\security\cacerts
> #org.apache.felix.https.truststore=./keystore/scilexcon
> org.apache.felix.https.truststore.password= redacted

I'm not sure how Apache Felix fits into this (I don't know a thing about
Felix), but:

> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>clientAuth="false" sslProtocol="TLS" />

This connector has no reference to any keystore configuration. Unless
Felix is somehow wiring that all up, then you haven't configured a
viable TLS connector.

-chris

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

Re: Tomcat answers on port 80, not on 443

[Konstantin Kolinko]

2015-10-15 20:48 GMT+03:00 Beyer, Gregory L :
>
> Hello,
>
> I'm trying to get my web app, which is otherwise running fine on port 80 to 
> respond on SSL.   Sorry if this is a resend.  I only just started getting 
> list messages so my first may not have gone.  Don't intend to bump.
>
> Scenario:
>
> The server in question is a Windows12 web application host running Tomcat 
> 8.0.26.   Running on Tomcat is a java application which accepts port 80  
> connections from another host across the 'net.  I have firewall rules 
> configured to allow port 80 and 443 traffic between the servers.   80 This is 
> working fine.   I'm not running IIS - only Tomcat.
>
> However, we don't want to have our data stream exposed clear text over the 
> internet - we need to use SSL.
>
> I have used %JAVA_HOME%\bin\keytool to generate a keystore and then have 
> configured the InBound SSL Settings in my apps config.properties file with 
> the path to the keystore and the password.  The # lines are variations on the 
> path to the truststore that I have attempted unsuccessfully.  I'm using the 
> default certificate, below.  Webclients will not be connecting so we don't 
> need a commercial certificate.  This is a server to server web call.
>
> ##
> # Inbound SSL Settings
> ##
>
> org.apache.felix.https.enable=true
> org.osgi.service.http.port.secure=443
> org.apache.felix.https.keystore=E:\keystore\scilexcon
> #org.apache.felix.https.keystore=./keystore/scilexcon
> org.apache.felix.https.keystore.password=redacted
> org.apache.felix.https.keystore.key.password= redacted
> org.apache.felix.https.truststore=E:\keystore\scilexcon
> #org.apache.felix.https.truststore=C:\Program 
> Files\Java\jre1.8.0_60\lib\security\cacerts
> #org.apache.felix.https.truststore=./keystore/scilexcon
> org.apache.felix.https.truststore.password= redacted
>

1)
Is above a *.properties file?  If so then '\' works as an escape
symbol and must be doubled (\\). Usually people just use '/' instead,
it usually works with Java.

> ./keystore/scilexcon

2)
"." is the current directory when you start a program. It may be
different depending on you you start it. (E.g. for Tomcat started
explicitly via startup.bat vs started as a service  it may be
different).

> I've also configured the java runtime of my application with the trustore 
> path:
>
> -Djavax.net.ssl.trustStore=E:\keystore\scilexcon
>
>
>
> An http connect to my connect runtime is successful.  http://
> https:// times out
>
> Netstat -a reveals that port 443 is listening on 
>
>
> Documents I have used so far is one documenting the Inbound SSL connections 
> of my apps config file, and the SLL documentation of Apache Tomcat  
> http://8080/docs/ssl-howto.html
>
> In my server.xml, I've unremmed the connector section and changed the 
> connector port to 443:
>
>
> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>clientAuth="false" sslProtocol="TLS" />
>
>
>  Define an AJP 1.3 Connector on port 8009 -->
> 
>
> I've looked through my logs, but don't find anything to indicate why it just 
> clocks until timing out.  Maybe I'm missing something?
>
> Having read the SSL howto, I don't think I've missed anything.

3)
https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Common_Troubleshooting_Scenario

Try connecting with a web browser or a standard tool (like wget,
openssl client) to check that HTTPS works.

Look into an access log.

Take a series of thread dumps (for your client as well).

4) Is Java trusing your self-signed server certificate (so that it is
able to connect to it)?

Old versions of Java (Java 6) use SSLv2Hello when initialing a HTTPS
connection. That protocol is disabled by default in current versions
of Tomcat.
https://wiki.apache.org/tomcat/Security/POODLE

Best regards,
Konstantin Kolinko

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