That wont work either because like I said before, the application is not really using SSL. The SSL is handled by the load balancers. If we use anything that forces SSL it will fail for the other framework which does not use SSL.
On Thu, Jul 1, 2010 at 3:59 AM, Pid <p...@pidster.com> wrote: > On 01/07/2010 08:49, John-Paul Ranaudo wrote: > > No we are not. > > If the SSL-only resources match a specific path, you can add a > security-constraint which doesn't have user roles, but does have a > transport-guarantee set to 'CONFIDENTIAL'. > > The container will automatically upgrade a matching request to HTTPS by > redirecting it to the port configured in 'redirectPort' on the HTTP > connector. > > > p > > > On 7/1/10, Pid <p...@pidster.com> wrote: > >> 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 > >>>> > >>>> > >> > >> > >> > > > > >
