Re: SSL and non SSL configuration on tomcat 6.0.26, confused
On 01/07/2010 20:11, John-Paul Ranaudo wrote: I wish I could provide more information. At least I have narrowed down the problem. I am having a meeting with the architects of both frameworks today so perhaps I'll get some details. Given some examples of URLs that fail, and bits of code/HTML/JSP that are relevant would be a start. p Thanks. On Thu, Jul 1, 2010 at 2:54 PM, Pid p...@pidster.com mailto:p...@pidster.com wrote: On 01/07/2010 19:38, John-Paul Ranaudo wrote: I did more tracing and remote debugging and I was mistaken (too many late nights). Each framework is sending us the request via port 80. The problem comes from the fact the one of the frameworks uses HTTPS before the load balancers so when we send back a redirect it is using the wrong scheme. HTTP instead of HTTPS. I need a way of knowing which framework made the request so I can alter the scheme on redirect for just the one framework. btw, the frameworks are proprietary and much like existing portal frameworks. So I am wondering if I can do this with virtual hosts or somehow detect the incoming URL to tell which domain its coming from and handle appropriately. I wondering too, but mostly because you're not really giving us any real information about what's happening. The word 'framework' might mean something specific to you, but it doesn't help me understand what's happening on your server(s). We can't help you without accurate and detailed information. I /guess/ that virtual hosts won't help you. I /guess/ that the domain it's coming from won't matter so much as the domain requested. p On Thu, Jul 1, 2010 at 11:31 AM, Pid p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com wrote: On 01/07/2010 16:01, John-Paul Ranaudo wrote: I am confused no doubt. What you say here is correct: /In your description of the issue so far, you've said that the application *is* using SSL. The load-balancers might be terminating it forwarding unencrypted connections/ / / /I think I understand what you mean by redirecting. Our current configuration. Framework A does not use SSL thus uses connector port 80. Framework B, the problem, uses SSL/port 443. / It might help illuminate matters if you explain exactly what Frameworks A B actually are. Are they separate web applications? How do they relate to each other, are they on separate URLs? Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 / (Used by framework A) Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 scheme=https secure=true / (Used by framework B) Now I could change the port 80 connector to have a redirectPort attribute like so: / Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=443/ The problem with this approach is that framework A which does not use SSL now will use it via he redirect port. We'll then get the same mixed content warnings in the browser. It won't use it unless it's told to. So what's telling it to? As far as I can see, there's nothing stopping the whole site running under 443, which would prevent you seeing mixed content errors. Have you identified exactly which resources are being served via HTTP within an HTTPS page? What are they? p I hope this explains the problem more clearly. / / Redirecting as I explained below just means that you can upgrade to HTTPS for specific paths. The load-balancer still handles it. If we use anything that forces SSL it will fail for the other framework which does not use SSL. Why? How are you switching back to HTTP for 'the other framework', once the user has been on a page served under HTTPS? p On Thu, Jul 1, 2010 at 3:59 AM, Pid p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
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=2 / Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 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=2 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=2 redirectPort=443 / !-- secure connector -- Connector port=8443 protocol=HTTP/1.1 connectionTimeout=2 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
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
No we are not. 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=2 / Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 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=2 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=2 redirectPort=443 / !-- secure connector -- Connector port=8443 protocol=HTTP/1.1 connectionTimeout=2 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
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
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=2 / Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 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=2 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=2 redirectPort=443 / !-- secure connector -- Connector port=8443 protocol=HTTP/1.1 connectionTimeout=2 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
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
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=2 / Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 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=2 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
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
On 01/07/2010 14:49, John-Paul Ranaudo wrote: That wont work either because like I said before, the application is not really using SSL. The SSL is handled by the load balancers. Either I'm confused, or you are. In your description of the issue so far, you've said that the application *is* using SSL. The load-balancers might be terminating it forwarding unencrypted connections, but the application must be using it - or you wouldn't need the second connector with 'scheme=https'. Redirecting as I explained below just means that you can upgrade to HTTPS for specific paths. The load-balancer still handles it. If we use anything that forces SSL it will fail for the other framework which does not use SSL. Why? How are you switching back to HTTP for 'the other framework', once the user has been on a page served under HTTPS? p On Thu, Jul 1, 2010 at 3:59 AM, Pid p...@pidster.com mailto: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 mailto: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=2 / Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 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 mailto: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=2 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
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
I am confused no doubt. What you say here is correct: *In your description of the issue so far, you've said that the application *is* using SSL. The load-balancers might be terminating it forwarding unencrypted connections* * * *I think I understand what you mean by redirecting. Our current configuration. Framework A does not use SSL thus uses connector port 80. Framework B, the problem, uses SSL/port 443. * * * * Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 / (Used by framework A) Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 scheme=https secure=true / (Used by framework B) Now I could change the port 80 connector to have a redirectPort attribute like so: Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=443/ The problem with this approach is that framework A which does not use SSL now will use it via he redirect port. We'll then get the same mixed content warnings in the browser. I hope this explains the problem more clearly. * Redirecting as I explained below just means that you can upgrade to HTTPS for specific paths. The load-balancer still handles it. If we use anything that forces SSL it will fail for the other framework which does not use SSL. Why? How are you switching back to HTTP for 'the other framework', once the user has been on a page served under HTTPS? p On Thu, Jul 1, 2010 at 3:59 AM, Pid p...@pidster.com mailto: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 mailto: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=2 / Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 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 mailto: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
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
On 01/07/2010 16:01, John-Paul Ranaudo wrote: I am confused no doubt. What you say here is correct: /In your description of the issue so far, you've said that the application *is* using SSL. The load-balancers might be terminating it forwarding unencrypted connections/ / / /I think I understand what you mean by redirecting. Our current configuration. Framework A does not use SSL thus uses connector port 80. Framework B, the problem, uses SSL/port 443. / It might help illuminate matters if you explain exactly what Frameworks A B actually are. Are they separate web applications? How do they relate to each other, are they on separate URLs? Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 / (Used by framework A) Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 scheme=https secure=true / (Used by framework B) Now I could change the port 80 connector to have a redirectPort attribute like so: / Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=443/ The problem with this approach is that framework A which does not use SSL now will use it via he redirect port. We'll then get the same mixed content warnings in the browser. It won't use it unless it's told to. So what's telling it to? As far as I can see, there's nothing stopping the whole site running under 443, which would prevent you seeing mixed content errors. Have you identified exactly which resources are being served via HTTP within an HTTPS page? What are they? p I hope this explains the problem more clearly. / / Redirecting as I explained below just means that you can upgrade to HTTPS for specific paths. The load-balancer still handles it. If we use anything that forces SSL it will fail for the other framework which does not use SSL. Why? How are you switching back to HTTP for 'the other framework', once the user has been on a page served under HTTPS? p On Thu, Jul 1, 2010 at 3:59 AM, Pid p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto: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 mailto:p...@pidster.com mailto:p...@pidster.com mailto: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=2 / Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 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 mailto:ch...@christopherschultz.net mailto:ch...@christopherschultz.net mailto:ch...@christopherschultz.net wrote: John-Paul, On 6/25/2010 1:40 PM, John-Paul Ranaudo wrote: Ok, so I am
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
I did more tracing and remote debugging and I was mistaken (too many late nights). Each framework is sending us the request via port 80. The problem comes from the fact the one of the frameworks uses HTTPS before the load balancers so when we send back a redirect it is using the wrong scheme. HTTP instead of HTTPS. I need a way of knowing which framework made the request so I can alter the scheme on redirect for just the one framework. btw, the frameworks are proprietary and much like existing portal frameworks. So I am wondering if I can do this with virtual hosts or somehow detect the incoming URL to tell which domain its coming from and handle appropriately. Thanks. On Thu, Jul 1, 2010 at 11:31 AM, Pid p...@pidster.com wrote: On 01/07/2010 16:01, John-Paul Ranaudo wrote: I am confused no doubt. What you say here is correct: /In your description of the issue so far, you've said that the application *is* using SSL. The load-balancers might be terminating it forwarding unencrypted connections/ / / /I think I understand what you mean by redirecting. Our current configuration. Framework A does not use SSL thus uses connector port 80. Framework B, the problem, uses SSL/port 443. / It might help illuminate matters if you explain exactly what Frameworks A B actually are. Are they separate web applications? How do they relate to each other, are they on separate URLs? Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 / (Used by framework A) Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 scheme=https secure=true / (Used by framework B) Now I could change the port 80 connector to have a redirectPort attribute like so: / Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=443/ The problem with this approach is that framework A which does not use SSL now will use it via he redirect port. We'll then get the same mixed content warnings in the browser. It won't use it unless it's told to. So what's telling it to? As far as I can see, there's nothing stopping the whole site running under 443, which would prevent you seeing mixed content errors. Have you identified exactly which resources are being served via HTTP within an HTTPS page? What are they? p I hope this explains the problem more clearly. / / Redirecting as I explained below just means that you can upgrade to HTTPS for specific paths. The load-balancer still handles it. If we use anything that forces SSL it will fail for the other framework which does not use SSL. Why? How are you switching back to HTTP for 'the other framework', once the user has been on a page served under HTTPS? p On Thu, Jul 1, 2010 at 3:59 AM, Pid p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto: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 mailto:p...@pidster.com mailto:p...@pidster.com mailto: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=2 / Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 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
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
On 01/07/2010 19:38, John-Paul Ranaudo wrote: I did more tracing and remote debugging and I was mistaken (too many late nights). Each framework is sending us the request via port 80. The problem comes from the fact the one of the frameworks uses HTTPS before the load balancers so when we send back a redirect it is using the wrong scheme. HTTP instead of HTTPS. I need a way of knowing which framework made the request so I can alter the scheme on redirect for just the one framework. btw, the frameworks are proprietary and much like existing portal frameworks. So I am wondering if I can do this with virtual hosts or somehow detect the incoming URL to tell which domain its coming from and handle appropriately. I wondering too, but mostly because you're not really giving us any real information about what's happening. The word 'framework' might mean something specific to you, but it doesn't help me understand what's happening on your server(s). We can't help you without accurate and detailed information. I /guess/ that virtual hosts won't help you. I /guess/ that the domain it's coming from won't matter so much as the domain requested. p On Thu, Jul 1, 2010 at 11:31 AM, Pid p...@pidster.com mailto:p...@pidster.com wrote: On 01/07/2010 16:01, John-Paul Ranaudo wrote: I am confused no doubt. What you say here is correct: /In your description of the issue so far, you've said that the application *is* using SSL. The load-balancers might be terminating it forwarding unencrypted connections/ / / /I think I understand what you mean by redirecting. Our current configuration. Framework A does not use SSL thus uses connector port 80. Framework B, the problem, uses SSL/port 443. / It might help illuminate matters if you explain exactly what Frameworks A B actually are. Are they separate web applications? How do they relate to each other, are they on separate URLs? Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 / (Used by framework A) Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 scheme=https secure=true / (Used by framework B) Now I could change the port 80 connector to have a redirectPort attribute like so: / Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=443/ The problem with this approach is that framework A which does not use SSL now will use it via he redirect port. We'll then get the same mixed content warnings in the browser. It won't use it unless it's told to. So what's telling it to? As far as I can see, there's nothing stopping the whole site running under 443, which would prevent you seeing mixed content errors. Have you identified exactly which resources are being served via HTTP within an HTTPS page? What are they? p I hope this explains the problem more clearly. / / Redirecting as I explained below just means that you can upgrade to HTTPS for specific paths. The load-balancer still handles it. If we use anything that forces SSL it will fail for the other framework which does not use SSL. Why? How are you switching back to HTTP for 'the other framework', once the user has been on a page served under HTTPS? p On Thu, Jul 1, 2010 at 3:59 AM, Pid p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto: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 mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto: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
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
I wish I could provide more information. At least I have narrowed down the problem. I am having a meeting with the architects of both frameworks today so perhaps I'll get some details. Thanks. On Thu, Jul 1, 2010 at 2:54 PM, Pid p...@pidster.com wrote: On 01/07/2010 19:38, John-Paul Ranaudo wrote: I did more tracing and remote debugging and I was mistaken (too many late nights). Each framework is sending us the request via port 80. The problem comes from the fact the one of the frameworks uses HTTPS before the load balancers so when we send back a redirect it is using the wrong scheme. HTTP instead of HTTPS. I need a way of knowing which framework made the request so I can alter the scheme on redirect for just the one framework. btw, the frameworks are proprietary and much like existing portal frameworks. So I am wondering if I can do this with virtual hosts or somehow detect the incoming URL to tell which domain its coming from and handle appropriately. I wondering too, but mostly because you're not really giving us any real information about what's happening. The word 'framework' might mean something specific to you, but it doesn't help me understand what's happening on your server(s). We can't help you without accurate and detailed information. I /guess/ that virtual hosts won't help you. I /guess/ that the domain it's coming from won't matter so much as the domain requested. p On Thu, Jul 1, 2010 at 11:31 AM, Pid p...@pidster.com mailto:p...@pidster.com wrote: On 01/07/2010 16:01, John-Paul Ranaudo wrote: I am confused no doubt. What you say here is correct: /In your description of the issue so far, you've said that the application *is* using SSL. The load-balancers might be terminating it forwarding unencrypted connections/ / / /I think I understand what you mean by redirecting. Our current configuration. Framework A does not use SSL thus uses connector port 80. Framework B, the problem, uses SSL/port 443. / It might help illuminate matters if you explain exactly what Frameworks A B actually are. Are they separate web applications? How do they relate to each other, are they on separate URLs? Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 / (Used by framework A) Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 scheme=https secure=true / (Used by framework B) Now I could change the port 80 connector to have a redirectPort attribute like so: / Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=443/ The problem with this approach is that framework A which does not use SSL now will use it via he redirect port. We'll then get the same mixed content warnings in the browser. It won't use it unless it's told to. So what's telling it to? As far as I can see, there's nothing stopping the whole site running under 443, which would prevent you seeing mixed content errors. Have you identified exactly which resources are being served via HTTP within an HTTPS page? What are they? p I hope this explains the problem more clearly. / / Redirecting as I explained below just means that you can upgrade to HTTPS for specific paths. The load-balancer still handles it. If we use anything that forces SSL it will fail for the other framework which does not use SSL. Why? How are you switching back to HTTP for 'the other framework', once the user has been on a page served under HTTPS? p On Thu, Jul 1, 2010 at 3:59 AM, Pid p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com mailto: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 mailto:p...@pidster.com mailto:p...@pidster.com mailto:p...@pidster.com
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
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=2 / Connector port=443 protocol=HTTP/1.1 connectionTimeout=2 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: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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=2 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=2 redirectPort=443 / !-- secure connector -- Connector port=8443 protocol=HTTP/1.1 connectionTimeout=2 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
Chris Sorry for the late reply. While I have not been able to try this yet your explanations are very clear and I understand better what the options on the connector mean now. I will give this a try. Thank you for your reply. Regards, John Ranaudo On Fri, Jun 25, 2010 at 2:22 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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=2 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=2 redirectPort=443 / !-- secure connector -- Connector port=8443 protocol=HTTP/1.1 connectionTimeout=2 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwk880ACgkQ9CaO5/Lv0PDRsQCgmB+nCnB/LG8sgt0ByBnOlhsR 0DMAoL4rR/B4KUWsF9CLZOekfaGMKrUP =wXOl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL and non SSL configuration on tomcat 6.0.26, confused
Our environment: Unix Solaris 5.9 Tomcat 6.0.26 JVM 1.6.20 Our application runs in two frameworks. One uses https one does not. I am trying to configure the tomcat connectors to work but when I get it working in one framework it does not work in the other. *I have been told we do not need to 'handle' SSL totally as this is handled by our load balancers. Not sure what these means*. For example: In one framework we'll get permission denied errors and the other will work. If we change things around the opposite occurs but instead of permission errors we get invalid certificate error. The tomcat documentation on connectors does not describe the options very well. Connector port=80 protocol=HTTP/1.1 connectionTimeout=2/ Connector port=443 protocol=HTTP/1.1 SSLEnabled=false maxThreads=150 scheme=https secure=false clientAuth=false sslProtocol=TLS/ The above connectors work with the http framework but gives me the mixed content warning in IE because some requests are http and some https. It's obvious I have not worked with SSL very much. Any help would be greatly appreciated. Regards, John Ranaudo
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
On 25/06/2010 17:56, John-Paul Ranaudo wrote: Our environment: Unix Solaris 5.9 Tomcat 6.0.26 JVM 1.6.20 Our application runs in two frameworks. One uses https one does not. I am trying to configure the tomcat connectors to work but when I get it working in one framework it does not work in the other. *I have been told we do not need to 'handle' SSL totally as this is handled by our load balancers. Not sure what these means*. That usually means that the load-balancer is decoding the SSL connection and passing an unencrypted connection through to the servers in the cluster, which then don't need to repeat the effort. For example: In one framework we'll get permission denied errors and the other will work. If we change things around the opposite occurs but instead of permission errors we get invalid certificate error. The tomcat documentation on connectors does not describe the options very well. This link, or another one? http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#SSL Support Connector port=80 protocol=HTTP/1.1 connectionTimeout=2/ Connector port=443 protocol=HTTP/1.1 SSLEnabled=false maxThreads=150 scheme=https secure=false clientAuth=false sslProtocol=TLS/ Looks like a few odd things going on there. SSLEnabled=false secure=false You'll need to set at least one of those to true. If the connector on 443 is supposed to be decoding SSL connections there's a lot more config you'll need too. See the link above. The above connectors work with the http framework but gives me the mixed content warning in IE because some requests are http and some https. That's nothing to do with the Connectors per se. If your web app is mixing references to secure and insecure pages, you'll get that warning. You need to fix your app so it does the right thing. p It's obvious I have not worked with SSL very much. Any help would be greatly appreciated. Regards, John Ranaudo signature.asc Description: OpenPGP digital signature
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
Thanks for the reply. 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? However if I do, does this not make Tomcat try and decode the connection? *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. * 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. The application always uses relative paths so whatever protocol the framework is using will be what is returned in the page. 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. Regards, John On Fri, Jun 25, 2010 at 1:18 PM, Pid p...@pidster.com wrote: On 25/06/2010 17:56, John-Paul Ranaudo wrote: Our environment: Unix Solaris 5.9 Tomcat 6.0.26 JVM 1.6.20 Our application runs in two frameworks. One uses https one does not. I am trying to configure the tomcat connectors to work but when I get it working in one framework it does not work in the other. *I have been told we do not need to 'handle' SSL totally as this is handled by our load balancers. Not sure what these means*. That usually means that the load-balancer is decoding the SSL connection and passing an unencrypted connection through to the servers in the cluster, which then don't need to repeat the effort. For example: In one framework we'll get permission denied errors and the other will work. If we change things around the opposite occurs but instead of permission errors we get invalid certificate error. The tomcat documentation on connectors does not describe the options very well. This link, or another one? http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#SSL Support Connector port=80 protocol=HTTP/1.1 connectionTimeout=2/ Connector port=443 protocol=HTTP/1.1 SSLEnabled=false maxThreads=150 scheme=https secure=false clientAuth=false sslProtocol=TLS/ Looks like a few odd things going on there. SSLEnabled=false secure=false You'll need to set at least one of those to true. If the connector on 443 is supposed to be decoding SSL connections there's a lot more config you'll need too. See the link above. The above connectors work with the http framework but gives me the mixed content warning in IE because some requests are http and some https. That's nothing to do with the Connectors per se. If your web app is mixing references to secure and insecure pages, you'll get that warning. You need to fix your app so it does the right thing. p It's obvious I have not worked with SSL very much. Any help would be greatly appreciated. Regards, John Ranaudo
Re: SSL and non SSL configuration on tomcat 6.0.26, confused
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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=2 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=2 redirectPort=443 / !-- secure connector -- Connector port=8443 protocol=HTTP/1.1 connectionTimeout=2 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwk880ACgkQ9CaO5/Lv0PDRsQCgmB+nCnB/LG8sgt0ByBnOlhsR 0DMAoL4rR/B4KUWsF9CLZOekfaGMKrUP =wXOl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
