tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: SSL and non SSL configuration on tomcat 6.0.26, confused
Date Fri, 25 Jun 2010 18:22:05 GMT
Hash: SHA1


On 6/25/2010 1:40 PM, John-Paul Ranaudo wrote:
> Ok, so I am assuming I do not have to setup SSL (certificates etc) since my
> load balancer is decoding the connection. So even if the load balancer is
> "decoding" the connection I still have to have SSLEnabled="true"?

No, Pid was saying that setting one of the two options (SSLEnabled and
secure) to "true" makes sense... setting both to "false" is not
particularly useful.

> However if
> I do, does this not make Tomcat try and decode the "connection"?

Yes, setting SSLEnabled="true" will make the connector try to perform
the decryption.

> *Which is the root of my problem. How to use the HTTPS protocol without
> having Tomcat decrypt the connection since the load balancer has done this
> for me. *

It sounds like you just want Tomcat to know that the connection is
secure, but without actually doing the decryption. You should be able to
do it like this:

  port="443" <- this is the port that the LB talks to
  scheme="https" <- so request.getScheme returns correct value
  secure="true" <- so request.isSecure returns correct value

There's no need to set SSLProtocol or SSLEnabled (you're not using SSL,
remember), they will default to "false".

> The link to the documentation is correct. However the properties of the
> connector are confusing to me. For example "SSLEnabled" if fairly obvious
> but "secure" it confusing. Not sure under what context I need to set this.

You can set these to different values, for instance, to instruct the
server to report connections as secure even when they aren't actually
tunneled through SSL (as above).

> The application always uses relative paths so whatever protocol the
> framework is using will be what is returned in the page.

Good. How about redirects?

> I have also tried setting the redirect port thinking I can redirect requests
> to 443 to the port 80 internally and scheme to 'https'. This actually had
> the effect of making one framework (the one with https) work but broke the
> other.

The redirect port is only used when the server decides that a webapp
requires a secure connection (see <transport-guarantee> in web.xml), and
the server issues a redirect to the client to upgrade the connection to
HTTPS. The default is 443, so if a client arrives on port 80, they will
be redirected to the same URL except with https:// on the front and the
port added if it's not the default of 443.

Now, you have to remember that the port number that does out attached to
a redirect URL (say, https://myhost:443/foo/bar) is probably the port on
the load-balancer the client will hit, not necessarily the port on the
local machine. The following configuration is perfectly legitimate:

<!-- non-secure connector -->

<!-- secure connector -->
  scheme="https" <- so request.getScheme returns correct value
  secure="true" <- so request.isSecure returns correct value

As you see, redirectPort is set to a port that isn't being handled by
Tomcat. That's okay, because the load-balancer is presumably handling
requests to myhost:443, terminating the SSL, and proxying the cleartext
HTTP request to the "8443" connector, which then reports secure="true"
to anyone who asks.

Hope that helps,
- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message