Re: Where Tomcat webapp contexts live on Debian

[Peter Kreuser]

I'd assume the service that starts tomcat sets the bin-Dir, that contains a 
setenv.sh, that has the CATALINA_HOME and BASE env-Varaibles, where you find 
the context-Files that have a docbase.

I'd like to repeat the question: who did this setup?

Peter Kreuser

> Am 15.08.2017 um 23:45 schrieb James H. H. Lampert :
> 
> I think I've mentioned before that I have a Tomcat server on a Google Compute 
> Debian instance, that I installed with an "apt-get," rather than from an 
> Apache download.
> 
> I had to apt-get manager separately, which is odd to begin with.
> 
> And things ended up in unexpected places.
> 
> Some stuff (like the Catalina directory) wound up in /etc/tomcat7. Other 
> stuff (like the bin and lib directories) wound up in /usr/share/tomcat7.
> 
> But the weirdest thing is where the webapp contexts wound up. The default 
> ROOT context (which doesn't look quite like the default ROOT context of 
> anything I've installed from an Apache download) is in 
> /var/lib/tomcat7/webapps/ROOT. But the manager and host-manager webapps are 
> in /usr/share/tomcat7-admin/manager and /usr/share/tomcat7-admin/host-manager.
> 
> Setting aside any questions of why whoever set this up for Debian did it this 
> way, all of this still raises a very big question:
> 
> How is Tomcat finding all of this?
> 
> --
> JHHL
> 
> -
> 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: 2 Way SSL integration with Webservices - Inbound connection not trusted

[Vinoth Raja]

Hi Chris,

In the above conversation, the server presents the list of acceptable
client certificates to the client. Does that happen for you?

[ Yes . It prints the list of acceptable certificate when
certificateVerification is set to required. It prints the acceptable
certificates from cacerts.
Application is not reachable from browser once certificateVerification is
set to required. It shows "ERR_BAD_SSL_CLIENT_AUTH_CERT".
I have tried setting different trustStore from setenv.bat but doesnt seems
to take effect]


> Can I set the truststore in SSLContext before making outbound call?
> will it trust the client request.

What outbound call? Tomcat only handles incoming HTTP/TLS connections.
[i meant the web service call. yes I am talking about trusting the incoming
TLS connection]

On Wed, Aug 16, 2017 at 12:34 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Vinoth,
>
> On 8/15/17 11:42 AM, Vinoth Raja wrote:
> > clientAuth="true" Is not valid attribute for connector in tomcat
> > 8.5.15. I have tried setting certificateVerifucation as required
> > but application URL is not reachable and it was complaining about
> > certificate.
>
> Does the browser prompt for a certificate?
>
> If you use "openssl s_client -connect [hostname]:[port]" does the
> connection show that trusted certificates are presented?
>
> For example:
>
> $ openssl s_client -connect host:port
>
> CONNECTED(0003)
> [server certificate]
>
> Acceptable client certificate CA names
> /CN=client-certificate1
> /CN=client-certificate2
> ...
> Requested Signature Algorithms:
> RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RS
> A+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+
> SHA1:DSA+SHA1:ECDSA+SHA1
> Shared Requested Signature Algorithms:
> RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RS
> A+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+
> SHA1:DSA+SHA1:ECDSA+SHA1
> Peer signing digest: SHA512
> Server Temp Key: ECDH, P-256, 256 bits
> - ---
> SSL handshake has read 2582 bytes and written 138 bytes
> - ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 4096 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID:
> Session-ID-ctx:
> Master-Key: [session key]
> Key-Arg   : None
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1502814654
> Timeout   : 300 (sec)
> Verify return code: 10 (certificate has expired)
> - ---
> [DISCONNECT]
>
> In the above conversation, the server presents the list of acceptable
> client certificates to the client. Does that happen for you?
>
> > Can I set the truststore in SSLContext before making outbound call?
> > will it trust the client request.
>
> What outbound call? Tomcat only handles incoming HTTP/TLS connections.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmTIpIACgkQHPApP6U8
> pFga/g/8DIfIj6QoCQeMaMu3EoPJO2VjCHfCj11OoxXMkWr3NRlbXPkmtEYo6lQ6
> qBeokSYok+OrLXlY6EM40ofq5rU/5kTzNf4kb116d5na8gz+9DoaVaDC5S+LNzjH
> dKSu2eQXSZA+6OHSo55mH0AGQ1dyY9sZlySCqEJpOSYZMx61lZLz3NjUZqZEZ1wH
> BYeLv1VXHhnB59oyEJNuSaUBlST7iinjfGya/T16/H61gQCV3Sz+aIkmv1IWT82A
> kVYK7UasYg119wKk/2lJskYqloULngGWIbdZo+BrGoSyvBs0BKipErgSBIKwVFVD
> KmTsXPzrftnSmvKuTJgI45QiEYLtWqzVsJof8q2oaGId+KnPJl+HiOAhvIXFaYg5
> 3zsZfi9JRZwJu59CYwew+UVX/+ogwMhjDMgCMsceaGaXqiTwni0T95s2GqSbbUwr
> HSwzXiyCHs7Kh8foWSmrDbrS0OZ1Rs3BvR2vhHMpmvjLxSMbtY0QwUK9arzmcRxJ
> +PWlUlAkZaILcwLo5GR1LVNZzx71l5gYcC8FHQZkeBTmH8Rzedvi5riu2g6suRC2
> T37R0u1iZ7iQTWNH0jLCHZyOWwy1La0fD7t6er7oB3Rq1F+2njNw/gIkLwRWni3V
> YQo+KjoHP5v9ao7tA6Qjs76vqfnj9r1C7IplYeCEbecTnLNTF/w=
> =0zTG
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Where Tomcat webapp contexts live on Debian

[James H. H. Lampert]

I think I've mentioned before that I have a Tomcat server on a Google 
Compute Debian instance, that I installed with an "apt-get," rather than 
from an Apache download.


I had to apt-get manager separately, which is odd to begin with.

And things ended up in unexpected places.

Some stuff (like the Catalina directory) wound up in /etc/tomcat7. Other 
stuff (like the bin and lib directories) wound up in /usr/share/tomcat7.


But the weirdest thing is where the webapp contexts wound up. The 
default ROOT context (which doesn't look quite like the default ROOT 
context of anything I've installed from an Apache download) is in 
/var/lib/tomcat7/webapps/ROOT. But the manager and host-manager webapps 
are in /usr/share/tomcat7-admin/manager and 
/usr/share/tomcat7-admin/host-manager.


Setting aside any questions of why whoever set this up for Debian did it 
this way, all of this still raises a very big question:


How is Tomcat finding all of this?

--
JHHL

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

Re: 2 Way SSL integration with Webservices - Inbound connection not trusted

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Vinoth,

On 8/15/17 11:42 AM, Vinoth Raja wrote:
> clientAuth="true" Is not valid attribute for connector in tomcat
> 8.5.15. I have tried setting certificateVerifucation as required
> but application URL is not reachable and it was complaining about
> certificate.

Does the browser prompt for a certificate?

If you use "openssl s_client -connect [hostname]:[port]" does the
connection show that trusted certificates are presented?

For example:

$ openssl s_client -connect host:port

CONNECTED(0003)
[server certificate]

Acceptable client certificate CA names
/CN=client-certificate1
/CN=client-certificate2
...
Requested Signature Algorithms:
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RS
A+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+
SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms:
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RS
A+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+
SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
- ---
SSL handshake has read 2582 bytes and written 138 bytes
- ---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
Session-ID-ctx:
Master-Key: [session key]
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1502814654
Timeout   : 300 (sec)
Verify return code: 10 (certificate has expired)
- ---
[DISCONNECT]

In the above conversation, the server presents the list of acceptable
client certificates to the client. Does that happen for you?

> Can I set the truststore in SSLContext before making outbound call?
> will it trust the client request.

What outbound call? Tomcat only handles incoming HTTP/TLS connections.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmTIpIACgkQHPApP6U8
pFga/g/8DIfIj6QoCQeMaMu3EoPJO2VjCHfCj11OoxXMkWr3NRlbXPkmtEYo6lQ6
qBeokSYok+OrLXlY6EM40ofq5rU/5kTzNf4kb116d5na8gz+9DoaVaDC5S+LNzjH
dKSu2eQXSZA+6OHSo55mH0AGQ1dyY9sZlySCqEJpOSYZMx61lZLz3NjUZqZEZ1wH
BYeLv1VXHhnB59oyEJNuSaUBlST7iinjfGya/T16/H61gQCV3Sz+aIkmv1IWT82A
kVYK7UasYg119wKk/2lJskYqloULngGWIbdZo+BrGoSyvBs0BKipErgSBIKwVFVD
KmTsXPzrftnSmvKuTJgI45QiEYLtWqzVsJof8q2oaGId+KnPJl+HiOAhvIXFaYg5
3zsZfi9JRZwJu59CYwew+UVX/+ogwMhjDMgCMsceaGaXqiTwni0T95s2GqSbbUwr
HSwzXiyCHs7Kh8foWSmrDbrS0OZ1Rs3BvR2vhHMpmvjLxSMbtY0QwUK9arzmcRxJ
+PWlUlAkZaILcwLo5GR1LVNZzx71l5gYcC8FHQZkeBTmH8Rzedvi5riu2g6suRC2
T37R0u1iZ7iQTWNH0jLCHZyOWwy1La0fD7t6er7oB3Rq1F+2njNw/gIkLwRWni3V
YQo+KjoHP5v9ao7tA6Qjs76vqfnj9r1C7IplYeCEbecTnLNTF/w=
=0zTG
-END PGP SIGNATURE-

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

RE: 2 Way SSL integration with Webservices - Inbound connection not trusted

[Macca, Diego]

Hi,
I didn't know that clientauth is deprecated in 8.5. We still use the good 8.

I have understood that your tomcat receive connections, not act as a client.

If it a server you configure the truststore in tomcat itself (and we also 
configure it in the JVM but should not be needed), if it act as a client 
originating the connection then you need to configure the truststore at the JVM 
level in the Catalina options.


Best regards,
Diego Macca

From: Vinoth Raja mailto:rbvdvin...@gmail.com>>
Date: Tuesday, 15. Aug 2017, 5:42 PM
To: Tomcat Users List mailto:users@tomcat.apache.org>>
Subject: Re: 2 Way SSL integration with Webservices - Inbound connection not 
trusted

Hi Diego,

Thanks.
clientAuth="true" Is not valid attribute for connector in tomcat 8.5.15. I
have tried setting certificateVerifucation as required but application URL
is not reachable and it was complaining about certificate.

Can I set the truststore in SSLContext before making outbound call?.will it
trust the client request.

Let me enable SSL debug and check the log as well.


Thanks
Vinoth


On Tuesday, August 15, 2017, Macca, Diego  wrote:

> Hi,
> You need to set clientAuth="true" in the connector or, for some reason
> unknown to me (probably something changed in Java from rel. 6/7 on), Tomcat
> will not enforce the 2 way ssl.
>
> You can see what is going on (certificates exchange) with an ssl debug.
>
> Kind Regards,
> Diego Macca
> Senior IT Specialist
>
> DG-IS/EDA - Executional Domain Applications
> EUROPEAN CENTRAL BANK
> Tel.: +49 (69) 1344 6991
> E-mail: diego.ma...@ecb.europa.eu 
> www.ecb.europa.eu
> www.youtube.com/ecbeuro
> https://twitter.com/ecb
>
>
> -Original Message-
> From: Vinoth Raja [mailto:rbvdvin...@gmail.com ]
> Sent: 15 August 2017 10:50
> To: Tomcat Users List
> Subject: 2 Way SSL integration with Webservices - Inbound connection not
> trusted
>
> Hi,
>
> Please advise on the step to resolve the issue encountered in 2way SSL
>
> Tomcat version used : apache-tomcat-8.5.15 Java Version used: jdk1.8.0_131
>
> *Problem statement: *Tomcat doesn't trust the inbound connection.
>
> We have web application deployed in tomcat and it integrated with web
> services.
> 2 way SSL is enabled.
> Webservice client deployed in Tomcat send the certificate to webservices
> and it is trusted.
> Tomcat doesn't trust certificate sent by the webservices.
> It seems to ignore the client validation and allow the communication.
>
> *step followed to implement 2 way SSL from application*
>
> We set the keystore and trust store to be used for communication. so it
> takes the cert from key store for outbound and trust the cert for inbound
> connections.
>
>System.setProperty("javax.net.ssl.trustStoreType", "JKS");
> System.setProperty("javax.net.ssl.keyStoreType", "JKS");
> System.setProperty("javax.net.ssl.trustStore","TrustStore.jks");
> System.setProperty("javax.net.ssl.keyStore","KeyStore.jks");
> System.setProperty("javax.net.ssl.trustStorePassword","changeit");
> System.setProperty("javax.net.ssl.keyStorePassword","changeit");
>
> It sends the certificate for other system to trust but it doesn't trust
> the incoming connection.
>
>
> Please advise on the configuration to trust the incoming connection.
>
>
> Thanks
> Vinoth
> Any e-mail message from the European Central Bank (ECB) is sent in good
> faith, but shall neither be binding nor construed as constituting a
> commitment by the ECB except where provided for in a written agreement.
> This e-mail is intended only for the use of the recipient(s) named above.
> Any unauthorised disclosure, use or dissemination, either in whole or in
> part, is prohibited. If you have received this e-mail in error, please
> notify the sender immediately via e-mail and delete this e-mail from your
> system. The ECB processes personal data in line with Regulation (EC) No
> 45/2001 and Decision ECB/2007/1. For any further information you can
> consult the Data Protection Disclaimer on the ECB webpage. In case of
> queries, please contact the ECB Data Protection Officer (d...@ecb.europa.eu
> ). You may also contact the European Data Protection
> Supervisor.
>
Any e-mail message from the European Central Bank (ECB) is sent in good faith, 
but shall neither be binding nor construed as constituting a commitment by the 
ECB except where provided for in a written agreement. This e-mail is intended 
only for the use of the recipient(s) named above. Any unauthorised disclosure, 
use or dissemination, either in whole or in part, is prohibited. If you have 
received this e-mail in error, please notify the sender immediately via e-mail 
and delete this e-mail from your system. The ECB processes personal data in 
line with Regulation (EC) No 45/2001 and Decision ECB/2007/1. For any further 
information you can consult the Data Protection Disclaimer on the ECB webpage. 
In case of queries, please contact the ECB Data Protection Offi

Re: Per EndPoint Threads???

[Owen Rubel]

Owen Rubel
oru...@gmail.com

On Tue, Aug 15, 2017 at 8:23 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Owen,
>
> On 8/13/17 10:46 AM, Owen Rubel wrote:
> > Owen Rubel oru...@gmail.com
> >
> > On Sun, Aug 13, 2017 at 5:57 AM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Owen,
> >
> > On 8/12/17 12:47 PM, Owen Rubel wrote:
>  What I am talking about is something that improves
>  communication as we notice that communication channel needing
>  more resources. Not caching what is communicated... improving
>  the CHANNEL for communicating the resource (whatever it may
>  be).
> >
> > If the channel is an HTTP connection (or TCP; the application
> > protocol isn't terribly relevant), then you are limited by the
> > following:
> >
> > 1. Network bandwidth 2. Available threads (to service a particular
> > request) 3. Hardware resources on the server
> > (CPU/memory/disk/etc.)
> >
> > Let's ignore 1 and 3 for now, since you are primarily concerned
> > with concurrency, and concurrency is useless if the other resources
> > are constrained or otherwise limiting the equation.
> >
> > Let's say we had "per endpoint" thread pools, so that e.g. /create
> > had its own thread pool, and /show had another one, etc. What would
> > that buy us?
> >
> > (Let's ignore for now the fact that one set of threads must always
> > be used to decode the request to decide where it's going, like
> > /create or /show.)
> >
> > If we have a limited total number of threads (e.g. 10), then we
> > could "reserve" some of them so that we could always have 2 threads
> > for /create even if all the other threads in the system (the other
> > 8) were being used for something else. If we had 2 threads for
> > /create and 2 threads for /show, then only 6 would remain for e.g.
> > /edit or /delete. So if 6 threads were already being used for /edit
> > or /delete, the 7th incoming request would be queued, but anyone
> > making a request for /show or /create would (if a thread in those
> > pools is available) be serviced immediately.
> >
> > I can see some utility in this ability, because it would allow the
> > container to ensure that some resources were never starved... or,
> > rather, that they have some priority over certain other services.
> > In other words, the service could enjoy guaranteed provisioning
> > for certain endpoints.
> >
> > As it stands, Tomcat (and, I would venture a guess, most if not
> > all other containers) implements a fair request pipeline where
> > requests are (at least roughly) serviced in the order in which they
> > are received. Rather than guaranteeing provisioning for a
> > particular endpoint, the closest thing that could be implemented
> > (at the application level) would be a
> > resource-availability-limiting mechanism, such as counting the
> > number of in-flight requests and rejecting those which exceed some
> > threshold with e.g. a 503 response.
> >
> > Unfortunately, that doesn't actually prioritize some requests, it
> > merely rejects others in order to attempt to prioritize those
> > others. It also starves endpoints even when there is no reason to
> > do so (e.g. in the 10-thread scenario, if all 4 /show and /create
> > threads are idle, but 6 requests are already in process for the
> > other endpoints, a 7th request for those other endpoints will be
> > rejected).
> >
> > I believe that per-endpoint provisioning is a possibility, but I
> > don't think that the potential gains are worth the certain
> > complexity of the system required to implement it.
> >
> > There are other ways to handle heterogeneous service requests in a
> > way that doesn't starve one type of request in favor of another.
> > One obvious solution is horizontal scaling with a load-balancer. An
> > LB can be used to implement a sort of guaranteed-provisioning for
> > certain endpoints by providing more back-end servers for certain
> > endpoints. If you want to make sure that /show can be called by any
> > client at any time, then make sure you spin-up 1000 /show servers
> > and register them with the load-balancer. You can survive with only
> > maybe 10 nodes servicing /delete requests; others will either wait
> > in a queue or receive a 503 from the lb.
> >
> > For my money, I'd maximize the number of threads available for all
> > requests (whether within a single server, or across a large
> > cluster) and not require that they be available for any particular
> > endpoint. Once you have to depart from a single server, you MUST
> > have something like a load-balancer involved, and therefore the
> > above solution becomes not only more practical but also more
> > powerful.
> >
> > Since relying on a one-box-wonder to run a high-availability web
> > service isn't practical, provisioning is necessarily above the
> > cluster-node level, and so the problem has effectively moved from
> > the app server to the load-balancer

Re: 2 Way SSL integration with Webservices - Inbound connection not trusted

[Vinoth Raja]

Hi Diego,

Thanks.
clientAuth="true" Is not valid attribute for connector in tomcat 8.5.15. I
have tried setting certificateVerifucation as required but application URL
is not reachable and it was complaining about certificate.

Can I set the truststore in SSLContext before making outbound call?.will it
trust the client request.

Let me enable SSL debug and check the log as well.


Thanks
Vinoth


On Tuesday, August 15, 2017, Macca, Diego  wrote:

> Hi,
> You need to set clientAuth="true" in the connector or, for some reason
> unknown to me (probably something changed in Java from rel. 6/7 on), Tomcat
> will not enforce the 2 way ssl.
>
> You can see what is going on (certificates exchange) with an ssl debug.
>
> Kind Regards,
> Diego Macca
> Senior IT Specialist
>
> DG-IS/EDA - Executional Domain Applications
> EUROPEAN CENTRAL BANK
> Tel.: +49 (69) 1344 6991
> E-mail: diego.ma...@ecb.europa.eu 
> www.ecb.europa.eu
> www.youtube.com/ecbeuro
> https://twitter.com/ecb
>
>
> -Original Message-
> From: Vinoth Raja [mailto:rbvdvin...@gmail.com ]
> Sent: 15 August 2017 10:50
> To: Tomcat Users List
> Subject: 2 Way SSL integration with Webservices - Inbound connection not
> trusted
>
> Hi,
>
> Please advise on the step to resolve the issue encountered in 2way SSL
>
> Tomcat version used : apache-tomcat-8.5.15 Java Version used: jdk1.8.0_131
>
> *Problem statement: *Tomcat doesn't trust the inbound connection.
>
> We have web application deployed in tomcat and it integrated with web
> services.
> 2 way SSL is enabled.
> Webservice client deployed in Tomcat send the certificate to webservices
> and it is trusted.
> Tomcat doesn't trust certificate sent by the webservices.
> It seems to ignore the client validation and allow the communication.
>
> *step followed to implement 2 way SSL from application*
>
> We set the keystore and trust store to be used for communication. so it
> takes the cert from key store for outbound and trust the cert for inbound
> connections.
>
>System.setProperty("javax.net.ssl.trustStoreType", "JKS");
> System.setProperty("javax.net.ssl.keyStoreType", "JKS");
> System.setProperty("javax.net.ssl.trustStore","TrustStore.jks");
> System.setProperty("javax.net.ssl.keyStore","KeyStore.jks");
> System.setProperty("javax.net.ssl.trustStorePassword","changeit");
> System.setProperty("javax.net.ssl.keyStorePassword","changeit");
>
> It sends the certificate for other system to trust but it doesn't trust
> the incoming connection.
>
>
> Please advise on the configuration to trust the incoming connection.
>
>
> Thanks
> Vinoth
> Any e-mail message from the European Central Bank (ECB) is sent in good
> faith, but shall neither be binding nor construed as constituting a
> commitment by the ECB except where provided for in a written agreement.
> This e-mail is intended only for the use of the recipient(s) named above.
> Any unauthorised disclosure, use or dissemination, either in whole or in
> part, is prohibited. If you have received this e-mail in error, please
> notify the sender immediately via e-mail and delete this e-mail from your
> system. The ECB processes personal data in line with Regulation (EC) No
> 45/2001 and Decision ECB/2007/1. For any further information you can
> consult the Data Protection Disclaimer on the ECB webpage. In case of
> queries, please contact the ECB Data Protection Officer (d...@ecb.europa.eu
> ). You may also contact the European Data Protection
> Supervisor.
>

Re: Per EndPoint Threads???

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Owen,

On 8/13/17 10:46 AM, Owen Rubel wrote:
> Owen Rubel oru...@gmail.com
> 
> On Sun, Aug 13, 2017 at 5:57 AM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Owen,
> 
> On 8/12/17 12:47 PM, Owen Rubel wrote:
 What I am talking about is something that improves
 communication as we notice that communication channel needing
 more resources. Not caching what is communicated... improving
 the CHANNEL for communicating the resource (whatever it may
 be).
> 
> If the channel is an HTTP connection (or TCP; the application
> protocol isn't terribly relevant), then you are limited by the
> following:
> 
> 1. Network bandwidth 2. Available threads (to service a particular
> request) 3. Hardware resources on the server
> (CPU/memory/disk/etc.)
> 
> Let's ignore 1 and 3 for now, since you are primarily concerned
> with concurrency, and concurrency is useless if the other resources
> are constrained or otherwise limiting the equation.
> 
> Let's say we had "per endpoint" thread pools, so that e.g. /create
> had its own thread pool, and /show had another one, etc. What would
> that buy us?
> 
> (Let's ignore for now the fact that one set of threads must always
> be used to decode the request to decide where it's going, like
> /create or /show.)
> 
> If we have a limited total number of threads (e.g. 10), then we
> could "reserve" some of them so that we could always have 2 threads
> for /create even if all the other threads in the system (the other
> 8) were being used for something else. If we had 2 threads for
> /create and 2 threads for /show, then only 6 would remain for e.g.
> /edit or /delete. So if 6 threads were already being used for /edit
> or /delete, the 7th incoming request would be queued, but anyone
> making a request for /show or /create would (if a thread in those
> pools is available) be serviced immediately.
> 
> I can see some utility in this ability, because it would allow the 
> container to ensure that some resources were never starved... or, 
> rather, that they have some priority over certain other services.
> In other words, the service could enjoy guaranteed provisioning
> for certain endpoints.
> 
> As it stands, Tomcat (and, I would venture a guess, most if not
> all other containers) implements a fair request pipeline where
> requests are (at least roughly) serviced in the order in which they
> are received. Rather than guaranteeing provisioning for a
> particular endpoint, the closest thing that could be implemented
> (at the application level) would be a
> resource-availability-limiting mechanism, such as counting the
> number of in-flight requests and rejecting those which exceed some
> threshold with e.g. a 503 response.
> 
> Unfortunately, that doesn't actually prioritize some requests, it 
> merely rejects others in order to attempt to prioritize those
> others. It also starves endpoints even when there is no reason to
> do so (e.g. in the 10-thread scenario, if all 4 /show and /create
> threads are idle, but 6 requests are already in process for the
> other endpoints, a 7th request for those other endpoints will be
> rejected).
> 
> I believe that per-endpoint provisioning is a possibility, but I
> don't think that the potential gains are worth the certain
> complexity of the system required to implement it.
> 
> There are other ways to handle heterogeneous service requests in a
> way that doesn't starve one type of request in favor of another.
> One obvious solution is horizontal scaling with a load-balancer. An
> LB can be used to implement a sort of guaranteed-provisioning for
> certain endpoints by providing more back-end servers for certain
> endpoints. If you want to make sure that /show can be called by any
> client at any time, then make sure you spin-up 1000 /show servers
> and register them with the load-balancer. You can survive with only
> maybe 10 nodes servicing /delete requests; others will either wait
> in a queue or receive a 503 from the lb.
> 
> For my money, I'd maximize the number of threads available for all 
> requests (whether within a single server, or across a large
> cluster) and not require that they be available for any particular
> endpoint. Once you have to depart from a single server, you MUST
> have something like a load-balancer involved, and therefore the
> above solution becomes not only more practical but also more
> powerful.
> 
> Since relying on a one-box-wonder to run a high-availability web 
> service isn't practical, provisioning is necessarily above the 
> cluster-node level, and so the problem has effectively moved from
> the app server to the load-balancer (or reverse proxy). I believe
> the application server is an inappropriate place to implement this
> type of provisioning because it's too small-scale. The app server
> should serve requests as quickly as possible, and arranging for
> this kind of provisioning would add a level of complexity that

RE: 2 Way SSL integration with Webservices - Inbound connection not trusted

[Macca, Diego]

Hi,
You need to set clientAuth="true" in the connector or, for some reason unknown 
to me (probably something changed in Java from rel. 6/7 on), Tomcat will not 
enforce the 2 way ssl.

You can see what is going on (certificates exchange) with an ssl debug.

Kind Regards,
Diego Macca
Senior IT Specialist

DG-IS/EDA - Executional Domain Applications
EUROPEAN CENTRAL BANK
Tel.: +49 (69) 1344 6991
E-mail: diego.ma...@ecb.europa.eu
www.ecb.europa.eu
www.youtube.com/ecbeuro
https://twitter.com/ecb


-Original Message-
From: Vinoth Raja [mailto:rbvdvin...@gmail.com]
Sent: 15 August 2017 10:50
To: Tomcat Users List
Subject: 2 Way SSL integration with Webservices - Inbound connection not trusted

Hi,

Please advise on the step to resolve the issue encountered in 2way SSL

Tomcat version used : apache-tomcat-8.5.15 Java Version used: jdk1.8.0_131

*Problem statement: *Tomcat doesn't trust the inbound connection.

We have web application deployed in tomcat and it integrated with web services.
2 way SSL is enabled.
Webservice client deployed in Tomcat send the certificate to webservices and it 
is trusted.
Tomcat doesn't trust certificate sent by the webservices.
It seems to ignore the client validation and allow the communication.

*step followed to implement 2 way SSL from application*

We set the keystore and trust store to be used for communication. so it takes 
the cert from key store for outbound and trust the cert for inbound connections.

   System.setProperty("javax.net.ssl.trustStoreType", "JKS"); 
System.setProperty("javax.net.ssl.keyStoreType", "JKS"); 
System.setProperty("javax.net.ssl.trustStore","TrustStore.jks");
System.setProperty("javax.net.ssl.keyStore","KeyStore.jks");
System.setProperty("javax.net.ssl.trustStorePassword","changeit");
System.setProperty("javax.net.ssl.keyStorePassword","changeit");

It sends the certificate for other system to trust but it doesn't trust the 
incoming connection.


Please advise on the configuration to trust the incoming connection.


Thanks
Vinoth
Any e-mail message from the European Central Bank (ECB) is sent in good faith, 
but shall neither be binding nor construed as constituting a commitment by the 
ECB except where provided for in a written agreement. This e-mail is intended 
only for the use of the recipient(s) named above. Any unauthorised disclosure, 
use or dissemination, either in whole or in part, is prohibited. If you have 
received this e-mail in error, please notify the sender immediately via e-mail 
and delete this e-mail from your system. The ECB processes personal data in 
line with Regulation (EC) No 45/2001 and Decision ECB/2007/1. For any further 
information you can consult the Data Protection Disclaimer on the ECB webpage. 
In case of queries, please contact the ECB Data Protection Officer 
(d...@ecb.europa.eu). You may also contact the European Data Protection 
Supervisor.

2 Way SSL integration with Webservices - Inbound connection not trusted

[Vinoth Raja]

Hi,

Please advise on the step to resolve the issue encountered in 2way SSL

Tomcat version used : apache-tomcat-8.5.15
Java Version used: jdk1.8.0_131

*Problem statement: *Tomcat doesn't trust the inbound connection.

We have web application deployed in tomcat and it integrated with web
services.
2 way SSL is enabled.
Webservice client deployed in Tomcat send the certificate to webservices
and it is trusted.
Tomcat doesn't trust certificate sent by the webservices.
It seems to ignore the client validation and allow the communication.

*step followed to implement 2 way SSL from application*

We set the keystore and trust store to be used for communication. so it
takes the cert from key store for outbound and trust the cert for inbound
connections.

   System.setProperty("javax.net.ssl.trustStoreType", "JKS");
System.setProperty("javax.net.ssl.keyStoreType", "JKS");
System.setProperty("javax.net.ssl.trustStore","TrustStore.jks");
System.setProperty("javax.net.ssl.keyStore","KeyStore.jks");
System.setProperty("javax.net.ssl.trustStorePassword","changeit");
System.setProperty("javax.net.ssl.keyStorePassword","changeit");

It sends the certificate for other system to trust but it doesn't trust the
incoming connection.


Please advise on the configuration to trust the incoming connection.


Thanks
Vinoth