You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Igor Cicimov <ic...@gmail.com> on 2018/02/23 09:45:22 UTC
JKS certificate for Tomcat client authentication
Hi all,
I have the following setup in the tomcat default file on Ubunntu-14.04:
JAVA_OPTS="$JAVA_OPTS
-Djavax.net.ssl.keyStore=/opt/encompass/keystore/keystore.jks"
JAVA_OPTS="$JAVA_OPTS
-Djavax.net.ssl.trustStore=/opt/encompass/keystore/truststore.jks"
The keystore.jks holds dozen of SSL keys our app uses to authenticate to
various web services. One of these certificates expired and I used openssl
to create new private key (key.pem) and CSR, that the other side signed and
sent back (cert.pem). Then I concatenated the certificate and the private
key into single file:
$ cat cert.pem key.pem > cert2.pem
and imported the file into the existing keystore using keytool:
$ keytool -delete -alias client-cert -keystore keystore.jks -storepass xxxx
$ keytool -import -alias client-cert -file cert2.pem -keystore keystore.jks
-storepass xxxx
The signing root CA and the intermediate certificate already exist in the
truststore.jks keystore.
Does this procedure sound sane? Is there a better (or maybe proper) way of
doing it?
Thanks,
Igor
Re: JKS certificate for Tomcat client authentication
Posted by Igor Cicimov <ic...@gmail.com>.
Hi Chris,
On Tue, Feb 27, 2018 at 1:56 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Igor,
>
> On 2/23/18 5:47 PM, Igor Cicimov wrote:
> > On Sat, Feb 24, 2018 at 7:52 AM, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >>
> >> Igor,
> >>
> >> On 2/23/18 4:45 AM, Igor Cicimov wrote:
> >>> Hi all,
> >>>
> >>> I have the following setup in the tomcat default file on
> >>> Ubunntu-14.04:
> >>>
> >>> JAVA_OPTS="$JAVA_OPTS
> >>> -Djavax.net.ssl.keyStore=/opt/encompass/keystore/keystore.jks"
> >>> JAVA_OPTS="$JAVA_OPTS
> >>> -Djavax.net.ssl.trustStore=/opt/encompass/keystore/truststore.jks"
> >>>
> >>>
> >>>
> The keystore.jks holds dozen of SSL keys our app uses to
> >>> authenticate to various web services. One of these
> >>> certificates expired and I used openssl to create new private
> >>> key (key.pem) and CSR, that the other side signed and sent back
> >>> (cert.pem). Then I concatenated the certificate and the private
> >>> key into single file:
> >>>
> >>> $ cat cert.pem key.pem > cert2.pem
> >>>
> >>> and imported the file into the existing keystore using
> >>> keytool:
> >>>
> >>> $ keytool -delete -alias client-cert -keystore keystore.jks
> >>> -storepass xxxx $ keytool -import -alias client-cert -file
> >>> cert2.pem -keystore keystore.jks -storepass xxxx
> >>>
> >>> The signing root CA and the intermediate certificate already
> >>> exist in the truststore.jks keystore.
> >>>
> >>> Does this procedure sound sane? Is there a better (or maybe
> >>> proper) way of doing it?
> >>
> >> Are you just sanity-checking your process for importing certs
> >> into a JKS bundle?
> >>
> >
> > I'm just sanity-checking the process in terms of keystore
> > functionality and any possible issues for the JVM using and finding
> > the cert and the key in the store.
> >
> > The reason being after importing the new cert our access does not
> > work any more and the issuer has a limited (as they say, *sigh*)
> > troubleshooting capability on their side. Not sure how is that
> > possible having in mind that they have designed and are in control
> > of the authentication (ssl client certs) and authorization
> > (username/password) system (Tivoli Axis2 app if that matters).
> > Building something and then not being able to tell clients if their
> > access is denied due to bad/missing certificate or bad/missing
> > credentials is just unbelievable. They even claim they can't even
> > see our side connecting at all to their web service although in our
> > logs I can see:
> >
> > Invalid Content-Type:text/html. Is this an error message instead of
> > a SOAP response?
> >
> > response coming back but as html error message instead of SOAP
> > response.
>
> You could try my ssltest tool. It supports client TLS authentication.
> Maybe just a sanity-check that there isn't anything wrong with your
> own Java client:
>
> https://github.com/ChristopherSchultz/ssltest
>
> Also, since you have the original (separate) key and (signed)
> certificate files, definitely give this a try:
>
> $ openssl s_client \
> -showcerts \
> -cert cert.pem \
> -key key.pem \
> -connect [endpoint]
>
> If you can't connect using that, then either the cert or the key is
> not correct. OpenSSL should tell you if the key doesn't match the
> cert, or if the password is wrong.
>
> If you remove the -cert and -key arguments and try to connect, the
> service ought to tell you which certificates are acceptable. It will
> probably tell you that anything signed by a particular certificate is
> okay and not your particular certificate (otherwise, they'd have a
> million certs they trust).
>
> Once you can confirm that the crypto material you have (key, certs),
> then you can use ssltest above to see if you have packaged those bits
> into the keystore properly. You might want to use a separate keystore
> for this testing purpose, just in case something else is interfering.
>
> Theoretically, as long as your keystore contains:
>
> 1. The signing (or, more likely, the "intermediate") certificate
> 2. The signed certificate
> 3. The signed certificate's private key
>
> You ought to be able to connect. You don't really even need a
> certificate "alias", though things "seem" to work better when they are
> present.
>
> >> Does the process result in the items you expected to be in the
> >> keystore?
> >>
> >
> >> From what I can see all the bits are there. I have enabled the
> >> java ssl
> > debugging and can see the cert being loaded on startup and
> > exchanged during SSL handshake and no errors can be seen in the
> > process, like the usual PKIX error when matching cert can not be
> > found etc.
> >
> > Any ideas what can be possibly wrong?
>
> Lots of things:
>
> 1. Wrong cert in the store (unsigned versus signed, though if you are
> using openssl for everything you usually don't have an unsigned
> cert... only the CSR).
>
> 2. Missing intermediate certificate. This can be easy to do if you
> have a keystore with lots of stuff in it. Perhaps the service has
> rotated their intermediate certificate and your newly-issued
> certificate was signed with a certificate newer than the one already
> in your keystore.
>
> 3. Mismatched key/cert.
>
> 4. Certificate needs an "alias" for some reason? But you are providing
> one, so ... probably not this.
>
> 5. Can't negotiate some other part of the TLS connection. Maybe they
> only support TLSv1.2 or something? Or no cipher suites in common?
> OpenSSL should tell you what's up.
>
> >> I'd personally be very paranoid if the JKS file was the only
> >> place all of those key/cert pairs were stored, because of my
> >> (bad) experience using JKS keystores in the past. Thankfully,
> >> Oracle is finally deprecating them and making the default
> >> keystore type PKCS12 in the future. JKS (and it's surprisingly
> >> extant cousin, JSEKS) never should have existed.
> >>
> >>
> > Yeah I saw some warning messages with the latest Oracle jdk-1.8_161
> > about JKS being deprecated in favour of PKCS12 when I use keytool
> > on the servers. I never saw those before at least not for jdk-1.7
> > for sure.
>
> IIRC, PKCS12 has always been supported by the JVM. So if you'd like to
> switch from one format to another, you should have no trouble. Once
> you get it working /at all/, that is.
>
> IMHO, you should try to use separate keystores for separate services
> if you can manage it. So if you connect to 5 services which require
> mutual TLS authentication, I'd have 5 separate keystores which only
> contain the bits required to connect to that one service.
>
> I'd do that for several reasons, but one of those reasons is that at
> some point, you'll need to completely change what's in the keystore
> (new key/certicicate, new intermediate cert from the issuer, etc.) and
> you won't know what you can remove safely if it's an all-in-one
> bundle. Over time, you'll end up with 100 certificates that you aren't
> sure if you need anymore.
>
> Anytime I have code, configuration, etc. that I'm "afraid" to touch
> for fear of breaking something, it's a red flag that it's not being
> maintained properly. Separate keystores are much easier to maintain.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqUICodHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFi9wQ//ekXAbj7N7+qI/2OI
> JUG59rhBDoyfu+kFjyLuLJXvho8t8uACEBrNUjWrBm9zOSO1zUGoAwCa7vk6FyNy
> 9L30dzYAEy+MnMDAZ0WJqAgfAwWUEVaTvgkhqnLC7RBLqMmLKUKw5wWFF497Yoq/
> AdX1+dFD12a3OoepwTr5Bhgiz34gUF5Ufom5vQAaGNTwepw6/+K3lyHZCqHAoYxX
> VjREWRLpFjKkAIfnL2V/Sif3q4dhpu+XUBmlHvs2uG35Z2dSpoLK6XgftVSVVVng
> 4+s9dTKpEb7KE3jK2EZFAYa8mv2EG5NMiDS/UPmMOm8MpGbHgq6W05WetrC634+G
> P69DLcU4074ml3rf163fyu3O+Bv2JFFzbegXbfswnCI6gOFW2h0lR5Kp/e4u24Km
> D5irRnRafYGp9TFe0xSsNcWC8qRPAjnY2Ouvpvb5hRFfE8EePN9eI8uOrYVPbRcO
> 8Cg7IE4WEiIwwEWVCy3CKnIDSu4nBduEl3L3A1eIQ8evCr4JzOZ6q0TVkk+rPdre
> IvOgaveJ0+oLDRO00yvhvoSLZTFGkvSaADJ5rL8YkdbSgUV82/B4UfRTs1r2Rq9f
> 33o+0/ra9rP8J3zDmL4AofVH9j28TD3BIecM7qP5wwNp3U9cWZRM3PI8yA+VD9cF
> fPT7atxpHY2SZVEX6PU7hdZNEbA=
> =jmUY
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> First thanks for your very detailed answer and sorry for the very delayed
response, I was on holiday for couple of weeks. I re-imported everything as
PKCS12 bundle (the client cert, the intermediate, the root CA and the
private key) and that seems has solved the issue. Really not sure what was
wrong with the previous one but I will have another look at it when I get a
chance.
Thanks,
Igor
Re: JKS certificate for Tomcat client authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Igor,
On 2/23/18 5:47 PM, Igor Cicimov wrote:
> On Sat, Feb 24, 2018 at 7:52 AM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Igor,
>>
>> On 2/23/18 4:45 AM, Igor Cicimov wrote:
>>> Hi all,
>>>
>>> I have the following setup in the tomcat default file on
>>> Ubunntu-14.04:
>>>
>>> JAVA_OPTS="$JAVA_OPTS
>>> -Djavax.net.ssl.keyStore=/opt/encompass/keystore/keystore.jks"
>>> JAVA_OPTS="$JAVA_OPTS
>>> -Djavax.net.ssl.trustStore=/opt/encompass/keystore/truststore.jks"
>>>
>>>
>>>
The keystore.jks holds dozen of SSL keys our app uses to
>>> authenticate to various web services. One of these
>>> certificates expired and I used openssl to create new private
>>> key (key.pem) and CSR, that the other side signed and sent back
>>> (cert.pem). Then I concatenated the certificate and the private
>>> key into single file:
>>>
>>> $ cat cert.pem key.pem > cert2.pem
>>>
>>> and imported the file into the existing keystore using
>>> keytool:
>>>
>>> $ keytool -delete -alias client-cert -keystore keystore.jks
>>> -storepass xxxx $ keytool -import -alias client-cert -file
>>> cert2.pem -keystore keystore.jks -storepass xxxx
>>>
>>> The signing root CA and the intermediate certificate already
>>> exist in the truststore.jks keystore.
>>>
>>> Does this procedure sound sane? Is there a better (or maybe
>>> proper) way of doing it?
>>
>> Are you just sanity-checking your process for importing certs
>> into a JKS bundle?
>>
>
> I'm just sanity-checking the process in terms of keystore
> functionality and any possible issues for the JVM using and finding
> the cert and the key in the store.
>
> The reason being after importing the new cert our access does not
> work any more and the issuer has a limited (as they say, *sigh*)
> troubleshooting capability on their side. Not sure how is that
> possible having in mind that they have designed and are in control
> of the authentication (ssl client certs) and authorization
> (username/password) system (Tivoli Axis2 app if that matters).
> Building something and then not being able to tell clients if their
> access is denied due to bad/missing certificate or bad/missing
> credentials is just unbelievable. They even claim they can't even
> see our side connecting at all to their web service although in our
> logs I can see:
>
> Invalid Content-Type:text/html. Is this an error message instead of
> a SOAP response?
>
> response coming back but as html error message instead of SOAP
> response.
You could try my ssltest tool. It supports client TLS authentication.
Maybe just a sanity-check that there isn't anything wrong with your
own Java client:
https://github.com/ChristopherSchultz/ssltest
Also, since you have the original (separate) key and (signed)
certificate files, definitely give this a try:
$ openssl s_client \
-showcerts \
-cert cert.pem \
-key key.pem \
-connect [endpoint]
If you can't connect using that, then either the cert or the key is
not correct. OpenSSL should tell you if the key doesn't match the
cert, or if the password is wrong.
If you remove the -cert and -key arguments and try to connect, the
service ought to tell you which certificates are acceptable. It will
probably tell you that anything signed by a particular certificate is
okay and not your particular certificate (otherwise, they'd have a
million certs they trust).
Once you can confirm that the crypto material you have (key, certs),
then you can use ssltest above to see if you have packaged those bits
into the keystore properly. You might want to use a separate keystore
for this testing purpose, just in case something else is interfering.
Theoretically, as long as your keystore contains:
1. The signing (or, more likely, the "intermediate") certificate
2. The signed certificate
3. The signed certificate's private key
You ought to be able to connect. You don't really even need a
certificate "alias", though things "seem" to work better when they are
present.
>> Does the process result in the items you expected to be in the
>> keystore?
>>
>
>> From what I can see all the bits are there. I have enabled the
>> java ssl
> debugging and can see the cert being loaded on startup and
> exchanged during SSL handshake and no errors can be seen in the
> process, like the usual PKIX error when matching cert can not be
> found etc.
>
> Any ideas what can be possibly wrong?
Lots of things:
1. Wrong cert in the store (unsigned versus signed, though if you are
using openssl for everything you usually don't have an unsigned
cert... only the CSR).
2. Missing intermediate certificate. This can be easy to do if you
have a keystore with lots of stuff in it. Perhaps the service has
rotated their intermediate certificate and your newly-issued
certificate was signed with a certificate newer than the one already
in your keystore.
3. Mismatched key/cert.
4. Certificate needs an "alias" for some reason? But you are providing
one, so ... probably not this.
5. Can't negotiate some other part of the TLS connection. Maybe they
only support TLSv1.2 or something? Or no cipher suites in common?
OpenSSL should tell you what's up.
>> I'd personally be very paranoid if the JKS file was the only
>> place all of those key/cert pairs were stored, because of my
>> (bad) experience using JKS keystores in the past. Thankfully,
>> Oracle is finally deprecating them and making the default
>> keystore type PKCS12 in the future. JKS (and it's surprisingly
>> extant cousin, JSEKS) never should have existed.
>>
>>
> Yeah I saw some warning messages with the latest Oracle jdk-1.8_161
> about JKS being deprecated in favour of PKCS12 when I use keytool
> on the servers. I never saw those before at least not for jdk-1.7
> for sure.
IIRC, PKCS12 has always been supported by the JVM. So if you'd like to
switch from one format to another, you should have no trouble. Once
you get it working /at all/, that is.
IMHO, you should try to use separate keystores for separate services
if you can manage it. So if you connect to 5 services which require
mutual TLS authentication, I'd have 5 separate keystores which only
contain the bits required to connect to that one service.
I'd do that for several reasons, but one of those reasons is that at
some point, you'll need to completely change what's in the keystore
(new key/certicicate, new intermediate cert from the issuer, etc.) and
you won't know what you can remove safely if it's an all-in-one
bundle. Over time, you'll end up with 100 certificates that you aren't
sure if you need anymore.
Anytime I have code, configuration, etc. that I'm "afraid" to touch
for fear of breaking something, it's a red flag that it's not being
maintained properly. Separate keystores are much easier to maintain.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqUICodHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFi9wQ//ekXAbj7N7+qI/2OI
JUG59rhBDoyfu+kFjyLuLJXvho8t8uACEBrNUjWrBm9zOSO1zUGoAwCa7vk6FyNy
9L30dzYAEy+MnMDAZ0WJqAgfAwWUEVaTvgkhqnLC7RBLqMmLKUKw5wWFF497Yoq/
AdX1+dFD12a3OoepwTr5Bhgiz34gUF5Ufom5vQAaGNTwepw6/+K3lyHZCqHAoYxX
VjREWRLpFjKkAIfnL2V/Sif3q4dhpu+XUBmlHvs2uG35Z2dSpoLK6XgftVSVVVng
4+s9dTKpEb7KE3jK2EZFAYa8mv2EG5NMiDS/UPmMOm8MpGbHgq6W05WetrC634+G
P69DLcU4074ml3rf163fyu3O+Bv2JFFzbegXbfswnCI6gOFW2h0lR5Kp/e4u24Km
D5irRnRafYGp9TFe0xSsNcWC8qRPAjnY2Ouvpvb5hRFfE8EePN9eI8uOrYVPbRcO
8Cg7IE4WEiIwwEWVCy3CKnIDSu4nBduEl3L3A1eIQ8evCr4JzOZ6q0TVkk+rPdre
IvOgaveJ0+oLDRO00yvhvoSLZTFGkvSaADJ5rL8YkdbSgUV82/B4UfRTs1r2Rq9f
33o+0/ra9rP8J3zDmL4AofVH9j28TD3BIecM7qP5wwNp3U9cWZRM3PI8yA+VD9cF
fPT7atxpHY2SZVEX6PU7hdZNEbA=
=jmUY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JKS certificate for Tomcat client authentication
Posted by Igor Cicimov <ic...@gmail.com>.
Hi Chris,
On Sat, Feb 24, 2018 at 7:52 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Igor,
>
> On 2/23/18 4:45 AM, Igor Cicimov wrote:
> > Hi all,
> >
> > I have the following setup in the tomcat default file on
> > Ubunntu-14.04:
> >
> > JAVA_OPTS="$JAVA_OPTS
> > -Djavax.net.ssl.keyStore=/opt/encompass/keystore/keystore.jks"
> > JAVA_OPTS="$JAVA_OPTS
> > -Djavax.net.ssl.trustStore=/opt/encompass/keystore/truststore.jks"
> >
> > The keystore.jks holds dozen of SSL keys our app uses to
> > authenticate to various web services. One of these certificates
> > expired and I used openssl to create new private key (key.pem) and
> > CSR, that the other side signed and sent back (cert.pem). Then I
> > concatenated the certificate and the private key into single file:
> >
> > $ cat cert.pem key.pem > cert2.pem
> >
> > and imported the file into the existing keystore using keytool:
> >
> > $ keytool -delete -alias client-cert -keystore keystore.jks
> > -storepass xxxx $ keytool -import -alias client-cert -file
> > cert2.pem -keystore keystore.jks -storepass xxxx
> >
> > The signing root CA and the intermediate certificate already exist
> > in the truststore.jks keystore.
> >
> > Does this procedure sound sane? Is there a better (or maybe proper)
> > way of doing it?
>
> Are you just sanity-checking your process for importing certs into a
> JKS bundle?
>
I'm just sanity-checking the process in terms of keystore functionality and
any possible issues for the JVM using and finding the cert and the key in
the store.
The reason being after importing the new cert our access does not work any
more and the issuer has a limited (as they say, *sigh*) troubleshooting
capability on their side. Not sure how is that possible having in mind that
they have designed and are in control of the authentication (ssl client
certs) and authorization (username/password) system (Tivoli Axis2 app if
that matters). Building something and then not being able to tell clients
if their access is denied due to bad/missing certificate or bad/missing
credentials is just unbelievable. They even claim they can't even see our
side connecting at all to their web service although in our logs I can see:
Invalid Content-Type:text/html. Is this an error message instead of a SOAP
response?
response coming back but as html error message instead of SOAP response.
> Does the process result in the items you expected to be in the keystore?
>
From what I can see all the bits are there. I have enabled the java ssl
debugging and can see the cert being loaded on startup and exchanged during
SSL handshake and no errors can be seen in the process, like the usual PKIX
error when matching cert can not be found etc.
Any ideas what can be possibly wrong?
> I'd personally be very paranoid if the JKS file was the only place all
> of those key/cert pairs were stored, because of my (bad) experience
> using JKS keystores in the past. Thankfully, Oracle is finally
> deprecating them and making the default keystore type PKCS12 in the
> future. JKS (and it's surprisingly extant cousin, JSEKS) never should
> have existed.
>
>
Yeah I saw some warning messages with the latest Oracle jdk-1.8_161 about
JKS being deprecated in favour of PKCS12 when I use keytool on the servers.
I never saw those before at least not for jdk-1.7 for sure.
> - -chris
>
Thanks,
Igor
Re: JKS certificate for Tomcat client authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Igor,
On 2/23/18 4:45 AM, Igor Cicimov wrote:
> Hi all,
>
> I have the following setup in the tomcat default file on
> Ubunntu-14.04:
>
> JAVA_OPTS="$JAVA_OPTS
> -Djavax.net.ssl.keyStore=/opt/encompass/keystore/keystore.jks"
> JAVA_OPTS="$JAVA_OPTS
> -Djavax.net.ssl.trustStore=/opt/encompass/keystore/truststore.jks"
>
> The keystore.jks holds dozen of SSL keys our app uses to
> authenticate to various web services. One of these certificates
> expired and I used openssl to create new private key (key.pem) and
> CSR, that the other side signed and sent back (cert.pem). Then I
> concatenated the certificate and the private key into single file:
>
> $ cat cert.pem key.pem > cert2.pem
>
> and imported the file into the existing keystore using keytool:
>
> $ keytool -delete -alias client-cert -keystore keystore.jks
> -storepass xxxx $ keytool -import -alias client-cert -file
> cert2.pem -keystore keystore.jks -storepass xxxx
>
> The signing root CA and the intermediate certificate already exist
> in the truststore.jks keystore.
>
> Does this procedure sound sane? Is there a better (or maybe proper)
> way of doing it?
Are you just sanity-checking your process for importing certs into a
JKS bundle?
Does the process result in the items you expected to be in the keystore?
I'd personally be very paranoid if the JKS file was the only place all
of those key/cert pairs were stored, because of my (bad) experience
using JKS keystores in the past. Thankfully, Oracle is finally
deprecating them and making the default keystore type PKCS12 in the
future. JKS (and it's surprisingly extant cousin, JSEKS) never should
have existed.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqQfxMACgkQHPApP6U8
pFgyEA/9E8xItsOkifnpYSqvxfiFsJzLbEQRU7TiIAqqwl3rD0uhDkulnUHtO0h7
mk9bekd7YuWFu3JSm8ht2HklyDbTkEJyRJLHcQupLXE3mj427neeTT2p1oOJxwwu
nuMJ9NQw2Nofas3TlyyvkkIfZddk/Afuq7D4JuXgnKU6DPc2I9YB0RxsMnPmVCn9
ApiGWakOnxeLapAGHdYXg+e1qDOmuYn0VLkr3hkrS07cPuzRTKjmCVBrI8locpUx
MOBYtdEF8rKmEWvTzJI0EM43FEGQaamKaYxBo4LLT0esaE1sM9D8tU/ckgsmTWWN
6pjO4JI0d/yXmeMuTtdspvdoXiLDtJz/krHFI/wPILO8ABMWToAMNSxZJI/s8c4T
CImCz6YJ+K+lLi3638Pz7cQ8V6KXgHaOsj7aaB4jqWyF/Z1heZUg+8xJYX2xo3cn
11br7rXWX5cFPJr7QeS/nZU194/SdGxe2XvpVgCnb6cXVgLd9UKPO/8htp6PmBya
t7RAEE25o/I0ew/ankjRxqz3iwcVWjRZF+r83gisaj3ZltJ+pJx9PPsc9Kd+gc0f
c/iscO/Bt9Jyb/lcJzR1lZ0EMU70RLhLrtGFPYd99Lp5ONsgnYgG3+7NdE5Jw01p
MMy5zTlN8Mm5/xQjopECn3Bfl385UH6dbtLlK/sPZaVElwhySxM=
=F4jp
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org