tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Björn Raupach <raup...@me.com>
Subject Re: SSL and Virtual Hosting
Date Thu, 22 Oct 2015 07:49:30 GMT
Hi Chris,

thank you very much for the elaborate answer!

> On 21 Oct 2015, at 21:44, Christopher Schultz <chris@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 <markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message