tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Björn Raupach <>
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 <> wrote:
> Björn,
> On 10/21/15 2:47 PM, Björn Raupach wrote:
>>> On 21 Oct 2015, at 20:42, Mark Thomas <> 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 and 
>>>> runs without SSL and deploys the web app at the root context.
We just throw a ROOT.war in /webapps.
>>>> 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
>>>> 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? 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
>> <> and have to live with any
>> cert errors on <>?
> 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 

> Hope that helps,
> -chris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message