You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Björn Raupach <ra...@me.com> on 2015/10/21 17:27:59 UTC
SSL and Virtual Hosting
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.
Thanks for taking the time!
with kind regards,
Björn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL and Virtual Hosting
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL and Virtual Hosting
Posted by Björn Raupach <ra...@me.com>.
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-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
Re: SSL and Virtual Hosting
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL and Virtual Hosting
Posted by Björn Raupach <ra...@me.com>.
Hello Mark,
thanks for responding
> 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? 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/>?
>
> 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.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org <ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org <ma...@tomcat.apache.org>
Re: SSL and Virtual Hosting
Posted by George Sexton <ge...@mhsoftware.com>.
On 10/21/2015 12:42 PM, Mark Thomas wrote:
> 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.
>
> 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.
I'm excited to see this feature. I'm using a wild-card cert within my
domain, but I want to offer my customers with virtual hosts the option
of supplying their own cert in their domain.
>
> Mark
>
--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com
Re: SSL and Virtual Hosting
Posted by Mark Thomas <ma...@apache.org>.
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.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSL and Virtual Hosting
Posted by Björn Raupach <ra...@me.com>.
Dear Jason,
> On 21 Oct 2015, at 19:18, Jason Britton <jb...@gmail.com> wrote:
>
> Hi Björn -
> Look in tomcat/conf at the server.xml, you'd just define multiple host
> entries, one host entry would have a name of "alice.example.com" the other
> with "bob.example.com". Each host entry would also have its own appBase
> (alice-webapps & bob-webapps), meaning both sites could be deployed using
> ROOT.war. Update the DNS for alice and bob to point at the server your
> consolidated tomcat is on. Inside tomcat/conf/Catalina/ I'm pretty sure
> you're going to need a directory for each host with that hosts config
> ROOT.xml etc).
thanks. Yes, I know how to do this part.
> We use Apache HTTPD to proxy to our Tomcats and we
> terminate SSL at HTTPD so I'm not exactly sure on your SSL questions. Our
> SSL is configured through Apache HTTPD Virtual Hosts. Maybe you want to
> look into the cost for a wildcard SSL cert that would cover *.example.com
> rather than specific hosts?
Unfortunately that is the scenario I am trying to prevent.
I don’t want to add another layer of complexity.
Apache Tomcat works like a charm and if it supports Virtual Hosting I don’t need
another service running.
>
> Jason
>
> On Wed, Oct 21, 2015 at 8:27 AM, Björn Raupach <ra...@me.com> 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.
>>
>> Thanks for taking the time!
>>
>>
>> with kind regards,
>> Björn
>>
>> ---------------------------------------------------------------------
>> 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
Re: SSL and Virtual Hosting
Posted by Jason Britton <jb...@gmail.com>.
Hi Björn -
Look in tomcat/conf at the server.xml, you'd just define multiple host
entries, one host entry would have a name of "alice.example.com" the other
with "bob.example.com". Each host entry would also have its own appBase
(alice-webapps & bob-webapps), meaning both sites could be deployed using
ROOT.war. Update the DNS for alice and bob to point at the server your
consolidated tomcat is on. Inside tomcat/conf/Catalina/ I'm pretty sure
you're going to need a directory for each host with that hosts config
ROOT.xml etc). We use Apache HTTPD to proxy to our Tomcats and we
terminate SSL at HTTPD so I'm not exactly sure on your SSL questions. Our
SSL is configured through Apache HTTPD Virtual Hosts. Maybe you want to
look into the cost for a wildcard SSL cert that would cover *.example.com
rather than specific hosts?
Jason
On Wed, Oct 21, 2015 at 8:27 AM, Björn Raupach <ra...@me.com> 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.
>
> Thanks for taking the time!
>
>
> with kind regards,
> Björn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>