Re: Trouble using SSL with Tomcat 9

2017-09-27 Thread Don Flinn
Thanks Chuck,

As is obvious, I'm not an experienced admin, but a developer.  I picked
another unused port, 447, and tried again.  I'm not running Tomcat as
root.  I want to get the self signed cert working before purchasing an SSL
certificate.

This WORKED.  Thanks for all the help.  Note that I just picked an unused
port at random, not knowing any better.  I'm sure that there is a more
sophisticated way to pick a port to use.  I'm guessing that if I have
Tomcat grab that port it will keep it while it is running.  But for now I'm
over-joyed,

Don

On Wed, Sep 27, 2017 at 1:24 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Don Flinn [mailto:fl...@alum.mit.edu]
> > Subject: Re: Trouble using SSL with Tomcat 9
>
> > I installed a new download of tomcat 9, established one application with
> > php/java bridge (need php and java access). Set the SSL port to an unused
> > port, 443, and ran my app who's only out put is an H1 message.  This time
> I
> > get the expected error from Chrome with the red warning about bad
> > certificate.  However, the redirect went to https://localhost/Financial/
> > index.php - i.e. NO port number and of course drilling down couldn't find
> > my app which is at port 443, I believe.
>
> Port 443 is the standard HTTPS port, so it won't show up in the https: URL
> since it's the default.
>
> Unless you're running Tomcat as root (a very, very bad idea), you'll need
> to
> use iptables or equivalent to let Tomcat listen on port 443.
> https://wiki.apache.org/tomcat/HowTo#How_to_run_
> Tomcat_without_root_privileg
> es.3F
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>


RE: Trouble using SSL with Tomcat 9

2017-09-27 Thread Caldarale, Charles R
> From: Don Flinn [mailto:fl...@alum.mit.edu] 
> Subject: Re: Trouble using SSL with Tomcat 9

> I installed a new download of tomcat 9, established one application with
> php/java bridge (need php and java access). Set the SSL port to an unused
> port, 443, and ran my app who's only out put is an H1 message.  This time
I
> get the expected error from Chrome with the red warning about bad
> certificate.  However, the redirect went to https://localhost/Financial/
> index.php - i.e. NO port number and of course drilling down couldn't find
> my app which is at port 443, I believe.

Port 443 is the standard HTTPS port, so it won't show up in the https: URL
since it's the default.

Unless you're running Tomcat as root (a very, very bad idea), you'll need to
use iptables or equivalent to let Tomcat listen on port 443.
https://wiki.apache.org/tomcat/HowTo#How_to_run_Tomcat_without_root_privileg
es.3F

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.



smime.p7s
Description: S/MIME cryptographic signature


Re: Trouble using SSL with Tomcat 9

2017-09-27 Thread Don Flinn
Hi Andre

I installed a new download of tomcat 9, established one application with
php/java bridge (need php and java access). Set the SSL port to an unused
port, 443, and ran my app who's only out put is an H1 message.  This time I
get the expected error from Chrome with the red warning about bad
certificate.  However, the redirect went to https://localhost/Financial/
index.php - i.e. NO port number and of course drilling down couldn't find
my app which is at port 443, I believe.

Progress, but still no cigar.

The tomcat logs only showed  a 302. -  0:0:0:0:0:0:0:1 - -
[27/Sep/2017:05:08:12 -0400] "GET
/Financials/index.php?XDEBUG_SESSION_START=netbeans-xdebug
HTTP/1.1" 302 -

Don't know what my next step should be - any suggestions.  Your help to
this point has been great.  I greatly appreciate the help you are giving me.

Also, I'm sure you have seen, another user, John Ellis, is having somewhat
similar problems.


Don

On Mon, Sep 25, 2017 at 10:26 AM, André Warnier (tomcat) 
wrote:

> On 25.09.2017 15:57, Don Flinn wrote:
>
>> Andre,
>>
>> I've attached the output from netstat -a.  I see 8080 listening, but not
>> 8443.  I've also
>> attached the screen shot of the result of running my "protected"
>> application in Tomcat.
>>
>
> This list removes most attachments, so we did not get the screenshot.
> You have ti post it to dropbox or so, for us to have a look.
>
> But you should definitely look in the tomcat logfiles (in the subdirectory
> inventively named "logs"), to see why it did not open port 8443 when
> supposedly told to do so.
>
> As I mentioned, when I have Norton Security and it shuts down Windows
>> firewall and runs
>> its own firewall.
>>
>
> Yes, but if port 8443 is not open and listening, that's a secondary
> consideration now. The first is why tomcat does not open that port.
>
> P.S. There are additional options to netstat, which will also print the
> name of the process which "owns" that port. Makes it easier to scan the
> list, because it will say
> "tomcat" next to the ones opened by tomcat.
>
>
>> Don
>>
>> On Sun, Sep 24, 2017 at 5:52 PM, André Warnier (tomcat) > > wrote:
>>
>> On 24.09.2017 16 :08, Don Flinn wrote:
>>
>> Andre,
>>
>> I apologize for not giving all my information. As you perceived,
>> I'm
>> running Windows. Other info, Windows 10, Tomcat 9, java
>> 1.8.0_144.  As you
>> suggested, using netstat and telnet I found that port 8443 is not
>> open.
>> Looking further Windows firewall is controlled by Norton
>> security.  I am
>> now trying to find out how to open ports in Norton security using
>> the
>> Norton blog.
>>
>> Thank you for your help.  As is obvious, I'm a newbee in low
>> level admin
>> work.  I'm hoping that when I get port 8443 open things will
>> work.  I'll
>> let you know.
>>
>> Maybe wait just a second more, before you go digging in the firewall.
>> You say that you found out that "the port is not open".
>> That is not the same thing as
>> - the port /is/ open
>> - but it cannot be connected to
>> If netstat shows the port open and listening, but you cannot connect
>> to it with
>> telnet, it is probably a firewall issue.
>> But if the port is not open, then it is a tomcat issue.
>> Provided that you configured tomcat properly, the port should be
>> open, firewall or no
>> firewall. (A firewall can only block access by a client, to a server
>> port that is
>> open. It cannot prevent a server process to open that port for
>> listening.)
>> If it isn't open, the tomcat logs should tell you why.
>>
>>
>>
>>
>>
>> Don
>>
>>
>>
>> On Sun, Sep 24, 2017 at 6:44 AM, André Warnier (tomcat) <
>> a...@ice-sa.com
>> >
>> wrote:
>>
>> On 24.09.2017 02 :36, Don Flinn wrote:
>>
>> I'm trying to use a self signed certificate generated in
>> keytool.  When I
>> run the application Chrome, Firefox and internet Explorer
>> using
>> localhost:8080/ all the browsers do a redirect to
>> localhost:8443
>> and
>> then return This site can’t be reachedL*ocalhost* refused
>> to connect.
>> There is no red lined out protocol in any of the
>> browsers.  All the Tomcat
>> logs show no errors or warnings.  I can access
>> applications that are not
>> protected and tomcat itself.
>>
>>
>> I would suggest that you first re-read what you wrote above,
>> line by line,
>> and reflect quietly on what each line is telling you.
>>
>> 1) you say "localhost". That means that you are using a
>> browser as client,
>> on the same machine as the one which is running the server.
>> 2) you also say that one of the 

Re: Trouble using SSL with Tomcat 9

2017-09-25 Thread Don Flinn
I've put the log files, the jpg of the chrome page and the netstat -a -b in
Google Drive and sent you a link.

My application is somewhat complex and hopefully not the cause of the
problem.  It is composed of a large number of php and  javascript files in
the Financials application, which includes the php/java bridge, which calls
into a java application called JFin in a number of places, which also has a
large number of java files,  The JFin jar is placed in the
webapps/Financials/WEB-INFO/lib directory along with a large number of
other jars, which are includes in the java files.  All this runs fine under
Tomcat on port 8080.  The log files ect. that I sent are when I run
localhost:8080/Financials.  The log files capture the restart of Tomcat and
the run of the Financials application. I also have run it under debug in
NetBeans 8.2. and it never gets to the first line in Financials/index.php.

The logs capture Tomcat startup, then run as
localhost:8080/Financials.index.php
in chrome and then at 12:49 I ran it in netbeans debug.  The logs look ok
in the first two cases, but when run under netbeans the tomcat stderr gave
an error -
25-Sep-2017 12:56:18.251 INFO [http-nio-8080-exec-1]
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request
header
 Note: further occurrences of HTTP header parsing errors will be logged at
DEBUG level.
 java.lang.IllegalArgumentException: Invalid character found in method
name. HTTP method names must be tokens
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(
Http11InputBuffer.java:406)

I don't know what this means.  Is it a clue or is it an artifact of
NetBeans debug?  It didn't show up in the run directly from chrome.  I ran
it again at about 1:30pm directly from chrome and the error again didn't
show up.



So the

On Mon, Sep 25, 2017 at 10:26 AM, André Warnier (tomcat) 
wrote:

> On 25.09.2017 15:57, Don Flinn wrote:
>
>> Andre,
>>
>> I've attached the output from netstat -a.  I see 8080 listening, but not
>> 8443.  I've also
>> attached the screen shot of the result of running my "protected"
>> application in Tomcat.
>>
>
> This list removes most attachments, so we did not get the screenshot.
> You have ti post it to dropbox or so, for us to have a look.
>
> But you should definitely look in the tomcat logfiles (in the subdirectory
> inventively named "logs"), to see why it did not open port 8443 when
> supposedly told to do so.
>
> As I mentioned, when I have Norton Security and it shuts down Windows
>> firewall and runs
>> its own firewall.
>>
>
> Yes, but if port 8443 is not open and listening, that's a secondary
> consideration now. The first is why tomcat does not open that port.
>
> P.S. There are additional options to netstat, which will also print the
> name of the process which "owns" that port. Makes it easier to scan the
> list, because it will say
> "tomcat" next to the ones opened by tomcat.
>
>
>> Don
>>
>> On Sun, Sep 24, 2017 at 5:52 PM, André Warnier (tomcat) > > wrote:
>>
>> On 24.09.2017 16 :08, Don Flinn wrote:
>>
>> Andre,
>>
>> I apologize for not giving all my information. As you perceived,
>> I'm
>> running Windows. Other info, Windows 10, Tomcat 9, java
>> 1.8.0_144.  As you
>> suggested, using netstat and telnet I found that port 8443 is not
>> open.
>> Looking further Windows firewall is controlled by Norton
>> security.  I am
>> now trying to find out how to open ports in Norton security using
>> the
>> Norton blog.
>>
>> Thank you for your help.  As is obvious, I'm a newbee in low
>> level admin
>> work.  I'm hoping that when I get port 8443 open things will
>> work.  I'll
>> let you know.
>>
>> Maybe wait just a second more, before you go digging in the firewall.
>> You say that you found out that "the port is not open".
>> That is not the same thing as
>> - the port /is/ open
>> - but it cannot be connected to
>> If netstat shows the port open and listening, but you cannot connect
>> to it with
>> telnet, it is probably a firewall issue.
>> But if the port is not open, then it is a tomcat issue.
>> Provided that you configured tomcat properly, the port should be
>> open, firewall or no
>> firewall. (A firewall can only block access by a client, to a server
>> port that is
>> open. It cannot prevent a server process to open that port for
>> listening.)
>> If it isn't open, the tomcat logs should tell you why.
>>
>>
>>
>>
>>
>> Don
>>
>>
>>
>> On Sun, Sep 24, 2017 at 6:44 AM, André Warnier (tomcat) <
>> a...@ice-sa.com
>> >
>> wrote:
>>
>> On 24.09.2017 02 :36, Don Flinn wrote:
>>
>> I'm trying to use a self signed certificate generated in
>> keytool.  When I
>> run the application 

Re: Trouble using SSL with Tomcat 9

2017-09-25 Thread tomcat

On 25.09.2017 15:57, Don Flinn wrote:

Andre,

I've attached the output from netstat -a.  I see 8080 listening, but not 8443.  
I've also
attached the screen shot of the result of running my "protected" application in 
Tomcat.


This list removes most attachments, so we did not get the screenshot.
You have ti post it to dropbox or so, for us to have a look.

But you should definitely look in the tomcat logfiles (in the subdirectory inventively 
named "logs"), to see why it did not open port 8443 when supposedly told to do so.



As I mentioned, when I have Norton Security and it shuts down Windows firewall 
and runs
its own firewall.


Yes, but if port 8443 is not open and listening, that's a secondary consideration now. The 
first is why tomcat does not open that port.


P.S. There are additional options to netstat, which will also print the name of the 
process which "owns" that port. Makes it easier to scan the list, because it will say

"tomcat" next to the ones opened by tomcat.



Don

On Sun, Sep 24, 2017 at 5:52 PM, André Warnier (tomcat) > wrote:

On 24.09.2017 16 :08, Don Flinn wrote:

Andre,

I apologize for not giving all my information. As you perceived, I'm
running Windows. Other info, Windows 10, Tomcat 9, java 1.8.0_144.  As 
you
suggested, using netstat and telnet I found that port 8443 is not open.
Looking further Windows firewall is controlled by Norton security.  I am
now trying to find out how to open ports in Norton security using the
Norton blog.

Thank you for your help.  As is obvious, I'm a newbee in low level admin
work.  I'm hoping that when I get port 8443 open things will work.  I'll
let you know.

Maybe wait just a second more, before you go digging in the firewall.
You say that you found out that "the port is not open".
That is not the same thing as
- the port /is/ open
- but it cannot be connected to
If netstat shows the port open and listening, but you cannot connect to it 
with
telnet, it is probably a firewall issue.
But if the port is not open, then it is a tomcat issue.
Provided that you configured tomcat properly, the port should be open, 
firewall or no
firewall. (A firewall can only block access by a client, to a server port 
that is
open. It cannot prevent a server process to open that port for listening.)
If it isn't open, the tomcat logs should tell you why.





Don



On Sun, Sep 24, 2017 at 6:44 AM, André Warnier (tomcat) >
wrote:

On 24.09.2017 02 :36, Don Flinn wrote:

I'm trying to use a self signed certificate generated in 
keytool.  When I
run the application Chrome, Firefox and internet Explorer using
localhost:8080/ all the browsers do a redirect to 
localhost:8443
and
then return This site can’t be reachedL*ocalhost* refused to 
connect.
There is no red lined out protocol in any of the browsers.  All 
the Tomcat
logs show no errors or warnings.  I can access applications 
that are not
protected and tomcat itself.


I would suggest that you first re-read what you wrote above, line 
by line,
and reflect quietly on what each line is telling you.

1) you say "localhost". That means that you are using a browser as 
client,
on the same machine as the one which is running the server.
2) you also say that one of the browsers is IE.
3) (1) and (2) together imply that the host in a Windows server 
(and the
client also of course).
4) you are not saying which version of Tomcat you are using, 
neither which
version of Java, neither which version of Windows.  That makes 
helping you
more complicated and time-consuming, and delays any help, because 
now we
have to ask you, and you have to respond.
5) "refused to connect" : before any kind of SSL dialog can even 
take
place, the browser must be able to establish a TCP connection to the
host:port in question.
"refused to connect" seens to indicate that this is not the case.
6) the logs do not show anything : that would seem to corroborate 
(5) :
tomcat does not even see this connection. iow, there is no 
connection.

There are several possible reasons for this.
a) Tomcat never opens the port 8443 for listening on it.
That can be checked, with tomcat running, with the "netstat" utility
program, included in Windows. With the proper arguments (which I 
will leave
to you as an exercise)(but "netstat -h" will help), netstat will 
show you
 

Re: Trouble using SSL with Tomcat 9

2017-09-25 Thread Don Flinn
Andre,

I've attached the output from netstat -a.  I see 8080 listening, but not
8443.  I've also attached the screen shot of the result of running my
"protected" application in Tomcat.  As I mentioned, when I have Norton
Security and it shuts down Windows firewall and runs its own firewall.

Don

On Sun, Sep 24, 2017 at 5:52 PM, André Warnier (tomcat) 
wrote:

> On 24.09.2017 16:08, Don Flinn wrote:
>
>> Andre,
>>
>> I apologize for not giving all my information. As you perceived, I'm
>> running Windows. Other info, Windows 10, Tomcat 9, java 1.8.0_144.  As you
>> suggested, using netstat and telnet I found that port 8443 is not open.
>> Looking further Windows firewall is controlled by Norton security.  I am
>> now trying to find out how to open ports in Norton security using the
>> Norton blog.
>>
>> Thank you for your help.  As is obvious, I'm a newbee in low level admin
>> work.  I'm hoping that when I get port 8443 open things will work.  I'll
>> let you know.
>>
>> Maybe wait just a second more, before you go digging in the firewall.
> You say that you found out that "the port is not open".
> That is not the same thing as
> - the port /is/ open
> - but it cannot be connected to
> If netstat shows the port open and listening, but you cannot connect to it
> with telnet, it is probably a firewall issue.
> But if the port is not open, then it is a tomcat issue.
> Provided that you configured tomcat properly, the port should be open,
> firewall or no firewall. (A firewall can only block access by a client, to
> a server port that is open. It cannot prevent a server process to open that
> port for listening.)
> If it isn't open, the tomcat logs should tell you why.
>
>
>
>
>
> Don
>>
>>
>>
>> On Sun, Sep 24, 2017 at 6:44 AM, André Warnier (tomcat) 
>> wrote:
>>
>> On 24.09.2017 02:36, Don Flinn wrote:
>>>
>>> I'm trying to use a self signed certificate generated in keytool.  When I
 run the application Chrome, Firefox and internet Explorer using
 localhost:8080/ all the browsers do a redirect to localhost:8443
 and
 then return This site can’t be reachedL*ocalhost* refused to connect.
 There is no red lined out protocol in any of the browsers.  All the
 Tomcat
 logs show no errors or warnings.  I can access applications that are not
 protected and tomcat itself.


>>> I would suggest that you first re-read what you wrote above, line by
>>> line,
>>> and reflect quietly on what each line is telling you.
>>>
>>> 1) you say "localhost". That means that you are using a browser as
>>> client,
>>> on the same machine as the one which is running the server.
>>> 2) you also say that one of the browsers is IE.
>>> 3) (1) and (2) together imply that the host in a Windows server (and the
>>> client also of course).
>>> 4) you are not saying which version of Tomcat you are using, neither
>>> which
>>> version of Java, neither which version of Windows.  That makes helping
>>> you
>>> more complicated and time-consuming, and delays any help, because now we
>>> have to ask you, and you have to respond.
>>> 5) "refused to connect" : before any kind of SSL dialog can even take
>>> place, the browser must be able to establish a TCP connection to the
>>> host:port in question.
>>> "refused to connect" seens to indicate that this is not the case.
>>> 6) the logs do not show anything : that would seem to corroborate (5) :
>>> tomcat does not even see this connection. iow, there is no connection.
>>>
>>> There are several possible reasons for this.
>>> a) Tomcat never opens the port 8443 for listening on it.
>>> That can be checked, with tomcat running, with the "netstat" utility
>>> program, included in Windows. With the proper arguments (which I will
>>> leave
>>> to you as an exercise)(but "netstat -h" will help), netstat will show you
>>> on which ports tomcat is listening locally.  If this does not include a
>>> ":8443" port, then it is not listening on that port, and certainly the
>>> logs
>>> of tomcat will tell you why.
>>> b) tomcat does listen on port 8443, but something else is blocking access
>>> to that port.
>>> Then you probably have to check your local firewall settings (or whatever
>>> else in whatever version of Windows may be blocking connections to a
>>> port).
>>>
>>> Another quick way to check if tomcat (or anything) is listening on port
>>> 8443 (and/or something is blocking it) would be, in a command window, to
>>> run the following command :
>>> telnet localhost 8443
>>> (also with tomcat running)
>>> If it also tells you "no connection", then (a) or (b) above would be
>>> confirmed.
>>> If it connects, then you may get another message, due to the fact that it
>>> expects an SSL connection. (If it did not expect an SSL connection, you'd
>>> just get a blank page until you type something else).
>>> Obviously, access to tomcat's port 8080 is fine, so you can compare the
>>> responses above with what happens when you substitute 

Re: Trouble using SSL with Tomcat 9

2017-09-24 Thread tomcat

On 24.09.2017 16:08, Don Flinn wrote:

Andre,

I apologize for not giving all my information. As you perceived, I'm
running Windows. Other info, Windows 10, Tomcat 9, java 1.8.0_144.  As you
suggested, using netstat and telnet I found that port 8443 is not open.
Looking further Windows firewall is controlled by Norton security.  I am
now trying to find out how to open ports in Norton security using the
Norton blog.

Thank you for your help.  As is obvious, I'm a newbee in low level admin
work.  I'm hoping that when I get port 8443 open things will work.  I'll
let you know.


Maybe wait just a second more, before you go digging in the firewall.
You say that you found out that "the port is not open".
That is not the same thing as
- the port /is/ open
- but it cannot be connected to
If netstat shows the port open and listening, but you cannot connect to it with telnet, it 
is probably a firewall issue.

But if the port is not open, then it is a tomcat issue.
Provided that you configured tomcat properly, the port should be open, firewall or no 
firewall. (A firewall can only block access by a client, to a server port that is open. It 
cannot prevent a server process to open that port for listening.)

If it isn't open, the tomcat logs should tell you why.






Don



On Sun, Sep 24, 2017 at 6:44 AM, André Warnier (tomcat) 
wrote:


On 24.09.2017 02:36, Don Flinn wrote:


I'm trying to use a self signed certificate generated in keytool.  When I
run the application Chrome, Firefox and internet Explorer using
localhost:8080/ all the browsers do a redirect to localhost:8443
and
then return This site can’t be reachedL*ocalhost* refused to connect.
There is no red lined out protocol in any of the browsers.  All the Tomcat
logs show no errors or warnings.  I can access applications that are not
protected and tomcat itself.



I would suggest that you first re-read what you wrote above, line by line,
and reflect quietly on what each line is telling you.

1) you say "localhost". That means that you are using a browser as client,
on the same machine as the one which is running the server.
2) you also say that one of the browsers is IE.
3) (1) and (2) together imply that the host in a Windows server (and the
client also of course).
4) you are not saying which version of Tomcat you are using, neither which
version of Java, neither which version of Windows.  That makes helping you
more complicated and time-consuming, and delays any help, because now we
have to ask you, and you have to respond.
5) "refused to connect" : before any kind of SSL dialog can even take
place, the browser must be able to establish a TCP connection to the
host:port in question.
"refused to connect" seens to indicate that this is not the case.
6) the logs do not show anything : that would seem to corroborate (5) :
tomcat does not even see this connection. iow, there is no connection.

There are several possible reasons for this.
a) Tomcat never opens the port 8443 for listening on it.
That can be checked, with tomcat running, with the "netstat" utility
program, included in Windows. With the proper arguments (which I will leave
to you as an exercise)(but "netstat -h" will help), netstat will show you
on which ports tomcat is listening locally.  If this does not include a
":8443" port, then it is not listening on that port, and certainly the logs
of tomcat will tell you why.
b) tomcat does listen on port 8443, but something else is blocking access
to that port.
Then you probably have to check your local firewall settings (or whatever
else in whatever version of Windows may be blocking connections to a port).

Another quick way to check if tomcat (or anything) is listening on port
8443 (and/or something is blocking it) would be, in a command window, to
run the following command :
telnet localhost 8443
(also with tomcat running)
If it also tells you "no connection", then (a) or (b) above would be
confirmed.
If it connects, then you may get another message, due to the fact that it
expects an SSL connection. (If it did not expect an SSL connection, you'd
just get a blank page until you type something else).
Obviously, access to tomcat's port 8080 is fine, so you can compare the
responses above with what happens when you substitute 8080 for 8443.

Once the above is really cleared up, then it may be worth looking at the
rest of the information which you sent below.

  If I set 


CONFIDENTIAL to NONE everything works with
localhost:8080.

My SSL files in tomcat -

*server.xml -*

Connector
protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEI
mplementation"
SSLEnabled="true" acceptCount="100" clientAuth="false"
disableUploadTimeout="true" enableLookups="false" maxThreads="25"
port="8443" keystoreFile="c:/temp/mkeystore2.jks" keystorePass="foobar"
secure="true" sslProtocol="TLS" clientAuth="false" />

*web.xml -*


  
  Financials
  /*
  
   

Re: Trouble using SSL with Tomcat 9

2017-09-24 Thread Don Flinn
Andre,

I apologize for not giving all my information. As you perceived, I'm
running Windows. Other info, Windows 10, Tomcat 9, java 1.8.0_144.  As you
suggested, using netstat and telnet I found that port 8443 is not open.
Looking further Windows firewall is controlled by Norton security.  I am
now trying to find out how to open ports in Norton security using the
Norton blog.

Thank you for your help.  As is obvious, I'm a newbee in low level admin
work.  I'm hoping that when I get port 8443 open things will work.  I'll
let you know.

Don



On Sun, Sep 24, 2017 at 6:44 AM, André Warnier (tomcat) 
wrote:

> On 24.09.2017 02:36, Don Flinn wrote:
>
>> I'm trying to use a self signed certificate generated in keytool.  When I
>> run the application Chrome, Firefox and internet Explorer using
>> localhost:8080/ all the browsers do a redirect to localhost:8443
>> and
>> then return This site can’t be reachedL*ocalhost* refused to connect.
>> There is no red lined out protocol in any of the browsers.  All the Tomcat
>> logs show no errors or warnings.  I can access applications that are not
>> protected and tomcat itself.
>>
>
> I would suggest that you first re-read what you wrote above, line by line,
> and reflect quietly on what each line is telling you.
>
> 1) you say "localhost". That means that you are using a browser as client,
> on the same machine as the one which is running the server.
> 2) you also say that one of the browsers is IE.
> 3) (1) and (2) together imply that the host in a Windows server (and the
> client also of course).
> 4) you are not saying which version of Tomcat you are using, neither which
> version of Java, neither which version of Windows.  That makes helping you
> more complicated and time-consuming, and delays any help, because now we
> have to ask you, and you have to respond.
> 5) "refused to connect" : before any kind of SSL dialog can even take
> place, the browser must be able to establish a TCP connection to the
> host:port in question.
> "refused to connect" seens to indicate that this is not the case.
> 6) the logs do not show anything : that would seem to corroborate (5) :
> tomcat does not even see this connection. iow, there is no connection.
>
> There are several possible reasons for this.
> a) Tomcat never opens the port 8443 for listening on it.
> That can be checked, with tomcat running, with the "netstat" utility
> program, included in Windows. With the proper arguments (which I will leave
> to you as an exercise)(but "netstat -h" will help), netstat will show you
> on which ports tomcat is listening locally.  If this does not include a
> ":8443" port, then it is not listening on that port, and certainly the logs
> of tomcat will tell you why.
> b) tomcat does listen on port 8443, but something else is blocking access
> to that port.
> Then you probably have to check your local firewall settings (or whatever
> else in whatever version of Windows may be blocking connections to a port).
>
> Another quick way to check if tomcat (or anything) is listening on port
> 8443 (and/or something is blocking it) would be, in a command window, to
> run the following command :
> telnet localhost 8443
> (also with tomcat running)
> If it also tells you "no connection", then (a) or (b) above would be
> confirmed.
> If it connects, then you may get another message, due to the fact that it
> expects an SSL connection. (If it did not expect an SSL connection, you'd
> just get a blank page until you type something else).
> Obviously, access to tomcat's port 8080 is fine, so you can compare the
> responses above with what happens when you substitute 8080 for 8443.
>
> Once the above is really cleared up, then it may be worth looking at the
> rest of the information which you sent below.
>
>  If I set 
>
>> CONFIDENTIAL to NONE everything works with
>> localhost:8080.
>>
>> My SSL files in tomcat -
>>
>> *server.xml -*
>>
>> Connector
>> protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
>> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEI
>> mplementation"
>> SSLEnabled="true" acceptCount="100" clientAuth="false"
>> disableUploadTimeout="true" enableLookups="false" maxThreads="25"
>> port="8443" keystoreFile="c:/temp/mkeystore2.jks" keystorePass="foobar"
>> secure="true" sslProtocol="TLS" clientAuth="false" />
>>
>> *web.xml -*
>>
>> 
>>  
>>  Financials
>>  /*
>>  
>>  
>>  CONFIDENTIAL
>>  
>> 
>>
>> *the output from my keystore  list -*
>>
>> C:\Users\don\Documents\Mansurus\Security> "%java_home%/bin/keytool.exe"
>> -list  -v -keystore c:/temp/mkeystore2.jks
>> Enter keystore password:
>>
>> Keystore type: JKS
>> Keystore provider: SUN
>>
>> Your keystore contains 1 entry
>>
>> Alias name: tomcat
>> Creation date: Sep 23, 2017
>> Entry type: PrivateKeyEntry
>> Certificate chain length: 1
>> Certificate[1]:
>> Owner: CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
>> Issuer: 

Re: Trouble using SSL with Tomcat 9

2017-09-24 Thread tomcat

On 24.09.2017 02:36, Don Flinn wrote:

I'm trying to use a self signed certificate generated in keytool.  When I
run the application Chrome, Firefox and internet Explorer using
localhost:8080/ all the browsers do a redirect to localhost:8443 and
then return This site can’t be reachedL*ocalhost* refused to connect.
There is no red lined out protocol in any of the browsers.  All the Tomcat
logs show no errors or warnings.  I can access applications that are not
protected and tomcat itself.


I would suggest that you first re-read what you wrote above, line by line, and reflect 
quietly on what each line is telling you.


1) you say "localhost". That means that you are using a browser as client, on the same 
machine as the one which is running the server.

2) you also say that one of the browsers is IE.
3) (1) and (2) together imply that the host in a Windows server (and the client also of 
course).
4) you are not saying which version of Tomcat you are using, neither which version of 
Java, neither which version of Windows.  That makes helping you more complicated and 
time-consuming, and delays any help, because now we have to ask you, and you have to respond.
5) "refused to connect" : before any kind of SSL dialog can even take place, the browser 
must be able to establish a TCP connection to the host:port in question.

"refused to connect" seens to indicate that this is not the case.
6) the logs do not show anything : that would seem to corroborate (5) : tomcat does not 
even see this connection. iow, there is no connection.


There are several possible reasons for this.
a) Tomcat never opens the port 8443 for listening on it.
That can be checked, with tomcat running, with the "netstat" utility program, included in 
Windows. With the proper arguments (which I will leave to you as an exercise)(but "netstat 
-h" will help), netstat will show you on which ports tomcat is listening locally.  If this 
does not include a ":8443" port, then it is not listening on that port, and certainly the 
logs of tomcat will tell you why.

b) tomcat does listen on port 8443, but something else is blocking access to 
that port.
Then you probably have to check your local firewall settings (or whatever else in whatever 
version of Windows may be blocking connections to a port).


Another quick way to check if tomcat (or anything) is listening on port 8443 (and/or 
something is blocking it) would be, in a command window, to run the following command :

telnet localhost 8443
(also with tomcat running)
If it also tells you "no connection", then (a) or (b) above would be confirmed.
If it connects, then you may get another message, due to the fact that it expects an SSL 
connection. (If it did not expect an SSL connection, you'd just get a blank page until you 
type something else).
Obviously, access to tomcat's port 8080 is fine, so you can compare the responses above 
with what happens when you substitute 8080 for 8443.


Once the above is really cleared up, then it may be worth looking at the rest of the 
information which you sent below.


 If I set 

CONFIDENTIAL to NONE everything works with
localhost:8080.

My SSL files in tomcat -

*server.xml -*

Connector
protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
SSLEnabled="true" acceptCount="100" clientAuth="false"
disableUploadTimeout="true" enableLookups="false" maxThreads="25"
port="8443" keystoreFile="c:/temp/mkeystore2.jks" keystorePass="foobar"
secure="true" sslProtocol="TLS" clientAuth="false" />

*web.xml -*


 
 Financials
 /*
 
 
 CONFIDENTIAL
 


*the output from my keystore  list -*

C:\Users\don\Documents\Mansurus\Security> "%java_home%/bin/keytool.exe"
-list  -v -keystore c:/temp/mkeystore2.jks
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: tomcat
Creation date: Sep 23, 2017
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
Issuer: CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown
Serial number: 6b5fe428
Valid from: Sat Sep 23 12:57:19 EDT 2017 until: Sun Sep 23 12:57:19 EDT 2018
Certificate fingerprints:
  MD5:  11:9D:2C:50:4A:09:9D:17:2F:46:3C:AF:AF:E5:59:EE
  SHA1: 63:EF:21:21:3C:22:82:46:21:84:9C:81:C6:B0:C1:EC:0F:1C:87:31
  SHA256:
4E:75:D6:6A:6C:23:84:E0:36:AF:CF:1E:56:7D:18:6E:A1:BE:E5:EE:0B:E5:7B:2A:01:96:DF:49:CA:F1:50:C7
  Signature algorithm name: SHA256withRSA
  Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: 46 C9 48 D4 54 2A 54 CE   24 1F 22 ED 1D FC 6E 14  F.H.T*T.$."...n.
0010: BE 6F 4A 49.oJI
]
]

What am I doing wrong?  I want to get a self-signed keystore working before
I purchase a commercial