Re: Tomcat 8.5.15 Client Authentication Trust Store Changes

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Racine,

On 6/21/17 3:53 PM, Racine Faye wrote:
> Thanks for the reply Christopher. The way tomcat has always worked 
> in the past(Before 8.5.15) , is that your trust store is what
> tomcat uses to decide what certificates the browser should show to
> the user because it only shows them certificates that are in the
> certificate chain of whatever you import into your trust store. So
> if you import a root certificate it will show everything that has
> that root certificate in its chain but if you import in an
> intermediate it will only show the certificates that the
> intermediate accepts.
I understand all that. But what is important is that the client
(browser) determines which certificates are acceptable based upon what
the server provides.

> So the way it works for DoD is that on each CAC there are 2 client 
> authentication certificates one Email Cert and one ID cert. They 
> contain different information mainly the email address is only 
> contained in the Email cert. When users are prompted to select a 
> certificate they are only supposed to be given the selection of
> what certificates are in the trust store because it knows that
> anything not in that trust store won't be accepted anyways.
Right.

> When you set the clientAuth to true in the connector that is what 
> makes it so Tomcat then asks for a certificate from the user for 
> validation.
Correct.

> I have used both IE and Chrome and I get the same results in both.
> I am pretty sure it is not a browser issue though because I have
> both Tomcat 8.5.15 and 8.5.14 running on the same server using the
> same trust store and 8.5.14 asks for only Certificates that are in
> the Chain of the Intermediates that I imported in and 8.5.15 asks
> for all of the certificates.
Okay, that's good that you have eliminated some variables. I'm still
interested in what the differences are... there shouldn't be much
change between the two versions.

> Unfortunately I am not able to run openssl as I am on a goverment 
> network and the software we can use is restricted.
Can you connect from another host where your software is less
restricted? What software CAN you run?

You can write a Java-based program that will connect to the server,
and run it in debug mode so the JVM is dumping tons of stuff to the
console. Are you allowed to compile and run some Java code?

> https://stackoverflow.com/questions/1666052/java-https-client-certific
ate-authentication
>
> 
The previous link  has a pretty good explanation of the way Tomcat
> has always worked in the past in the comments and explains about
> the behavior I am expecting.
I thoroughly understand what you are expecting. What you are
experiencing is .. unexpected.

Can you share your  configuration from both versions of
Tomcat? Remember to remove any secrets that may be in that configuration
.

Which connector are you actually using? You say "trust store" so I
would normally expect that you are using a Java-based connector with
JSSE. But since Tomcat 8.5.x you can use OpenSSL with Java-base
connectors, and the crypto is handled by a different subsystem
(OpenSSL instead of JSSE). Also, are you running on Windows or some
Unix-like system? In either case, do you have libtcnative or
tcnative.dll active? If so, what version?

- -chris

> On Wed, Jun 21, 2017 at 1:16 PM, Christopher Schultz 
>  wrote: Racine,
> 
> On 6/21/17 12:38 PM, Racine Faye wrote:
 I have noticed that in Tomcat 8.5.15 on the Windows Server
 2008 Operating System that the way that tomcat presents user 
 certificates has changed. I have a trust store that I use on
 the tomcat 8.5.14 version that has only DoD intermediate
 Email certificates which makes it so when users go to the
 site they are prompted for only their email cert.
 
 When upgrading to 8.5.15 I used the same trust store and it
 now prompts for all certificates on the computer.
> 
> What prompts for all certificates on the computer?
> 
 I am not sure if that is intended behavior or an oversight
 but it is kind of confusing to users to be presented
 certificates that they can't use.
> I don't believe Tomcat is presenting any certificates to the user,
> is it? It's the browser that is showing the certificate selection
> to the user. What browser are you using?
> 
 Another reason for having them only select the email cert is
 that only the email certificate contains the information that
 we need to get their user ID.
> This is informative, but not really relevant. Theoretically, the
> user can provide any certificate that has been signed by a
> certificate in the trust store. So if the user decides to provide a
> signed certificate that does *not* have the email address in it,
> then your application needs to be the one signalling an error.
> 
 I want to see if anyone else is having this issue or if
 anyone has noticed that when specifying a 

Re: Reg CVE-2017-5664

[Mark Thomas]

On 22/06/17 16:46, Durga Srinivasu Karuturi wrote:
> Hi,
> 
> We are using tomcat 8.5.14.
> 
> As this CVE-2017-5664
>  is applicable
> for current tomcat version, we are trying to evaluate whethere this CVE is
> applicable to our web application or not.
> 
> 
> We have couple of JSP error pages. Tested those all are severed as GET.

No issue with the JSPs as long as they don't check the HTTP method and
take different actions depending on what it is.

> Also we have custom error Servlet handler configured and in that also, we
> do handle it as GET only.

Might be worth checking how those servlets respond to non-GET requests.
If you have only implemented doGet() your users could see a 405 response
rather than the error page. That should be OK from a security point of view.

> There are no static error files configured in our web application.

Good. That removes probably the biggest risk which is the default servlet.

> With these can be take this CVE is not application to our web application
> with 8.5.14 tomcat?

>From the information you have provided, you look to be OK but it is
worth checking the few things I pointed out above.

Mark

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

Re: Reg CVE-2017-5664

[Durga Srinivasu Karuturi]

No, we are using RHEL with embed tomcat running inside java.

Thanks,
Durga Srinivasu

On Thu, Jun 22, 2017 at 10:03 PM, Emmanuel Bourg  wrote:

> Le 22/06/2017 à 17:46, Durga Srinivasu Karuturi a écrit :
>
> > We are using tomcat 8.5.14.
>
> From Debian 9? If so this has been patched today:
>
>   https://www.debian.org/security/2017/dsa-3891
>
> Emmanuel Bourg
>

Re: Reg CVE-2017-5664

[Emmanuel Bourg]

Le 22/06/2017 à 17:46, Durga Srinivasu Karuturi a écrit :

> We are using tomcat 8.5.14.

>From Debian 9? If so this has been patched today:

  https://www.debian.org/security/2017/dsa-3891

Emmanuel Bourg

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

Reg CVE-2017-5664

[Durga Srinivasu Karuturi]

Hi,

We are using tomcat 8.5.14.

As this CVE-2017-5664
 is applicable
for current tomcat version, we are trying to evaluate whethere this CVE is
applicable to our web application or not.


We have couple of JSP error pages. Tested those all are severed as GET.

Also we have custom error Servlet handler configured and in that also, we
do handle it as GET only.

There are no static error files configured in our web application.

With these can be take this CVE is not application to our web application
with 8.5.14 tomcat?

Please suggest.

Thanks,
Durga Srinivasu

Re: How to stop Tomcat if servlet fails to initialize

[Mark Thomas]

On 22/06/17 11:57, Pesonen, Harri wrote:
> 8.5.13. Maybe it is supported in 9 only.

Yes, throwOnFailure is 9.0.x only. It comes from
https://bz.apache.org/bugzilla/show_bug.cgi?id=60152

What you can do in 8.5.x (and 9.0.x) is:


That will stop the web application starting if a load-on-startup servlet
fails.

Looking more at the changes for throwOnFailure, it isn't going to help
because the Context failure in this case is viewed as a controlled
failure. i.e. the Context detected a problem and put itself into the
failed state.

What you could do - which would work equally well in 8.5.x and 9.0.x is
write a simple LifecycleListener, attach it to the Server and have it
traverse the container hierarchy on the Lifecycle.AFTER_START_EVENT and
check that all containers are started. If any are found in the FAILED
state, shut Tomcat down.

Mark


> 
> -Harri
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: 22. kesäkuuta 2017 13:46
> To: Tomcat Users List 
> Subject: Re: How to stop Tomcat if servlet fails to initialize
> 
> On 22/06/17 11:44, Pesonen, Harri wrote:
>> Hello, I tried adding throwOnFailure to conf/context.xml, but it did not 
>> work, I only got this:
>>
>> 10:34:23.582 (14) WRN> 
>> (org.apache.catalina.startup.SetContextPropertiesRule#begin) 
>> [SetContextPropertiesRule]{Context} Setting property 'throwOnFailure' to 
>> 'true' did not find a matching property.
>>
>> Maybe I did it wrong:
>>
>> 
> 
> I was working from the code rather than testing but this should work.
> What version are you using?
> 
> Mark
> 
> 
>>
>> -Harri
>>
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org] 
>> Sent: 21. kesäkuuta 2017 17:28
>> To: Tomcat Users List 
>> Subject: Re: How to stop Tomcat if servlet fails to initialize
>>
>> On 21/06/17 13:33, Pesonen, Harri wrote:
>>> Hello, if one servlet fails to initialize, meaning that 
>>> ServletContextListener.contextInitialized() throws exception, then Tomcat 
>>> still starts (but without the servlet). 
>>
>> If ServletContextListener.contextInitialized(), the web application will
>> not start.
>>
>> Servlets are not initialised until first used so they can't prevent an
>> application from starting. The one exception is Servlets configured for
>> "load on startup". Any failure of these servlets will cause the
>> application to fail to start.
>>
>>> I found out that if servlet calls System.exit(1), then Tomcat dies. Is this 
>>> the only way to make this happen?
>>> This does not work:
>>> -Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=true
>>
>> You can try setting the (completely undocumented) throwOnFailure
>> attribute for the Context, Host, Engine, Service and Server.
>>
>> The Context you can set in conf/context.xml so it applies to all web
>> applications.
>>
>> Mark
>>
>> -
>> 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
>>
> 
> 
> -
> 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
> 


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

Re: Tomcat 8.5.15 Client Authentication Trust Store Changes

[Mark Thomas]

On 21/06/17 20:53, Racine Faye wrote:
> Thanks for the reply Christopher. The way tomcat has always worked in
> the past(Before 8.5.15) , is that your trust store is what tomcat uses
> to decide what certificates the browser should show to the user
> because it only shows them certificates that are in the certificate
> chain of whatever you import into your trust store. So if you import a
> root certificate it will show everything that has that root
> certificate in its chain but if you import in an intermediate it will
> only show the certificates that the intermediate accepts. So the way
> it works for DoD is that on each CAC there are 2 client authentication
> certificates one Email Cert and one ID cert. They contain different
> information mainly the email address is only contained in the Email
> cert. When users are prompted to select a certificate they are only
> supposed to be given the selection of what certificates are in the
> trust store because it knows that anything not in that trust store
> won't be accepted anyways. When you set the clientAuth to true in the
> connector that is what makes it so Tomcat then asks for a certificate
> from the user for validation. I have used both IE and Chrome and I get
> the same results in both. I am pretty sure it is not a browser issue
> though because I have both Tomcat 8.5.15 and 8.5.14 running on the
> same server using the same trust store and 8.5.14 asks for only
> Certificates that are in the Chain of the Intermediates that I
> imported in and 8.5.15 asks for all of the certificates. Unfortunately
> I am not able to run openssl as I am on a goverment network and the
> software we can use is restricted.
> https://stackoverflow.com/questions/1666052/java-https-client-certificate-authentication
> The previous link  has a pretty good explanation of the way Tomcat has
> always worked in the past in the comments and explains about the
> behavior I am expecting.

I cannot reproduce the behaviour you are seeing.

I have tested with 8.5.14 and 8.5.15 (building both from source) and in
both cases specifying a truststoreFile limits the certs presented by the
browser to those signed by those in the truststoreFile.

That said, there have been quite a few changes in the TLS configuration
for 8.5.x and 9.0.x and it is possible that some edge cases exist that
are not handled correctly.

If you want us to look at this further you are going to need to provide
a test case that demonstrates the problem. This will need to include:

- Connector configuration for server.xml that reproduces the issue
- A complete set of keystores, certs and keys to configure Tomcat and
  the browser
- Instructions on how to reproduce the issue

Obviously don't use real certs for any of the above. The TLS generation
presentation from 2016 may help you create all of these.
http://tomcat.apache.org/presentations.html

Finally, all of the above needs to be as simple as possible.

Mark

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

RE: How to stop Tomcat if servlet fails to initialize

[Pesonen, Harri]

8.5.13. Maybe it is supported in 9 only.

-Harri

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 22. kesäkuuta 2017 13:46
To: Tomcat Users List 
Subject: Re: How to stop Tomcat if servlet fails to initialize

On 22/06/17 11:44, Pesonen, Harri wrote:
> Hello, I tried adding throwOnFailure to conf/context.xml, but it did not 
> work, I only got this:
> 
> 10:34:23.582 (14) WRN> 
> (org.apache.catalina.startup.SetContextPropertiesRule#begin) 
> [SetContextPropertiesRule]{Context} Setting property 'throwOnFailure' to 
> 'true' did not find a matching property.
> 
> Maybe I did it wrong:
> 
> 

I was working from the code rather than testing but this should work.
What version are you using?

Mark


> 
> -Harri
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: 21. kesäkuuta 2017 17:28
> To: Tomcat Users List 
> Subject: Re: How to stop Tomcat if servlet fails to initialize
> 
> On 21/06/17 13:33, Pesonen, Harri wrote:
>> Hello, if one servlet fails to initialize, meaning that 
>> ServletContextListener.contextInitialized() throws exception, then Tomcat 
>> still starts (but without the servlet). 
> 
> If ServletContextListener.contextInitialized(), the web application will
> not start.
> 
> Servlets are not initialised until first used so they can't prevent an
> application from starting. The one exception is Servlets configured for
> "load on startup". Any failure of these servlets will cause the
> application to fail to start.
> 
>> I found out that if servlet calls System.exit(1), then Tomcat dies. Is this 
>> the only way to make this happen?
>> This does not work:
>> -Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=true
> 
> You can try setting the (completely undocumented) throwOnFailure
> attribute for the Context, Host, Engine, Service and Server.
> 
> The Context you can set in conf/context.xml so it applies to all web
> applications.
> 
> Mark
> 
> -
> 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
> 


-
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

Re: How to stop Tomcat if servlet fails to initialize

[Mark Thomas]

On 22/06/17 11:44, Pesonen, Harri wrote:
> Hello, I tried adding throwOnFailure to conf/context.xml, but it did not 
> work, I only got this:
> 
> 10:34:23.582 (14) WRN> 
> (org.apache.catalina.startup.SetContextPropertiesRule#begin) 
> [SetContextPropertiesRule]{Context} Setting property 'throwOnFailure' to 
> 'true' did not find a matching property.
> 
> Maybe I did it wrong:
> 
> 

I was working from the code rather than testing but this should work.
What version are you using?

Mark


> 
> -Harri
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: 21. kesäkuuta 2017 17:28
> To: Tomcat Users List 
> Subject: Re: How to stop Tomcat if servlet fails to initialize
> 
> On 21/06/17 13:33, Pesonen, Harri wrote:
>> Hello, if one servlet fails to initialize, meaning that 
>> ServletContextListener.contextInitialized() throws exception, then Tomcat 
>> still starts (but without the servlet). 
> 
> If ServletContextListener.contextInitialized(), the web application will
> not start.
> 
> Servlets are not initialised until first used so they can't prevent an
> application from starting. The one exception is Servlets configured for
> "load on startup". Any failure of these servlets will cause the
> application to fail to start.
> 
>> I found out that if servlet calls System.exit(1), then Tomcat dies. Is this 
>> the only way to make this happen?
>> This does not work:
>> -Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=true
> 
> You can try setting the (completely undocumented) throwOnFailure
> attribute for the Context, Host, Engine, Service and Server.
> 
> The Context you can set in conf/context.xml so it applies to all web
> applications.
> 
> Mark
> 
> -
> 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
> 


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

RE: How to stop Tomcat if servlet fails to initialize

[Pesonen, Harri]

Hello, I tried adding throwOnFailure to conf/context.xml, but it did not work, 
I only got this:

10:34:23.582 (14) WRN> 
(org.apache.catalina.startup.SetContextPropertiesRule#begin) 
[SetContextPropertiesRule]{Context} Setting property 'throwOnFailure' to 'true' 
did not find a matching property.

Maybe I did it wrong:



-Harri

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 21. kesäkuuta 2017 17:28
To: Tomcat Users List 
Subject: Re: How to stop Tomcat if servlet fails to initialize

On 21/06/17 13:33, Pesonen, Harri wrote:
> Hello, if one servlet fails to initialize, meaning that 
> ServletContextListener.contextInitialized() throws exception, then Tomcat 
> still starts (but without the servlet). 

If ServletContextListener.contextInitialized(), the web application will
not start.

Servlets are not initialised until first used so they can't prevent an
application from starting. The one exception is Servlets configured for
"load on startup". Any failure of these servlets will cause the
application to fail to start.

> I found out that if servlet calls System.exit(1), then Tomcat dies. Is this 
> the only way to make this happen?
> This does not work:
> -Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=true

You can try setting the (completely undocumented) throwOnFailure
attribute for the Context, Host, Engine, Service and Server.

The Context you can set in conf/context.xml so it applies to all web
applications.

Mark

-
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

Re: RewriteValve forward or redirect ?

[Jérémie Barthés]

May you please test RewriteValve with any tomcat after version 8 with 
following conditions :


add RewriteValve in conf/server.xml


add rewriteRule in conf/Catalina/localhost/rewrite.config
RewriteRule ^/IWantThisVisible/(.*)$ /examples/$1/

start tomcat

go to following URL (any internet browser) :
http://localhost:8080/IWantThisVisible/servlets
http://localhost:8080/IWantThisVisible/servlets/

Thanks for you help

Jeremie


Le 20/06/2017 à 18:50, Jérémie Barthés a écrit :

RewriteRule ^/visibleURL/(.*)$ /examples/$1/
(missing space between ^/visibleURL/(.*)$ and /examples/$1/)

Le 20/06/2017 à 18:31, Jérémie Barthés a écrit :

please test what i put in my mail :

install a brand new tomcat 9 from archive (last version)

put a RewriteValve in server.xml



in the file /conf/Catalina/localhost/rewrite.config add
RewriteRule ^/visibleURL/(.*)$/examples/$1/

now start tomcat and go to /visibleURL/servlets/
then go to /visibleURL/servlets

you'll see what i'm talking about

Thanks

Jeremie



Le 20/06/2017 à 18:08, Christopher Schultz a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 6/20/17 9:32 AM, Jérémie Barthés wrote:

http://192.168.1.1:8080/visibleURL/servlets/ URL displayed =
http://192.168.1.1:8080/visibleURL/servlets/ page displayed =
http://192.168.1.1:8080/examples/servlets/

http://192.168.1.1:8080/visibleURL/servlets URL displayed =
http://192.168.1.1:8080/examples/servlets/ page displayed =
http://192.168.1.1:8080/examples/servlets/

i don't want http://192.168.1.1:8080/examples/servlets/ to be
displayed !

What do you mean "URL displayed" and "page displayed"? It sounds like
you want the URL to look exactly as it does look.

- -chris


Le 20/06/2017 à 15:26, Jérémie Barthés a écrit :

Hi,

I have some issues with my brand new tomcat 9.0.0.M21

I just unzipped *windows-64 core*

Then i added the *RewriteValve *in *conf/server.xml* / // //  // //
//
//  /

Then i added a rewriteRule in
*/conf/Catalina/localhost/rewrite.config* file : /RewriteRule
^/visibleURL/(.*)$  /examples/$1/

Then i started tomcat with startup.bat (my IP is 192.168.1.1)

in Firefox, i go to
_*http://192.168.1.1:8080/visibleURL/servlets/ *_ The URL
displayed by firefox
is/**//http://192.168.1.1:8080/visibleURL/servlets// and the
page displayed is /http://192.168.1.1:8080/examples/servlets/ /

now i go to *_http://192.168.1.1:8080/visibleURL/servlet__s_ *The
URL displayed by firefox is
/http://192.168.1.1:8080/examples/servlets//**and the page
displayed is /http://192.168.1.1:8080/examples/servlets/ /* *

I really want my users to see "visibleURL" in the URL displayed
by firefox even if they forget to type a "/". I don't want them
to see "examples" Where did i go wrong ?

Please Help

Thanks a lot

Jeremie




-



To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

For additional commands, e-mail: users-h...@tomcat.apache.org


-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllJSJQACgkQHPApP6U8
pFhITA/+OeOSADj+aeTCoCZC2q1n8+uzen6pYGNjI22Kk7iZnf529WueXfNaH9U7
6TqF+mfYf5H2gkHQR9Ht+8zDmUzzJsBLK+fKHyBplxU8o1jeC+QmhxC++OgEBVsI
DwEzqHKexGqsqkY2ua37gZm0EVra5HaQbbrPGP2RLqT3JWbx2rMAdEWlsz+mYn81
RBmLWnT3hr4r3xhE799dP/f2IP5uz0akdh68B+4rEnmsMvy3rHfalGt3Jv2yOClr
ompHO+C4ThRdcH8Zn0Y7MOwjvdkAZ1u9DLh84xpz2a33gHJnzz0I+p7cMtbpQVPf
8Z7S+692z4TD2GD0MSedUnNy3ryNvFG8UQZXBJ/pg83ZjmGNHe2orKnqMKgaTGhk
lplXZp1R6wqe2lLdJfyTsK2Lv75/oj+8FbNClfms4blcodmVPKcQq5c23tOx7QBe
RLZpTarNtzWK+3zEgOOSMlkkuuqXvuPNmgkZ7efachk6Lr+gp4nJ9uPbwMrTrVE/
F/ZHhV8nkE2r13fpoi9g2P32VCl9GSqBtJGeOYC4YHHwmmz6SjtT5XbU14XMj28m
lBMyuRmHeP5OsP6yvuaYUa64tMqaUP95/Rhry1Ne7e6R4LRMSqPR7nwKmZxn0kVu
JpCTkf/p9PRmB/S9752JxgwDeKBfcubajRSNI65sXLB5tljhDSE=
=nU9X
-END PGP SIGNATURE-

-
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




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