TC 7.0.54 / RHEL 6
I have two physical servers, each running an instance of TC. The servers
are behind a hardware loadbalancer. IPTables is routing request on 80 to
8080. Tomcat runs under a non-root user. All good.
I needed to protect an area of our webapp under SSL. Went ahead and
installed
On Fri, Aug 1, 2014 at 11:13 AM, John Smith tomcat.ran...@gmail.com wrote:
TC 7.0.54 / RHEL 6
I have two physical servers, each running an instance of TC. The servers
are behind a hardware loadbalancer. IPTables is routing request on 80 to
8080.
This seems unnecessary. If you have a
Daniel Mikusa wrote:
On Fri, Aug 1, 2014 at 11:13 AM, John Smith tomcat.ran...@gmail.com wrote:
TC 7.0.54 / RHEL 6
I have two physical servers, each running an instance of TC. The servers
are behind a hardware loadbalancer. IPTables is routing request on 80 to
8080.
This seems unnecessary.
TC 7.0.54 / RHEL 6
I have two physical servers, each running an instance of TC. The servers
are behind a hardware loadbalancer. IPTables is routing request on 80 to
8080.
This seems unnecessary. If you have a hardware load balancer in front of
Tomcat, it is the only thing that
On 01/08/2014 16:30, Daniel Mikusa wrote:
You probably want the SSL certificate installed on your hardware load
balancer. End client's browsers are going to connect to the hardware load
balancer, not Tomcat. Thus you'd want the certificate there so your end
users can benefit from it.
That
Not contradicting anything Daniel is saying, but maybe something to add,
and maybe that's the missing part of the original puzzle :
If Tomcat is expecting HTTPS requests on port 8443, then any re-direct or
response that it is sending back is going to include that port number after
the
On Fri, Aug 1, 2014 at 11:54 AM, Mark Thomas ma...@apache.org wrote:
On 01/08/2014 16:30, Daniel Mikusa wrote:
You probably want the SSL certificate installed on your hardware load
balancer. End client's browsers are going to connect to the hardware
load
balancer, not Tomcat. Thus you'd
John Smith wrote:
Not contradicting anything Daniel is saying, but maybe something to add,
and maybe that's the missing part of the original puzzle :
If Tomcat is expecting HTTPS requests on port 8443, then any re-direct or
response that it is sending back is going to include that port number
No, I am not really going that far. I am suggesting that that may be
the kind of thing that is happening, and that you may want to investigate
with a browser plugin, that the requests/responses are really what you are
expecting.
Your initial explanation was a bit confusing and lacking in
John Smith wrote:
No, I am not really going that far. I am suggesting that that may be
the kind of thing that is happening, and that you may want to investigate
with a browser plugin, that the requests/responses are really what you are
expecting.
Your initial explanation was a bit confusing
On 8/1/2014 12:35 PM, John Smith wrote:
No, I am not really going that far. I am suggesting that that may be
the kind of thing that is happening, and that you may want to investigate
with a browser plugin, that the requests/responses are really what you are
expecting.
Your initial
On Fri, Aug 1, 2014 at 11:49 AM, John Smith tomcat.ran...@gmail.com wrote:
TC 7.0.54 / RHEL 6
I have two physical servers, each running an instance of TC. The
servers
are behind a hardware loadbalancer. IPTables is routing request on 80
to
8080.
This seems unnecessary.
As your testing keep this process in mind. If you encounter a problem just
try to break down the flow from your browser to the server and back. If
you look at the request at each hop through this process, you can often
find where things went wrong. For example, did the request hit the LB?
Is your LB configured to listen on 8443, or on 443? It won't pick up the
port it's supposed to listen on from the TC instances; you have to specify
it.
Nailed it. Simplest solution, I didn't even consider it.
Thanks,
John
There is no response, since you are not even able to connect to that
IP:port.
If you are using the IP of the LB, then the LB is not accepting
connections on port 8443.
You won't get much further, unless you solve that first.
But I thought that you wanted your users to access via port 443
On 8/1/2014 1:33 PM, John Smith wrote:
Is your LB configured to listen on 8443, or on 443? It won't pick up the
port it's supposed to listen on from the TC instances; you have to specify
it.
Nailed it. Simplest solution, I didn't even consider it.
Thanks,
John
Thanks for letting us
On 01/08/2014 17:06, John Smith wrote:
On Fri, Aug 1, 2014 at 11:54 AM, Mark Thomas ma...@apache.org wrote:
On 01/08/2014 16:30, Daniel Mikusa wrote:
You probably want the SSL certificate installed on your hardware load
balancer. End client's browsers are going to connect to the hardware
Thanks for letting us know what the issue was; many people never come back
and tell us what fixed it.
My pleasure. This list is awesome.
TLS is layer 5 so if the LB is operating at layer 4 it can't host the
cert. Some LBs can operate at layer 5 so it will depend on your LB
and/or its configuration.
Mark
I see. That's good to know. The LB is at 7.
19 matches
Mail list logo
