On 01/07/2010 03:42, John-Paul Ranaudo wrote: > I have now realized the root of the problem. The cause of the problem is > that the load balancer will sometimes proxy an HTTPS request as an HTTP > request so when we send back a redirect we send it back with the wrong > scheme (HTTP). So here is my current configuration: > > <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" /> > <Connector port="443" protocol="HTTP/1.1" connectionTimeout="20000" > scheme="https" secure="true" /> > > Port 443 is not really handling the SSL because the load balancer is. I set > "secure" to true to mark the connections as secure to tomcat and not needing > SSL decryption as recommended. > > The one framework in which uses HTTPS will send most request as HTTPS > however the load balancer (for unknown reasons) proxies the request as HTTP > (port 80). So now when we send a redirect it's to HTTP (port 80) not HTTPS > (port 443). It should be port 443. > > Any idea how I can handle this in a connector configuration? > > My first thought is to create two virtual hosts which will then have 2 > different server.xml's. If I do this I can tell tomcat to proxy all HTTP > (port 80) requests to port 443 but only for that one virtual host (which > contains the problem framework). > > Any thoughts? > > Thanks and Regards, > > John-Paul Ranaudo > Application Architect > > On Fri, Jun 25, 2010 at 2:22 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > John-Paul, > > 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: > > <Connector > port="443" <- this is the port that the LB talks to > protocol="HTTP/1.1" > connectionTimeout="20000" > 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 --> > <Connector > port="8080" > protocol="HTTP/1.1" > connectionTimeout="20000" > redirectPort="443" > /> > > <!-- secure connector --> > <Connector > port="8443" > protocol="HTTP/1.1" > connectionTimeout="20000" > 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.
Are you using a transport-guarantee element in your web.xml? p > Hope that helps, > -chris >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
signature.asc
Description: OpenPGP digital signature
