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. Hope that helps, -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
