Björn, On 10/22/15 3:49 AM, Björn Raupach wrote: >> On 21 Oct 2015, at 21:44, Christopher Schultz <ch...@christopherschultz.net> >> wrote: >> >> Björn, >> >> On 10/21/15 2:47 PM, Björn Raupach wrote: >>>> On 21 Oct 2015, at 20:42, Mark Thomas <ma...@apache.org> wrote: >>>> >>>> On 21/10/2015 16:27, Björn Raupach wrote: >>>>> Dear group, >>>>> >>>>> it would be nice if anyone knows, if my planned setup is going to work. >>>>> >>>>> At the moment we are having two services (web apps) at two different >>>>> machines and hostnames. Lets say bob.example.com and alice.example.com >>>>> >>>>> bob.example.com runs without SSL and deploys the web app at the root >>>>> context. We just throw a ROOT.war in /webapps. >>>>> >>>>> alice.example.com needs SSL at all times. It currently does not run with >>>>> the root context but we would like to. So another ROOT.war. We have an >>>>> SSL cert for alice.example.com >>>>> >>>>> I want both applications to run on a single Tomcat instance with Virtual >>>>> Hosting. Virtual Hosting with Tomcat that is. I am comfortable with >>>>> setting up Virtual Hosting, but I am just not sure about the SSL part. >>>>> Does the choice between IP-based or Hostname matter? bob.example.com >>>>> might need SSL support in the future. >>>>> >>>>> We are using Amazon AWS if that is important. So I could get another >>>>> Elastic IP. We are working with the latest Apache Tomcat 8 and the latest >>>>> JDK on the server machines. >>>>> >>>>> Sorry if this is not 100% Tomcat related. >>>> >>>> Currently it will work if both hosts can share the same certificate >>>> because they share a connector and (currently) a connector can only have >>>> a single certificate. >>> >>> How can both hosts share the same certificate? >> >> I think he meant that if both sites "can" share a certificate, the whole >> thing becomes easier. For example, a certificate with a >> subject-alternative-name, or a wildcard certificate. >> >> Recent versions of Java support SNI which should allow multiple >> certificates to be used, but I'm not sure if Tomcat supports that >> directly right now (see Mark's comments about multi-certificate support >> in the very near future). >> >>> Do I need a SAN certificate or can I just run with the cert for >>> alice.example.com <http://alice.example.com/> and have to live with any >>> cert errors on bob.example.com <http://bob.example.com/>? >> >> Well, those are both options, but the first one costs a heap of money >> and the second is unpalatable for users (errors = bad). >> >>>> As of 9.0.x (and hopefully eventually back-ported to 8.x) you'll be able >>>> to have per host certs. There should be a 9.0.0-RC1 in the next week or so. >> >> This is the "holy grail" of TLS certificate support -- one that I hope >> will be able to be back-ported without too much pain for (probably) Mark. >> >> IIRC, this will also allow *either* PEM-file-based setup *or* >> keystore-based setup regardless of the crypto implementation (OpenSSL >> vs. JSSE) being used. I personally detest keystores because they are so >> fault-intolerant, but they do have the advantage of being able to say >> "use any matching certificate in this blob" to get work done. >> >> So... if you are willing to wait a bit (9.0-RC1 in the next week? woah!) >> for a back-port from trunk into the 8.0.x branch, then that's probably >> your best bet. If you absolutely need to get this out right away, I see >> only a few options: >> >> 1. Wildcard cert >> 2. Cert with a SAN >> 3. Front each service with AWS ELB >> 4. Front both services with httpd, which supports SNI >> 5. Use two <Connector>s, each on a different port >> 6. Use two <Connector>s, each on a different interface >> >> That last one (6) might not be possible on AWS, since the host is itself >> mostly unaware of the public IP address external clients use to access >> it. (I have an EC2 instance with both internal and external IPs, and I >> only have "lo" and "eth0" interfaces, so I couldn't bind a <Connector> >> to the public IP's interface). >> >> Option #3 might be the best for you in the short-term (and possibly the >> long-term), because it allows you to easily configure TLS *and* >> port-redirection without the complexity of a whole server+httpd instance >> to maintain. It will also allow you to grow your service trivially in >> the future should you choose to do so. The downside is that you pay for >> the ELB by the bit-transferred. It's up to you to decide how much you're >> willing to pay for that kind of thing. > > I go with your option #3. AWS ELB is new to me but I have a look. In the > end it is probably cheaper than paying another EC2 instance.
I forgot that there is a fixed cost to running the load balancer of (as of this writing) US0.025/hr, which is US219.15/yr. You can pay less for an EC2 instance, but ELB is /very/ reliable, scales essentially infinitely without your interference, and does not require management of any kind (e.g. keeping OS packages up-to-date, etc.). You can connect it up to any number of back-end EC2 instances with no per-connection charge. The pay-per-bit is also very cheap: US0.008 per GiB per month. If you push 10GiB per month, you'll pay only US0.96 per year. You can't beat that with a stick. That said, you'll need one ELB for each of your two services, unless you plan on using different ports or whatever. If you were going to do that, you could just use different ports on a single EC2 instance. > And if Tomcat 9 and eventually Tomcat 8 with SNI arrives, I can ditch > ELB. You might not want to. :) -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
