Hi Chris, thank you very much for the elaborate answer!
> 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. And if Tomcat 9 and eventually Tomcat 8 with SNI arrives, I can ditch ELB. > > Hope that helps, > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
