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. If you have a hardware load balancer in front of
Tomcat, it is the only thing that would ever talk to Tomcat. Thus if you
just configure it to go to port 8080 you don't need the iptables rule. I
can't imagine it's hurting anything, but just thought I'd mention it.
Tomcat runs under a non-root user. All good.
I needed to protect an area of our webapp under SSL. Went ahead and
installed the cert on each server. I can go directly to each server by IP
under SSL and get the cert (with the expected IP doesn't match FQDN
warning).
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.
Ex: browser -> HTTPS -> load balancer -> HTTP or HTTPS -> Tomcat
If you put an SSL certificate on your Tomcat servers, that would allow you
to secure the connection between your load balancer and Tomcat. Depending
on your network and security requirements this may or may not be necessary.
I'd say most people don't do this because terminating SSL on the load
balancer is sufficient. It just depends on your requirements though.
But when I go through the loadbalancer I can't access anything under port
8443. I redirected 443 to 8443 on each TC server using IPTables, but still
no luck.
Is there anything I'm missing?
The load balancer is almost certainly listening on port 80 and 443. To
test, you'd want to connect to the load balancer on one of those ports.
The load balancer would then connect to one of your backend nodes and
proxy the request on your behalf. Your browser will not connect directly
to the backend nodes (see my point above about not needing the iptables
rule), unless you specifically point it to the ip address of one of the
backend nodes.
I understand I can install the cert on the
loadbalancer instead, or use httpd as a proxy, but I'd rather just leave it
the way it is if there's any other option.
I think you'd want it on the load balancer. Possibly with additional certs
on your backend nodes, if you want HTTPS communication between the load
balancer and the Tomcat nodes.
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 hostname.
(even inside the pages, if you use absolute URL links there).
So the browser who ultimately receives this, is going to try to talk to port
8443.
But that will not work, if your front-end is expecting further requests on port 443, and
blocks 8443.
Unless in all your Tomcat responses, you arrange to replace any reference to port 8443, by
443, before they reach the browser again.
Maybe using a browser plugin like HttpFox, LiveHttpHeaders or Fiddler2 would allow you to
see more clearly what is going on there.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
