Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 67451 invoked from network); 1 Jul 2010 07:50:54 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Jul 2010 07:50:54 -0000 Received: (qmail 92314 invoked by uid 500); 1 Jul 2010 07:50:51 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 91992 invoked by uid 500); 1 Jul 2010 07:50:47 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 91983 invoked by uid 99); 1 Jul 2010 07:50:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Jul 2010 07:50:46 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jranaudo@gmail.com designates 209.85.214.45 as permitted sender) Received: from [209.85.214.45] (HELO mail-bw0-f45.google.com) (209.85.214.45) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Jul 2010 07:50:40 +0000 Received: by bwz5 with SMTP id 5so1146995bwz.18 for ; Thu, 01 Jul 2010 00:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ZO185CuS3DKpGwGlqEPsXz13/eCTVIvrbOxSHSooIZQ=; b=hme/ciRJQ+xlQMwkFIjM5ih6nk84E2qiBzXfmXUx0kNuFJBTVS/Xqi5HUR8Bn7xL8Z ShBURVbohq+JXNJtlMzlJh1RY1ruivyukGTO7IYZr2K0m4aolUsPifW8sWEXIfRkpZt4 zd95XVe6gaze0axS/xBY+Dfn/evHXX8NxdKQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=MQ43wT7mo1MLCM8ULZ+AS4yJYqrXeTGTC4FQMsyuKC19C0EDGXQt6XjdqPvcO3A1dp pAIc2fIGNLBD3CwWEVZqaeHRGnps1HHNMoOVWQ/2P3Zv/fZ/NuiuwJ9xufYJJBbIgqH6 VRfAOsYaCKK/VM7pi+OE07e5RlfCht65uWkwQ= MIME-Version: 1.0 Received: by 10.204.34.130 with SMTP id l2mr7124935bkd.164.1277970559793; Thu, 01 Jul 2010 00:49:19 -0700 (PDT) Received: by 10.204.115.211 with HTTP; Thu, 1 Jul 2010 00:49:19 -0700 (PDT) In-Reply-To: <4C2C4533.2030008@pidster.com> References: <4C24E4EF.8020001@pidster.com> <4C24F3CD.8010902@christopherschultz.net> <4C2C4533.2030008@pidster.com> Date: Thu, 1 Jul 2010 03:49:19 -0400 Message-ID: Subject: Re: SSL and non SSL configuration on tomcat 6.0.26, confused From: John-Paul Ranaudo To: Tomcat Users List , pid@pidster.com Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org No we are not. On 7/1/10, Pid 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: >> >> >> > 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 < >> chris@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: >> >> > 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 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: >> >> >> > port="8080" >> protocol="HTTP/1.1" >> connectionTimeout="20000" >> redirectPort="443" >> /> >> >> >> > 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-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org >>> >>> > > > -- Sent from my mobile device --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org