date:20150901

Ah. No, our client cert is signed by a self-signed root. But only the
client cert is in the keystore and only the client cert is registered on
the Datapower server. I can connect using the same keystore with a
standalone Java client that just opens a URL connection and input stream,
and also with SoapUI as a client. But not with our client app deployed in
Tomcat.

Regards,
Diarmuid
On 1 Sep 2015 22:23,  wrote:

> I'm referring to when a certificate is a combo such as a GoDaddy  g1_g2
> root. The intermediate is usually fine.
>
> Sent from my BlackBerry 10 smartphone on the
> Verizon Wireless 4G LTE network.
>   Original Message
> From: dmccrthy
> Sent: Tuesday, September 1, 2015 4:12 PM
> To: Tomcat Users List
> Reply To: Tomcat Users List
> Subject: RE: Tomcat 7.0.55 Not loading truststore or keystore
>
> Hi Jeff,
>
> Our client keystore has one certificate, but the truststore has multiple
> certs. I'll try removing everything from the truststore except the server
> cert and see what happens.
>
> Thanks,
> Diarmuid
> On 1 Sep 2015 19:53,  wrote:
>
> >
> > >> openssl s_client -tls1 -connect server-dns-name:15305 -CAfile
> > server-cert-with-intermediate-and-root-in-one-file.cer -cert
> > client-public-key.cer -key client-private-key.key -pass
> > pass:client-private-key-password
> >
> > I've had trouble when there are more certificate packaged in the same
> file
> > as the root certificate. If you can separate the certificates your
> problem
> > should go away.
> >
> > Jeff Crump
> >
> >
> > Sent from Mail for Windows 10
> >
> >
> >
> > From: George Stanchev
> > Sent: Tuesday, September 1, 2015 1:02 PM
> > To: Tomcat Users List
> > Subject: RE: Tomcat 7.0.55 Not loading truststore or keystore
> >
> >
> > Hi Diarmuid,
> >
> > We have run similar issue with client cert SSL. Is your 3rd party web
> > service hosted on Windows/IIS?
> >
> > George
> >
> > -Original Message-
> > From: dmccrthy [mailto:dmccr...@gmail.com]
> > Sent: Tuesday, September 01, 2015 11:07 AM
> > To: Tomcat Users List
> > Subject: Tomcat 7.0.55 Not loading truststore or keystore
> >
> > Hi All,
> >
> > I am having trouble getting Tomcat to load a truststore and keystore.
> > This seems to be a basic configuration issue but I can't figure out what
> > the problem is. Any insights would be gratefully received.
> >
> > The scenario is:
> >
> > * A 3rd party web application is deployed in Tomcat
> > * The 3rrd party web application is making outbound HTTPS connections to
> a
> > 3rd party web service
> > * Tomcat JVM parameters are configured with
> >
> > -Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks
> > -Djavax.net.ssl.trustStorePassword=
> > -Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.jks
> > -Djavax.net.ssl.keyStorePassword=
> > -Dhttps.protocols="TLSv1"
> > -Djavax.net.debug=ALL
> >
> > * Both truststore and keystore are JKS
> > * Mutual authentication is used for the SSL handshake
> > * There are no errors in the Tomcat logs to indicate a problem with the
> > truststore and keystore
> > * The Tomcat logs show the server-side certificate being downloaded but
> > not reporting the expected lines
> >
> > Found trusted certificate:
> > matching alias: 
> >
> > Or for the keystore, I am expecting to see a log that it is loading the
> > keystore (example below), but there is no sign that the keystore is being
> > loaded. I got the log extract below from a standalone java client which
> > successfully connects using MA to the remote service.
> >
> > keyStore is : c:\temp\DWCHASSMESA002.pfx
> > keyStore type is : PKCS12
> > keyStore provider is :
> > init keystore
> > init keymanager of type SunX509
> >
> > ***
> > found key for : dwchassmesa002
> > chain [0] = [
> >
> > * The Tomcat logs show that the SSL handshake gets as far as the
> > ClientKeyExchange, but there is no client certificate sent and the
> > handshake terminates with "Software caused connection abort: recv
> failed".
> > On DataPower the error is that the client is not sending the certificate.
> >
> > 
> > http-bio-8080-exec-2, READ: TLSv1 Handshake, length = 13
> > *** CertificateRequest
> > Cert Types: RSA, DSS
> > Cert Authorities:
> > 
> >
> > [read] MD5 and SHA1 hashes: len = 9
> > : 0D 00 00 05 02 01 02 00 00 .
> > *** ServerHelloDone
> > [read] MD5 and SHA1 hashes: len = 4
> > : 0E 00 00 00 
> > *** Certificate chain
> > ***
> > *** ClientKeyExchange, RSA PreMasterSecret, TLSv1 [write] MD5 and SHA1
> > hashes: len = 269
> >
> > 
> > http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 269 [Raw write]:
> > length = 274
> > : 16 03 01 01 0D 0B 00 00 03 00 00 00 10 00 01 02 
> > 
> >
> > 0110: 2E 32 .2
> > SESSION KEYGEN:
> > PreMaster Secret:
> > 
> >
> > http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 48
> > http-bio-8080-exec-2, waiting for close_notify or alert: state 1
> > http-bio-8080-exec-2, Exception while waiting for close
> > java.net.SocketException: Software

Re: Tomcat 7.0.55 Not loading truststore or keystore

Hi Chris,

Thanks for replying. This is a different 3rd party service we're connecting
to, but again it's a weird one because other tools work. I've included
responses below prefixed with [DMC].

Regards,
Diarmuid

On 1 Sep 2015 20:57, "Christopher Schultz" 
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Diarmuid,
>
> On 9/1/15 1:06 PM, dmccrthy wrote:
> > I am having trouble getting Tomcat to load a truststore and
> > keystore.  This seems to be a basic configuration issue but I can't
> > figure out what the problem is. Any insights would be gratefully
> > received.
> >
> > The scenario is:
> >
> > * A 3rd party web application is deployed in Tomcat * The 3rrd
> > party web application is making outbound HTTPS connections to a 3rd
> > party web service * Tomcat JVM parameters are configured with
> >
> > -Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks
> >
> >
> - -Djavax.net.ssl.trustStorePassword=
> > -Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.j
> ks
> >
> >
> - -Djavax.net.ssl.keyStorePassword=
>
> The above will all act as defaults for the Java-based HTTP(s) connectors
> .
>
> > -Dhttps.protocols="TLSv1"
>
> I don't believe this setting will do anything to Tomcat... at least,
> it's not documented to do so.

[DMC] Using this setting fixed our previous problem whereby outgoing HTTPS
connections from Tomcat experienced SSL handshake issues when the handshake
involved a negotiation from TLSv1.2 to TLSv1. Forcing the handshake to use
TLSv1 resolved the problem.

>
> Let's focus on the keystore to start, and then get client certs working.
>
> How many certs do you have in your keystore? Did you specify an
> "alias" for the key you'd like to use for the server?

[DMC] Just the client public/private key pair needed for the MA handshake.

>
> For my money, I'd forget the system properties and use an explicit set
> of configuration parameters on my  element. Can you post
> your  configuration?
>
> [
> Looking back at this after writing the rest of this reply: are you
> trying to host an HTTPS service *at all*?

[DMC] No, I just tried using a HTTPS connector to see if Tomcat would load
the trustore, and it did. But our scenario is for outgoing client HTTPS
connections so it doesn't help that.

If not, forget about the
> keystore entirely because it's not necessary even a little bit. Just
> in case it helps clear-up any confusion, here are when these two
> things matter:
>
> 1. keystore - useful in 2 separate circumstances:
>   a. You are setting up an HTTPS listener when you
>  have a server certificate. The server's certificate and private key
>  go into the keystore, along with any other certificates you may
>  need or in order to form a chain of trust from your CA (e.g.
>  VeriSign) down to your own key
>   b. You are making outgoing connections to an HTTPS service and you
>  need to present a client certificate to the server

[DMC] We're using scenario (b)

>
> 2. truststore - useful in 2 separate circumstances:
>   a. You have an HTTPS listener and you want to validate client
>  certificates of clients connecting TO YOU
>   b. You want to make outgoing connections to an HTTPS service
>  and YOU WANT TO VALIDATE THE SERVER'S CERTIFICATE against the
>  certs in your trust store. This allows you, for example, to
>  connect to a server with a self-signed cert, or one signed by
>  a CA that Java doesn't trust out-of-the-box
>
> You need to be very clear about what you are trying to do because it's
> about as clear as mud right now.
> ]

[DMC] Sorry for the ambiguity, we're using scenario (b), outgoing client
connections. The server cert is signed by GeoTrust but we don't have the
full CA chain in the truststore, only the server cert.

>
> > 1) Openssl connects with MA parameters connects with no errors
> >
> > openssl s_client -tls1 -connect server-dns-name:15305 -CAfile
> > server-cert-with-intermediate-and-root-in-one-file.cer -cert
> > client-public-key.cer -key client-private-key.key -pass
> > pass:client-private-key-password
> >
> > New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048
> > bit Secure Renegotiation IS supported Compression: NONE Expansion:
> > NONE No ALPN negotiated SSL-Session: Protocol  : TLSv1 Cipher:
> > AES256-SHA Session-ID:
> > 893D24420CC89DED5E8E0E18C3D97270C3DD04B7A4B86602D5B34FC5E58DDE8F
> > Session-ID-ctx: Master-Key:
> > 89ABDA0ED080567E0CB8494AC236B107B7430A5487986BE7F3B468AF81B19BC27FD9C7
> D3EBC46280B9A608E5517D447C
> >
> >
> Key-Arg   : None
> > PSK identity: None PSK identity hint: None SRP username: None Start
> > Time: 1441125595 Timeout   : 7200 (sec) Verify return code: 0 (ok)
>
> Is the other client connecting with SSL instead of TLS handshake?

[DMC] I'll have to double check, but the key thing I've been focusing on is
that the standalone Java client logs the fact that it's loading the
trustore, checking the server cert against it, and serving up the

Re: Tomcat 7.0.55 Not loading truststore or keystore

2015-09-01 Thread jeffery . scott . crump

I'm referring to when a certificate is a combo such as a GoDaddy  g1_g2 root. 
The intermediate is usually fine.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: dmccrthy
Sent: Tuesday, September 1, 2015 4:12 PM
To: Tomcat Users List
Reply To: Tomcat Users List
Subject: RE: Tomcat 7.0.55 Not loading truststore or keystore

Hi Jeff,

Our client keystore has one certificate, but the truststore has multiple
certs. I'll try removing everything from the truststore except the server
cert and see what happens.

Thanks,
Diarmuid
On 1 Sep 2015 19:53,  wrote:

>
> >> openssl s_client -tls1 -connect server-dns-name:15305 -CAfile
> server-cert-with-intermediate-and-root-in-one-file.cer -cert
> client-public-key.cer -key client-private-key.key -pass
> pass:client-private-key-password
>
> I've had trouble when there are more certificate packaged in the same file
> as the root certificate. If you can separate the certificates your problem
> should go away.
>
> Jeff Crump
>
>
> Sent from Mail for Windows 10
>
>
>
> From: George Stanchev
> Sent: Tuesday, September 1, 2015 1:02 PM
> To: Tomcat Users List
> Subject: RE: Tomcat 7.0.55 Not loading truststore or keystore
>
>
> Hi Diarmuid,
>
> We have run similar issue with client cert SSL. Is your 3rd party web
> service hosted on Windows/IIS?
>
> George
>
> -Original Message-
> From: dmccrthy [mailto:dmccr...@gmail.com]
> Sent: Tuesday, September 01, 2015 11:07 AM
> To: Tomcat Users List
> Subject: Tomcat 7.0.55 Not loading truststore or keystore
>
> Hi All,
>
> I am having trouble getting Tomcat to load a truststore and keystore.
> This seems to be a basic configuration issue but I can't figure out what
> the problem is. Any insights would be gratefully received.
>
> The scenario is:
>
> * A 3rd party web application is deployed in Tomcat
> * The 3rrd party web application is making outbound HTTPS connections to a
> 3rd party web service
> * Tomcat JVM parameters are configured with
>
> -Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks
> -Djavax.net.ssl.trustStorePassword=
> -Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.jks
> -Djavax.net.ssl.keyStorePassword=
> -Dhttps.protocols="TLSv1"
> -Djavax.net.debug=ALL
>
> * Both truststore and keystore are JKS
> * Mutual authentication is used for the SSL handshake
> * There are no errors in the Tomcat logs to indicate a problem with the
> truststore and keystore
> * The Tomcat logs show the server-side certificate being downloaded but
> not reporting the expected lines
>
> Found trusted certificate:
> matching alias: 
>
> Or for the keystore, I am expecting to see a log that it is loading the
> keystore (example below), but there is no sign that the keystore is being
> loaded. I got the log extract below from a standalone java client which
> successfully connects using MA to the remote service.
>
> keyStore is : c:\temp\DWCHASSMESA002.pfx
> keyStore type is : PKCS12
> keyStore provider is :
> init keystore
> init keymanager of type SunX509
>
> ***
> found key for : dwchassmesa002
> chain [0] = [
>
> * The Tomcat logs show that the SSL handshake gets as far as the
> ClientKeyExchange, but there is no client certificate sent and the
> handshake terminates with "Software caused connection abort: recv failed".
> On DataPower the error is that the client is not sending the certificate.
>
> 
> http-bio-8080-exec-2, READ: TLSv1 Handshake, length = 13
> *** CertificateRequest
> Cert Types: RSA, DSS
> Cert Authorities:
> 
>
> [read] MD5 and SHA1 hashes: len = 9
> : 0D 00 00 05 02 01 02 00 00 .
> *** ServerHelloDone
> [read] MD5 and SHA1 hashes: len = 4
> : 0E 00 00 00 
> *** Certificate chain
> ***
> *** ClientKeyExchange, RSA PreMasterSecret, TLSv1 [write] MD5 and SHA1
> hashes: len = 269
>
> 
> http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 269 [Raw write]:
> length = 274
> : 16 03 01 01 0D 0B 00 00 03 00 00 00 10 00 01 02 
> 
>
> 0110: 2E 32 .2
> SESSION KEYGEN:
> PreMaster Secret:
> 
>
> http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 48
> http-bio-8080-exec-2, waiting for close_notify or alert: state 1
> http-bio-8080-exec-2, Exception while waiting for close
> java.net.SocketException: Software caused connection abort: recv failed
> http-bio-8080-exec-2, handling exception: java.net.SocketException:
> Software caused connection abort: recv failed %% Invalidated:
> [Session-163, TLS_RSA_WITH_AES_128_CBC_SHA] http-bio-8080-exec-2, called
> close() http-bio-8080-exec-2, called closeInternal(true)
> http-bio-8080-exec-2, called closeSocket(
>
> We are using the software below on the client environment:
>
> * Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
> * Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> * JCE Unlimited Security: No
> * Apache Tomcat/7.0.55
> * Microsoft Windows Server 2008 R2 Enterprise 64-bit
>
> Analysis Steps
> ==
>
> 1) O

RE: Tomcat 7.0.55 Not loading truststore or keystore

Hi Jeff,

Our client keystore has one certificate, but the truststore has multiple
certs. I'll try removing  everything from the truststore except the server
cert and see what happens.

Thanks,
Diarmuid
On 1 Sep 2015 19:53,  wrote:

>
> >> openssl s_client -tls1 -connect server-dns-name:15305 -CAfile
> server-cert-with-intermediate-and-root-in-one-file.cer -cert
> client-public-key.cer -key client-private-key.key -pass
> pass:client-private-key-password
>
> I've had trouble when there are more certificate packaged in the same file
> as the root certificate. If you can separate the certificates your problem
> should go away.
>
> Jeff Crump
>
>
> Sent from Mail for Windows 10
>
>
>
> From: George Stanchev
> Sent: Tuesday, September 1, 2015 1:02 PM
> To: Tomcat Users List
> Subject: RE: Tomcat 7.0.55 Not loading truststore or keystore
>
>
> Hi Diarmuid,
>
> We have run similar issue with client cert SSL. Is your 3rd party web
> service hosted on Windows/IIS?
>
> George
>
> -Original Message-
> From: dmccrthy [mailto:dmccr...@gmail.com]
> Sent: Tuesday, September 01, 2015 11:07 AM
> To: Tomcat Users List
> Subject: Tomcat 7.0.55 Not loading truststore or keystore
>
> Hi All,
>
> I am having trouble getting Tomcat to load a truststore and keystore.
> This seems to be a basic configuration issue but I can't figure out what
> the problem is. Any insights would be gratefully received.
>
> The scenario is:
>
> * A 3rd party web application is deployed in Tomcat
> * The 3rrd party web application is making outbound HTTPS connections to a
> 3rd party web service
> * Tomcat JVM parameters are configured with
>
>-Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks
>-Djavax.net.ssl.trustStorePassword=
>-Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.jks
>-Djavax.net.ssl.keyStorePassword=
>-Dhttps.protocols="TLSv1"
>-Djavax.net.debug=ALL
>
> * Both truststore and keystore are JKS
> * Mutual authentication is used for the SSL handshake
> * There are no errors in the Tomcat logs to indicate a problem with the
> truststore and keystore
> * The Tomcat logs show the server-side certificate being downloaded but
> not reporting the expected lines
>
>   Found trusted certificate:
>   matching alias: 
>
>   Or for the keystore, I am expecting to see a log that it is loading the
> keystore (example below), but there is no sign that the keystore is being
> loaded. I got the log extract below from a standalone java client which
> successfully connects using MA to the remote service.
>
>   keyStore is : c:\temp\DWCHASSMESA002.pfx
>   keyStore type is : PKCS12
>   keyStore provider is :
>   init keystore
>   init keymanager of type SunX509
>
>   ***
>   found key for : dwchassmesa002
>   chain [0] = [
>
> * The Tomcat logs show that the SSL handshake gets as far as the
> ClientKeyExchange, but there is no client certificate sent and the
> handshake terminates with "Software caused connection abort: recv failed".
> On DataPower the error is that the client is not sending the certificate.
>
> 
> http-bio-8080-exec-2, READ: TLSv1 Handshake, length = 13
> *** CertificateRequest
> Cert Types: RSA, DSS
> Cert Authorities:
> 
>
> [read] MD5 and SHA1 hashes:  len = 9
> : 0D 00 00 05 02 01 02 00   00   .
> *** ServerHelloDone
> [read] MD5 and SHA1 hashes:  len = 4
> : 0E 00 00 00
> *** Certificate chain
> ***
> *** ClientKeyExchange, RSA PreMasterSecret, TLSv1 [write] MD5 and SHA1
> hashes:  len = 269
>
> 
> http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 269 [Raw write]:
> length = 274
> : 16 03 01 01 0D 0B 00 00   03 00 00 00 10 00 01 02  
> 
>
> 0110: 2E 32  .2
> SESSION KEYGEN:
> PreMaster Secret:
> 
>
> http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 48
> http-bio-8080-exec-2, waiting for close_notify or alert: state 1
> http-bio-8080-exec-2, Exception while waiting for close
> java.net.SocketException: Software caused connection abort: recv failed
> http-bio-8080-exec-2, handling exception: java.net.SocketException:
> Software caused connection abort: recv failed %% Invalidated:
> [Session-163, TLS_RSA_WITH_AES_128_CBC_SHA] http-bio-8080-exec-2, called
> close() http-bio-8080-exec-2, called closeInternal(true)
> http-bio-8080-exec-2, called closeSocket(
>
> We are using the software below on the client environment:
>
> * Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
> * Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> * JCE Unlimited Security: No
> * Apache Tomcat/7.0.55
> * Microsoft Windows Server 2008 R2 Enterprise 64-bit
>
> Analysis Steps
> ==
>
> 1) Openssl connects with MA parameters connects with no errors
>
> openssl s_client -tls1 -connect server-dns-name:15305 -CAfile
> server-cert-with-intermediate-and-root-in-one-file.cer -cert
> client-public-key.cer -key client-pri

RE: Tomcat 7.0.55 Not loading truststore or keystore

Hi George,

The 3rd party service is behind IBM Datapower. Datapower is reporting that
our HTTPS client connections aren't sending the client certificate as part
of the MA handshake. I'll double-check what the actual service is running
on behind that, but according to our 3rd party application team the
connections aren't getting that far.

Thanks,
Diarmuid
On 1 Sep 2015 19:03, "George Stanchev"  wrote:

> Hi Diarmuid,
>
> We have run similar issue with client cert SSL. Is your 3rd party web
> service hosted on Windows/IIS?
>
> George
>
> -Original Message-
> From: dmccrthy [mailto:dmccr...@gmail.com]
> Sent: Tuesday, September 01, 2015 11:07 AM
> To: Tomcat Users List
> Subject: Tomcat 7.0.55 Not loading truststore or keystore
>
> Hi All,
>
> I am having trouble getting Tomcat to load a truststore and keystore.
> This seems to be a basic configuration issue but I can't figure out what
> the problem is. Any insights would be gratefully received.
>
> The scenario is:
>
> * A 3rd party web application is deployed in Tomcat
> * The 3rrd party web application is making outbound HTTPS connections to a
> 3rd party web service
> * Tomcat JVM parameters are configured with
>
>-Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks
>-Djavax.net.ssl.trustStorePassword=
>-Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.jks
>-Djavax.net.ssl.keyStorePassword=
>-Dhttps.protocols="TLSv1"
>-Djavax.net.debug=ALL
>
> * Both truststore and keystore are JKS
> * Mutual authentication is used for the SSL handshake
> * There are no errors in the Tomcat logs to indicate a problem with the
> truststore and keystore
> * The Tomcat logs show the server-side certificate being downloaded but
> not reporting the expected lines
>
>   Found trusted certificate:
>   matching alias: 
>
>   Or for the keystore, I am expecting to see a log that it is loading the
> keystore (example below), but there is no sign that the keystore is being
> loaded. I got the log extract below from a standalone java client which
> successfully connects using MA to the remote service.
>
>   keyStore is : c:\temp\DWCHASSMESA002.pfx
>   keyStore type is : PKCS12
>   keyStore provider is :
>   init keystore
>   init keymanager of type SunX509
>
>   ***
>   found key for : dwchassmesa002
>   chain [0] = [
>
> * The Tomcat logs show that the SSL handshake gets as far as the
> ClientKeyExchange, but there is no client certificate sent and the
> handshake terminates with "Software caused connection abort: recv failed".
> On DataPower the error is that the client is not sending the certificate.
>
> 
> http-bio-8080-exec-2, READ: TLSv1 Handshake, length = 13
> *** CertificateRequest
> Cert Types: RSA, DSS
> Cert Authorities:
> 
>
> [read] MD5 and SHA1 hashes:  len = 9
> : 0D 00 00 05 02 01 02 00   00   .
> *** ServerHelloDone
> [read] MD5 and SHA1 hashes:  len = 4
> : 0E 00 00 00
> *** Certificate chain
> ***
> *** ClientKeyExchange, RSA PreMasterSecret, TLSv1 [write] MD5 and SHA1
> hashes:  len = 269
>
> 
> http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 269 [Raw write]:
> length = 274
> : 16 03 01 01 0D 0B 00 00   03 00 00 00 10 00 01 02  
> 
>
> 0110: 2E 32  .2
> SESSION KEYGEN:
> PreMaster Secret:
> 
>
> http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 48
> http-bio-8080-exec-2, waiting for close_notify or alert: state 1
> http-bio-8080-exec-2, Exception while waiting for close
> java.net.SocketException: Software caused connection abort: recv failed
> http-bio-8080-exec-2, handling exception: java.net.SocketException:
> Software caused connection abort: recv failed %% Invalidated:
> [Session-163, TLS_RSA_WITH_AES_128_CBC_SHA] http-bio-8080-exec-2, called
> close() http-bio-8080-exec-2, called closeInternal(true)
> http-bio-8080-exec-2, called closeSocket(
>
> We are using the software below on the client environment:
>
> * Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
> * Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> * JCE Unlimited Security: No
> * Apache Tomcat/7.0.55
> * Microsoft Windows Server 2008 R2 Enterprise 64-bit
>
> Analysis Steps
> ==
>
> 1) Openssl connects with MA parameters connects with no errors
>
> openssl s_client -tls1 -connect server-dns-name:15305 -CAfile
> server-cert-with-intermediate-and-root-in-one-file.cer -cert
> client-public-key.cer -key client-private-key.key -pass
> pass:client-private-key-password
>
> New, TLSv1/SSLv3, Cipher is AES256-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol  : TLSv1
> Cipher: AES256-SHA
> Session-ID:
> 893D24420CC89DED5E8E0E18C3D97270C3DD04B7A4B86602D5B34FC5E58DDE8F
> Session-ID-ctx:
> Master-Key:
>
> 89ABDA0ED080567E0CB8

Re: Tomcat 7.0.55 Not loading truststore or keystore

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Diarmuid,

On 9/1/15 1:06 PM, dmccrthy wrote:
> I am having trouble getting Tomcat to load a truststore and
> keystore.  This seems to be a basic configuration issue but I can't
> figure out what the problem is. Any insights would be gratefully
> received.
> 
> The scenario is:
> 
> * A 3rd party web application is deployed in Tomcat * The 3rrd
> party web application is making outbound HTTPS connections to a 3rd
> party web service * Tomcat JVM parameters are configured with
> 
> -Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks
>
> 
- -Djavax.net.ssl.trustStorePassword=
> -Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.j
ks
>
> 
- -Djavax.net.ssl.keyStorePassword=

The above will all act as defaults for the Java-based HTTP(s) connectors
.

> -Dhttps.protocols="TLSv1"

I don't believe this setting will do anything to Tomcat... at least,
it's not documented to do so.

Let's focus on the keystore to start, and then get client certs working.

How many certs do you have in your keystore? Did you specify an
"alias" for the key you'd like to use for the server?

For my money, I'd forget the system properties and use an explicit set
of configuration parameters on my  element. Can you post
your  configuration?

[
Looking back at this after writing the rest of this reply: are you
trying to host an HTTPS service *at all*? If not, forget about the
keystore entirely because it's not necessary even a little bit. Just
in case it helps clear-up any confusion, here are when these two
things matter:

1. keystore - useful in 2 separate circumstances:
  a. You are setting up an HTTPS listener when you
 have a server certificate. The server's certificate and private key
 go into the keystore, along with any other certificates you may
 need or in order to form a chain of trust from your CA (e.g.
 VeriSign) down to your own key
  b. You are making outgoing connections to an HTTPS service and you
 need to present a client certificate to the server

2. truststore - useful in 2 separate circumstances:
  a. You have an HTTPS listener and you want to validate client
 certificates of clients connecting TO YOU
  b. You want to make outgoing connections to an HTTPS service
 and YOU WANT TO VALIDATE THE SERVER'S CERTIFICATE against the
 certs in your trust store. This allows you, for example, to
 connect to a server with a self-signed cert, or one signed by
 a CA that Java doesn't trust out-of-the-box

You need to be very clear about what you are trying to do because it's
about as clear as mud right now.
]

> 1) Openssl connects with MA parameters connects with no errors
> 
> openssl s_client -tls1 -connect server-dns-name:15305 -CAfile 
> server-cert-with-intermediate-and-root-in-one-file.cer -cert 
> client-public-key.cer -key client-private-key.key -pass 
> pass:client-private-key-password
> 
> New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048
> bit Secure Renegotiation IS supported Compression: NONE Expansion:
> NONE No ALPN negotiated SSL-Session: Protocol  : TLSv1 Cipher:
> AES256-SHA Session-ID: 
> 893D24420CC89DED5E8E0E18C3D97270C3DD04B7A4B86602D5B34FC5E58DDE8F 
> Session-ID-ctx: Master-Key: 
> 89ABDA0ED080567E0CB8494AC236B107B7430A5487986BE7F3B468AF81B19BC27FD9C7
D3EBC46280B9A608E5517D447C
>
> 
Key-Arg   : None
> PSK identity: None PSK identity hint: None SRP username: None Start
> Time: 1441125595 Timeout   : 7200 (sec) Verify return code: 0 (ok)

Is the other client connecting with SSL instead of TLS handshake?

> 2) A standalone Java program with a couple of lines to open a
> HTTPS connection to the 3rd party certificate works.  This uses the
> same truststore and keystore 3) SoapUI works using the same
> truststore and keystore

SoapUI as a server or as a client? Or both?

> 4) Our 3rd party vendor can connect 5) I have googled various
> phrases like "Tomcat JVM not loading truststore".  There are
> hundreds of examples involving HTTPS connectors and/or
> configuration errors.  However we are not using server-side 
> connectors and I can't see anything wrong with the configuration.

What's a "server-side connector"?

> The only potential hit I found for a defect was in Tomcat 6 
> http://tomcat.10.x6.nabble.com/configured-truststore-ignored-by-tomcat
- -td4986884.html
>
>  6) I tried installing a HTTPS connector in our Tomcat client
> instance. This then shows that the truststore is being loaded, but
> it is not used by the outbound HTTPS client connections

How are you making an outbound client connection? Haven't we been over
this just this week? Tomcat doesn't make any outgoing connections, so
if you want to use a trust store you'll have to arrange for that trust
store to be used by whatever client connection you are making (e.g.
HttpsURLConnection, Apache hc-client, etc.).

> 7) Tried playing with the format of the file paths by adding double
> quotes, changing the path sep

Re: Tomcat 7 - Organizing web applications into sub directories

2015-09-01 Thread Srikanth Challa

Thank you Andre! Your solution was very helpful!

On Wed, Aug 26, 2015 at 10:26 AM, André Warnier  wrote:

> On 26.08.2015 06:06, Srikanth Challa wrote:
>
>> I am trying to organize my applications (multiple) into a specific
>> hierarchy under the webapps folder.
>> Something like this -
>> webapps
>>   dev
>>app1
>>app2
>>   test
>>app1
>>app3
>>
>> When deploying (without WAR), I am getting a 404 error for servlets. Tried
>> changing the web.xml servlet mapping, still no luck. It works perfectly
>> when the folder is moved directly under webapps like below -
>> webapps
>>   app1
>>
>> Does tomcat have a limitation on organizing webapps under multiple levels
>> of folders (under the webapp directory)?
>>
>>
> Hi.
> Without getting too technical :
> It is not a limitation of Tomcat.  There /are/ ways of doing what you
> indicate above.  But the problem is that if you do that, you are going
> against the "natural" way in which URLs are mapped to web-applications, and
> that will force you further down the line, to do ever more complicated
> things to keep this working correctly (for example, if you want to easily
> move an application between the "dev" and the "test" areas above).
>
> To map URLs to web-applications, Tomcat is following the basic principles
> outlined in the Servlet Specification 3.0, for example this :
>
> -- quote --
> 10.5 Directory Structure
> A Web application exists as a structured hierarchy of directories. The
> root of this
> hierarchy serves as the document root for files that are part of the
> application. For
> example, for a Web application with the context path /catalog in a Web
> container,
> the index.html file at the base of the Web application hierarchy or in a
> JAR file
> inside WEB-INF/lib that includes the index.html under META-INF/resources
> directory can be served to satisfy a request from /catalog/index.html.
> -- unquote --
>
> (re: http://tomcat.apache.org/tomcat-8.0-doc/appdev/deployment.html)
>
> For Tomcat, the "root" for all the applications within a specified ,
> is the directory which is indicated by the "appBase" attribute of the
> corresponding  tag.
> Like this :
>unpackWARs="true" autoDeploy="true">
>
> and then under "(/somepath/)webapps/" you would have something like this :
>
> (/somepath/)webapps/
>app1
>  app1-sub1
>  app1-sub2
>app2
>  app2-sub1
>  app2-sub2
> etc..
>
> This makes it clear to Tomcat that "app1" and "app2" are the distinct
> web-applications (also known as "context"), corresponding respectively to
> URLs such as :
>   http://yourhost:port/app1
>   http://yourhost:port/app2
> and that the subdirectories "app1-sub1", "app1-sub2" etc.. are internal
> sub-divisions of these "app1" and "app2" web-applications, helping to map
> longer URLs to "things" inside these application (such as servlets, JSP
> pages, HTML pages etc.) (these further sub-mappings being described in the
> web.xml file of each web-application).
>
> If you want to go against this "natural" interpretation of the directory
> structure by Tomcat, then you have to start telling Tomcat (in various
> places), that "app1/app1-sub1" is one application, and "app1/app1-sub2" is
> a different application etc.., which complicates things for you (for
> example, you'd have to name a WAR file like "app1#app1-sub1.war"). (And
> also, since it is not the "natural way", it will confuse orther people).
>
> A more practical way of achieving what you want, would probably be to
> define 2 distinct 's, like this (in server.xml) :
>
>   unpackWARs="true" autoDeploy="true">
> ...
> 
>
>   unpackWARs="true" autoDeploy="true">
> ...
> 
>
> (and of course, both "mydevhost" and "mytesthost" map to the same IP
> address (in DNS)).
>
> and then have a directory structure like this :
>
> webapps-dev/
>app1
>app2
>
> webapps-test/
>app1
>app2
>app3
>
> corresponding to URLs like :
>  http://mydevhost:port/app1  (maps to /somepath/webapps-dev/app1)
>  http://mytesthost:port/app1 (maps to /somepath/webapps-test/app1)
>  etc..
>
> This way, the internal configuration and content of "app1" can be exactly
> the same for "dev" and "test", and you can move an application between the
> 2 Hosts (or anywhwere else, such as to another machine) without having to
> make any change at all inside the application or its configuration.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
*-*
Srikanth Challa
Founder, CEO
Enterprise Atlas Inc.
srika...@enterpriseatlas.com
+1 (510) 402-6212

RE: Tomcat 7.0.55 Not loading truststore or keystore

2015-09-01 Thread jeffery.scott.crump


>> openssl s_client -tls1 -connect server-dns-name:15305 -CAfile 
>> server-cert-with-intermediate-and-root-in-one-file.cer -cert 
>> client-public-key.cer -key client-private-key.key -pass 
>> pass:client-private-key-password

I've had trouble when there are more certificate packaged in the same file as 
the root certificate. If you can separate the certificates your problem should 
go away.

Jeff Crump


Sent from Mail for Windows 10



From: George Stanchev
Sent: Tuesday, September 1, 2015 1:02 PM
To: Tomcat Users List
Subject: RE: Tomcat 7.0.55 Not loading truststore or keystore


Hi Diarmuid,

We have run similar issue with client cert SSL. Is your 3rd party web service 
hosted on Windows/IIS?

George

-Original Message-
From: dmccrthy [mailto:dmccr...@gmail.com]
Sent: Tuesday, September 01, 2015 11:07 AM
To: Tomcat Users List
Subject: Tomcat 7.0.55 Not loading truststore or keystore

Hi All,

I am having trouble getting Tomcat to load a truststore and keystore.  This 
seems to be a basic configuration issue but I can't figure out what the problem 
is. Any insights would be gratefully received.

The scenario is:

* A 3rd party web application is deployed in Tomcat
* The 3rrd party web application is making outbound HTTPS connections to a 3rd 
party web service
* Tomcat JVM parameters are configured with

   -Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks
   -Djavax.net.ssl.trustStorePassword=
   -Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.jks
   -Djavax.net.ssl.keyStorePassword=
   -Dhttps.protocols="TLSv1"
   -Djavax.net.debug=ALL

* Both truststore and keystore are JKS
* Mutual authentication is used for the SSL handshake
* There are no errors in the Tomcat logs to indicate a problem with the 
truststore and keystore
* The Tomcat logs show the server-side certificate being downloaded but not 
reporting the expected lines

  Found trusted certificate:
  matching alias: 

  Or for the keystore, I am expecting to see a log that it is loading the 
keystore (example below), but there is no sign that the keystore is being 
loaded. I got the log extract below from a standalone java client which 
successfully connects using MA to the remote service.

  keyStore is : c:\temp\DWCHASSMESA002.pfx
  keyStore type is : PKCS12
  keyStore provider is :
  init keystore
  init keymanager of type SunX509

  ***
  found key for : dwchassmesa002
  chain [0] = [

* The Tomcat logs show that the SSL handshake gets as far as the 
ClientKeyExchange, but there is no client certificate sent and the handshake 
terminates with "Software caused connection abort: recv failed".
On DataPower the error is that the client is not sending the certificate.


http-bio-8080-exec-2, READ: TLSv1 Handshake, length = 13
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:


[read] MD5 and SHA1 hashes:  len = 9
: 0D 00 00 05 02 01 02 00   00   .
*** ServerHelloDone
[read] MD5 and SHA1 hashes:  len = 4
: 0E 00 00 00
*** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1 [write] MD5 and SHA1 hashes:  
len = 269


http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 269 [Raw write]: length 
= 274
: 16 03 01 01 0D 0B 00 00   03 00 00 00 10 00 01 02  


0110: 2E 32  .2
SESSION KEYGEN:
PreMaster Secret:


http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 48 http-bio-8080-exec-2, 
waiting for close_notify or alert: state 1 http-bio-8080-exec-2, Exception 
while waiting for close
java.net.SocketException: Software caused connection abort: recv failed 
http-bio-8080-exec-2, handling exception: java.net.SocketException:
Software caused connection abort: recv failed %% Invalidated:  [Session-163, 
TLS_RSA_WITH_AES_128_CBC_SHA] http-bio-8080-exec-2, called close() 
http-bio-8080-exec-2, called closeInternal(true) http-bio-8080-exec-2, called 
closeSocket(

We are using the software below on the client environment:

* Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
* Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
* JCE Unlimited Security: No
* Apache Tomcat/7.0.55
* Microsoft Windows Server 2008 R2 Enterprise 64-bit

Analysis Steps
==

1) Openssl connects with MA parameters connects with no errors

openssl s_client -tls1 -connect server-dns-name:15305 -CAfile 
server-cert-with-intermediate-and-root-in-one-file.cer -cert 
client-public-key.cer -key client-private-key.key -pass 
pass:client-private-key-password

New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1
Cipher: AES256-SHA
Session-ID:
893D24420CC89DED5E8E0E18C3D97270C3DD04B7A4B86602D5B34FC5E58DDE8F
Session-ID-ctx:
Master-Key:
89ABDA0ED080567E0CB8494AC236B107B7430A5487986BE7F3B46

RE: Tomcat 7.0.55 Not loading truststore or keystore

2015-09-01 Thread George Stanchev

Hi Diarmuid,

We have run similar issue with client cert SSL. Is your 3rd party web service 
hosted on Windows/IIS? 

George

-Original Message-
From: dmccrthy [mailto:dmccr...@gmail.com] 
Sent: Tuesday, September 01, 2015 11:07 AM
To: Tomcat Users List
Subject: Tomcat 7.0.55 Not loading truststore or keystore

Hi All,

I am having trouble getting Tomcat to load a truststore and keystore.  This 
seems to be a basic configuration issue but I can't figure out what the problem 
is. Any insights would be gratefully received.

The scenario is:

* A 3rd party web application is deployed in Tomcat
* The 3rrd party web application is making outbound HTTPS connections to a 3rd 
party web service
* Tomcat JVM parameters are configured with

   -Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks
   -Djavax.net.ssl.trustStorePassword=
   -Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.jks
   -Djavax.net.ssl.keyStorePassword=
   -Dhttps.protocols="TLSv1"
   -Djavax.net.debug=ALL

* Both truststore and keystore are JKS
* Mutual authentication is used for the SSL handshake
* There are no errors in the Tomcat logs to indicate a problem with the 
truststore and keystore
* The Tomcat logs show the server-side certificate being downloaded but not 
reporting the expected lines

  Found trusted certificate:
  matching alias: 

  Or for the keystore, I am expecting to see a log that it is loading the 
keystore (example below), but there is no sign that the keystore is being 
loaded. I got the log extract below from a standalone java client which 
successfully connects using MA to the remote service.

  keyStore is : c:\temp\DWCHASSMESA002.pfx
  keyStore type is : PKCS12
  keyStore provider is :
  init keystore
  init keymanager of type SunX509

  ***
  found key for : dwchassmesa002
  chain [0] = [

* The Tomcat logs show that the SSL handshake gets as far as the 
ClientKeyExchange, but there is no client certificate sent and the handshake 
terminates with "Software caused connection abort: recv failed".
On DataPower the error is that the client is not sending the certificate.


http-bio-8080-exec-2, READ: TLSv1 Handshake, length = 13
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:


[read] MD5 and SHA1 hashes:  len = 9
: 0D 00 00 05 02 01 02 00   00   .
*** ServerHelloDone
[read] MD5 and SHA1 hashes:  len = 4
: 0E 00 00 00
*** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1 [write] MD5 and SHA1 hashes:  
len = 269


http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 269 [Raw write]: length 
= 274
: 16 03 01 01 0D 0B 00 00   03 00 00 00 10 00 01 02  


0110: 2E 32  .2
SESSION KEYGEN:
PreMaster Secret:


http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 48 http-bio-8080-exec-2, 
waiting for close_notify or alert: state 1 http-bio-8080-exec-2, Exception 
while waiting for close
java.net.SocketException: Software caused connection abort: recv failed 
http-bio-8080-exec-2, handling exception: java.net.SocketException:
Software caused connection abort: recv failed %% Invalidated:  [Session-163, 
TLS_RSA_WITH_AES_128_CBC_SHA] http-bio-8080-exec-2, called close() 
http-bio-8080-exec-2, called closeInternal(true) http-bio-8080-exec-2, called 
closeSocket(

We are using the software below on the client environment:

* Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
* Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
* JCE Unlimited Security: No
* Apache Tomcat/7.0.55
* Microsoft Windows Server 2008 R2 Enterprise 64-bit

Analysis Steps
==

1) Openssl connects with MA parameters connects with no errors

openssl s_client -tls1 -connect server-dns-name:15305 -CAfile 
server-cert-with-intermediate-and-root-in-one-file.cer -cert 
client-public-key.cer -key client-private-key.key -pass 
pass:client-private-key-password

New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1
Cipher: AES256-SHA
Session-ID:
893D24420CC89DED5E8E0E18C3D97270C3DD04B7A4B86602D5B34FC5E58DDE8F
Session-ID-ctx:
Master-Key:
89ABDA0ED080567E0CB8494AC236B107B7430A5487986BE7F3B468AF81B19BC27FD9C7D3EBC46280B9A608E5517D447C
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1441125595
   Timeout   : 7200 (sec)
Verify return code: 0 (ok)

2) A standalone Java program with a couple of lines to open a HTTPS connection 
to the 3rd party certificate works.  This uses the same truststore and keystore
3) SoapUI works using the same truststore and keystore
4) Our 3rd party vendor can connect
5) I have googled various phrases like "Tomcat JVM not loading truststore".  
There are hundreds of examples involvi

Tomcat 7.0.55 Not loading truststore or keystore

Hi All,

I am having trouble getting Tomcat to load a truststore and keystore.  This
seems to be a basic configuration issue but I can't figure out what the
problem is. Any insights would be gratefully received.

The scenario is:

* A 3rd party web application is deployed in Tomcat
* The 3rrd party web application is making outbound HTTPS connections to a
3rd party web service
* Tomcat JVM parameters are configured with

   -Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks
   -Djavax.net.ssl.trustStorePassword=
   -Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.jks
   -Djavax.net.ssl.keyStorePassword=
   -Dhttps.protocols="TLSv1"
   -Djavax.net.debug=ALL

* Both truststore and keystore are JKS
* Mutual authentication is used for the SSL handshake
* There are no errors in the Tomcat logs to indicate a problem with the
truststore and keystore
* The Tomcat logs show the server-side certificate being downloaded but not
reporting the expected lines

  Found trusted certificate:
  matching alias: 

  Or for the keystore, I am expecting to see a log that it is loading the
keystore (example below), but there is no sign that the keystore is being
loaded. I got the log extract below from a standalone java client which
successfully connects using MA to the remote service.

  keyStore is : c:\temp\DWCHASSMESA002.pfx
  keyStore type is : PKCS12
  keyStore provider is :
  init keystore
  init keymanager of type SunX509

  ***
  found key for : dwchassmesa002
  chain [0] = [

* The Tomcat logs show that the SSL handshake gets as far as the
ClientKeyExchange, but there is no client certificate sent and the
handshake terminates with "Software caused connection abort: recv failed".
On DataPower the error is that the client is not sending the certificate.


http-bio-8080-exec-2, READ: TLSv1 Handshake, length = 13
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:


[read] MD5 and SHA1 hashes:  len = 9
: 0D 00 00 05 02 01 02 00   00   .
*** ServerHelloDone
[read] MD5 and SHA1 hashes:  len = 4
: 0E 00 00 00
*** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
[write] MD5 and SHA1 hashes:  len = 269


http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 269
[Raw write]: length = 274
: 16 03 01 01 0D 0B 00 00   03 00 00 00 10 00 01 02  


0110: 2E 32  .2
SESSION KEYGEN:
PreMaster Secret:


http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 48
http-bio-8080-exec-2, waiting for close_notify or alert: state 1
http-bio-8080-exec-2, Exception while waiting for close
java.net.SocketException: Software caused connection abort: recv failed
http-bio-8080-exec-2, handling exception: java.net.SocketException:
Software caused connection abort: recv failed
%% Invalidated:  [Session-163, TLS_RSA_WITH_AES_128_CBC_SHA]
http-bio-8080-exec-2, called close()
http-bio-8080-exec-2, called closeInternal(true)
http-bio-8080-exec-2, called closeSocket(

We are using the software below on the client environment:

* Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
* Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
* JCE Unlimited Security: No
* Apache Tomcat/7.0.55
* Microsoft Windows Server 2008 R2 Enterprise 64-bit

Analysis Steps
==

1) Openssl connects with MA parameters connects with no errors

openssl s_client -tls1 -connect server-dns-name:15305 -CAfile
server-cert-with-intermediate-and-root-in-one-file.cer -cert
client-public-key.cer -key client-private-key.key -pass
pass:client-private-key-password

New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1
Cipher: AES256-SHA
Session-ID:
893D24420CC89DED5E8E0E18C3D97270C3DD04B7A4B86602D5B34FC5E58DDE8F
Session-ID-ctx:
Master-Key:
89ABDA0ED080567E0CB8494AC236B107B7430A5487986BE7F3B468AF81B19BC27FD9C7D3EBC46280B9A608E5517D447C
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1441125595
   Timeout   : 7200 (sec)
Verify return code: 0 (ok)

2) A standalone Java program with a couple of lines to open a HTTPS
connection to the 3rd party certificate works.  This uses the same
truststore and keystore
3) SoapUI works using the same truststore and keystore
4) Our 3rd party vendor can connect
5) I have googled various phrases like "Tomcat JVM not loading
truststore".  There are hundreds of examples involving HTTPS connectors
and/or configuration errors.  However we are not using server-side
connectors and I can't see anything wrong with the configuration.  The only
potential hit I found for a defect was in Tomcat 6
http://tomcat.10.x6.nabble.com/configured-truststore-ignored-by-tomcat-td4986884.html

6) I tried installing a HTTPS connector in

Re: Tomcat 8 Session Timeout

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Theo,

On 9/1/15 4:29 AM, theo.swe...@avios.com wrote:
> Mark - I took a look at the Manager How To Guide  as seen here -
> 
> https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Expire_Ses
sions
>
>  It mentions that it's possible to expire sessions for each
> individual app using a command similar to -
> 
> curl -X GET 
> http://username:password@localhost:8080/manager/text/expire?path=/exam
ples&idle=0
>
>  Do you know if a wildcard can be used for the app name?

You can't.

If you want to script it, you can write some code to pull the list of
sessions and then interrogate them for various things. I'm not sure
what the manager application's interface is willing to cough-up, but
if you use JMX (either directly or via the manager's JMXProxyServlet),
you can list the sessions, look at their attributes, and expire them
using whatever criteria you want.

Check out slide 40 in this presentation from ApacheCon NA 2015:
http://events.linuxfoundation.org/sites/events/files/slides/Monitoring%2
0Apache%20Tomcat%20with%20JMX_0.pdf

This trick requires that you have an attribute in the session called
"user" that has the user's username in the toString() output. It's
just an example, but you can see how you can grab sessions and do
things with them.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5dDTAAoJEBzwKT+lPKRYRIUQAIuCucb4uj6o9uyr6CD/N+Yh
9NDAedOdxygaR14+uy8vHPB/V60O65bURSArFt65oNIB0U0YIA5A7/dpp+8NNWLE
O31mJu9GPLb5X1RdArRV8esiI23QRkZWNtEuNPn1pVcVwMMmfym+NzX1N1Ng9Sdu
Tkkom3GKf4MXujl4UqqiGEgy1nnSvmRUUoRAdGRsEWamz5GgfjFT6TIhmy+RBDxy
Doh4iRxDNO9g0yMHL/SWxOssEh+unJCcFKEJEo2nsRkh4MjsOkmVlyzWHiXkC/IZ
P+815UQjxgwPX+xQq2U3ptghj+SS3MJGKm2HuihF/ia+0xT7+0V0l1Oo8+H7y4Br
4Jf9FO9hfan9W0pnqi9U0tg3Ojthl8m1Q9nucU+v6CbGYUU5RExqaJBATU46wuda
PvDCP8MkVmYGGPNnUDDi9RIw9dggKC/FPm//iLLSBeHKZMfN1PXBViQOZVbj3X84
Dc1RU7c7F1OfuXCcAb2koQJjDGmgxr7KF8mPtNdzq+dSUeVDn1L2JZziXJ6MICVp
xrlslFSZ7iCUgpuc1+/FX99jG+CvxBj4v+LDgMlw1VEkqxeqg7V5HO5T4KhdHXZ2
IjjlUMsEUtsmIrF00EXyW/gXGyl15Nzn6ULEPFwnm4nUf0vEUVoWyjdBsXWaAo5O
N8okIJvNcDxwaQWBWm7w
=epgx
-END PGP SIGNATURE-

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

Re: HTTP 400 with Form based authentication

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 8/31/15 3:20 PM, Sreyan Chakravarty wrote:
> Ok I found FormAuthenticator and landingPage attribute in it in the
> source.

You shouldn't need to look at the source.

> But how do I use that in my application ? What do I do ?

You configure the FormAuthenticationValve in your application's
META-INF/context.xml file.
http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Introduction

The intro says you can configure any Valve in any of the following
"Catalina container[s] (Engine, Host, or Context)." Just make it a new
child of the  element you should already have.

> Any documentation for this ?

Just what you have already read:


  


- -chris

> On Tue, Sep 1, 2015 at 12:46 AM, Sreyan Chakravarty < 
> sreyan.mail...@gmail.com> wrote:
> 
>> Well Christopher thanks for that eye opener. I didn't know that
>> the specs were so inconsistent.
>> 
>> Okay now regarding your comment-:
>> 
>> "Servlet 3.0 added the HttpServletRequest.login() method would
>> improved the situation greatly: you can implement your own login
>> handler that plugs-into the authentication services of the
>> container. It's just that the container doesn't handle any
>> redirection to a login page (none is required) or credential
>> capturing (easily done with a servlet)."
>> 
>> How do you implement your own login handler and how do you plug
>> that into Tomcat Auth services. Can you provide some info as to
>> how I would do that ?
>> 
>> And what is the extension to FORM Authenticator that Mark is
>> talking about ?
>> 
>> Also correct me if I am wrong, then the page that I use to login
>> and the page that will contain j_security_check as an action must
>> be two different pages.
>> 
>> Also can I have two  elements in my web.xml ?
>> 
>> On Mon, Aug 31, 2015 at 11:19 PM, Christopher Schultz < 
>> ch...@christopherschultz.net> wrote:
>> 
> Sreyan,
> 
> On 8/31/15 1:39 PM, Sreyan Chakravarty wrote:
> First of all I did read the Servlet Spec, it provided no
> hint as to what I was doing wrong.
> 
> So you are saying that I can't have a login form on the
> page when the welcome page ? Why not ? Tons of site have
> just that, like Twitter and Facebook. It seems weird why I
> can't have it on my welcome page.
> 
> Oh, you can do it, but you'll have to implement it yourself. Go 
> re-read the spec's section on how FORM authentication works. Note
> that you are required to attempt to access a protected page before
> being asked for authentication. I think it's a big hole in the spec
> that should be filled, but anything Tomcat would do for you here
> is, by definition, out-of-spec.
> 
> And wait a minute. You are telling me that I have to first
> point my web browser to /teacher/success.jsp and then when
> I get the login page and login  ?
> 
> Yes.
> 
> What can't I do the following-:
> 
> First login from the login page and then go to
> success.jsp?
> 
> You sure can do that, but you can't use j_security_check as
> yourPOST target. Instead, you have to write your own Servlet and
> then (probably) call HttpServletRequest.login() from there, then
> redirect the user to wherever you want them to go.
> 
> Why do I have to first hit an auth error and then be
> redirected back to login and then provide my user/pass
> combo ?
> 
> This is spec-defined behavior.
> 
> So how do you code a login module ? Where I can login first
> and then go to my resources ?
> 
> What's a "login module"?
> 
> This is indeed weird.
> 
> It's a (giant, gaping) hole in the spec. Inconvenient, maybe. But 
> certainly not weird.
> 
> Servlet 3.0 added the HttpServletRequest.login() method would
> improved the situation greatly: you can implement your own login
> handler that plugs-into the authentication services of the
> container. It's just that the container doesn't handle any
> redirection to a login page (none is required) or credential
> capturing (easily done with a servlet).
> 
> Really the only thing the servlet spec is missing is a setting in 
>  like  or something like that,
> so that if you try to login with j_security_check and you hadn't
> already requested a protected resource, the container knows where
> to send the user after authentication.
> 
> -chris
>>> 
>>> 
- -
>>>
>>> 
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

iQIcBAEBCAAGBQJV5c7LAAoJEBzwKT+lPKRYBkoP/RCzs3LjRGedna+GYX1KP7nD
eeQseNjfe+nCC9w0hkUUklTxA7ikC92IJHxfoBNKOwjEzIBBrT1stoR1rwUAjMRp
dBZ44EjxybDYHQgCJkLdFQXD0q3+SH4kYDguVNJNSl8vpYQ4ehTj7RDV0mlf7USz
rLgwZ/4WZh/QU3VMf0R+xYbnz/nkbzAMiIn9ZGMa/R26tBWT1AEWbP7ntGw6qFgM
i4FhElMb21cJYSrU6eAvTvJpJR97ziBnCLauZxBmfiioIH09iutXqrG8F/q3Ou42
9mBEPCqYTwj6ZznSX5nXbujllNTdtSJNfZUfuCLR

Re: HTTP 400 with Form based authentication

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 8/31/15 3:16 PM, Sreyan Chakravarty wrote:
> Well Christopher thanks for that eye opener. I didn't know that the
> specs were so inconsistent.

They aren't inconsistent... it's just that they don't cover a popular
use case. Remember that container-managed authentication has to cover
 types of authentication other than "FORM".

The client can't, for instance, force HTTP Basic credentials into a
server without knowing what the server's "realm" is for HTTP Basic.
The server won't ask for authentication unless it's necessary, and
authentication isn't necessary unless the user tries to access a
protected resource.

The same is true for SSL client certificates. When you consider all
the types of authentication that the servlet spec covers, it makes
more sense why the authentication is done the way it is. (It doesn't
make it any less irritating, though.)

> Okay now regarding your comment-:
> 
> "Servlet 3.0 added the HttpServletRequest.login() method would
> improved the situation greatly: you can implement your own login
> handler that plugs-into the authentication services of the
> container. It's just that the container doesn't handle any
> redirection to a login page (none is required) or credential
> capturing (easily done with a servlet)."

(Note that the word "would" should have been "which has" above.)

> How do you implement your own login handler and how do you plug
> that into Tomcat Auth services.
> 
> Can you provide some info as to how I would do that ?

You write your own servlet and point your "main" login at it:

public class MyLoginServlet extends HttpServlet {
  public void doPost(HttpServletRequest req, HttpServletResponse rsp) {
request.login(req.getParameter("username"),
  req.getParameter("password"));
  }
}

It's up to you to decide what else should happen after authentication
succeeds. This hooks-into the container's authentication system by
using whatever Realm has been defined to actually do the
authentication (e.g. DataSourceRealm) and will also use the
CredentialHandlers we've been discussing.

> And what is the extension to FORM Authenticator that Mark is
> talking about ?

Check out the documentation for the FORM Authenticator and you'll see
that you don't actually need to write your own servlet like the above
if all you want to do is allow drive-by logins and always forward to
the same URI:

http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Form_Authentic
ator_Valve

Unfortunately, that feature is buried in the configuration reference
for the FormAuthenticatorValve and not somewhere more easily
accessible like under "Realms and AAA" for example.

> Also correct me if I am wrong, then the page that I use to login
> and the page that will contain j_security_check as an action must
> be two different pages.

If you use the form/servlet I outlined above, then yes: your "main"
login page should be separate from the one you use for Tomcat's
automated authentication. Of course, you can page a single
parameterized page or a complex series of JSPs that include each other
to avoid duplication, or you can just make two pages.

If you use Mark's technique to configure the FormAuthenticationValve,
then you can use a single form for everything. I would highly
recommend simply using the FormAuthenticationValve configuration
because you have to do a whole lot less work.

> Also can I have two  elements in my web.xml ?

Nope. How would the container know when to pick one over the other?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5c4wAAoJEBzwKT+lPKRYX08QAJKuEE9N2ifMuZp2uOtXNkDz
VNPZBnZonXfqI/MKjYlhn2ox9IHpTOZ6sYVGaMgBKYV4ILHPN4kOvSHi3ud/azDh
igSpSEYJ52vcK1EAoYgr1f56hyUjSTZhxbQlNuf0cIfyF/nNLUB/fz9x5VMDUPEY
s8KH3UZ62OR5UI6rcwWE/QfnyneHyWoDqp0s831DxMRkH90XdzGGHn4xaICUK68f
fdZPJmQslgm6rdyh/MuVA/NVS9IGADEF4hlD7TbyGhl8sOupSv51pjivl594hjhX
znYT/wE8iO+sNft2oPb9A5LUWDS2le9dfA4S0zrA9TVsWFQvnUOs3dNkgEIW7aYO
fba0F9wUqRY0hUfoqiQ+mvCaBQP8a6P2YDy9P9PnShwxOTo6grd8UAXGYvsxyaae
D/TZkak1mSkYT/7HQ14OwXhDjtK00GflQ3I+p/qYAO7xCxeWJvfcxWp7y19Zc+8B
Zc3Vz+NQhneJHeltp6V0xK2xfamGrFCrpcuDMIpyu3Szi/15shpJaPTYWAuam8Pk
4Ld8OC0MCB5C7mgu58bJuKm54cr2GJgBlcgsfG6XwUkn3oeCAZDFBuqNoR7YMyQ6
e8gzUYvAwpb1IsNO1mELJIUKY8N+NDCdNnvjQ05X3rUsBhPS0tg6b3USdvs+TDIG
vb/DhPr4hguee6nFoX7Y
=iT9j
-END PGP SIGNATURE-

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

Re: Blank page when browsing to Tomcat page

On 01/09/2015 10:20, Nikitha Benny wrote:



> 1.) *So the question is, during a default Tomcat install, where is it
> defined that which dirs Tomcat scans* ?

That is not defined during installation.

It is controlled by the JarScanner component:
http://tomcat.apache.org/tomcat-8.0-doc/config/jar-scanner.html

> It should not scan the /cfmu/appcm dir

It should, if that directory has been placed on the web application
class path.

> 2.) *Can you give me a clue why this dir is scanned, and how this can be
> changed*?

It has been added to the web application class path.

Note: Tomcat constructs the web application class as per the docs:
http://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html


Mark


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

Blank page when browsing to Tomcat page

2015-09-01 Thread Nikitha Benny

Hi All,

Tomcat stopped working (blank page when browsing to the website using
firefox).

Checking in the catalina.2015-04-21.log on one of the problematic servers,
following messages were seen :

*Apr 21, 2015 11:35:11 AM org.apache.catalina.startup.TldConfig tldScanJar*
*WARNING: Failed to process JAR
[jar:file:/cfmu/appcm/CFMU/CFMU_CONFIG!19.0.0.84/build_G!88.IP.L5/java/jar/ito_op_addon.jar!/
] for TLD
files*
*java.util.zip.ZipException: zip file is empty*
*…*
*Apr 21, 2015 11:35:11 AM org.apache.catalina.core.StandardContext
startInternal*
*SEVERE: Context [/docs] startup failed due to previous errors*

The file on which it gives a warning exists and indeed empty.
# file /cfmu/appcm/CFMU/CFMU_CONFIG\!
19.0.0.84/build_G\!88.IP.L5/java/jar/ito_op_addon.jar
/cfmu/appcm/CFMU/CFMU_CONFIG!
19.0.0.84/build_G!88.IP.L5/java/jar/ito_op_addon.jar: empty

It’s clear that tomcat should NOT scan /cfmu/appcm.

It looks like, once we add the following line into context.xml that it
works again :
**

Now the question. *Why would Tomcat scan the /cfmu/appcm dir *?

We checked the classpath setting on the server, but CLASSPATH env variable
isn't set system-wide.
.
Besides that there is no reference to cfmu in the
/opt/OV/nonOV/tomcat/b/conf /catalina.properties file.

The dir /cfmu/appcm is a dir coming from our internal tools to keep track
of software version releases. It has nothing to do with Apache.

1.) *So the question is, during a default Tomcat install, where is it
defined that which dirs Tomcat scans* ?
It should not scan the /cfmu/appcm dir

2.) *Can you give me a clue why this dir is scanned, and how this can be
changed*?

Waiting for your reply.

Thanks & Regards,
Nikitha

Re: Tomcat 8 Session Timeout

On 01/09/2015 09:29, theo.swe...@avios.com wrote:
> Mark - I took a look at the Manager How To Guide  as seen here - 
> 
> https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Expire_Sessions
> 
> It mentions that it's possible to expire sessions for each individual app 
> using a command similar to - 
> 
> curl -X GET 
> http://username:password@localhost:8080/manager/text/expire?path=/examples&idle=0
> 
> Do you know if a wildcard can be used for the app name?

Sorry, it won't.

Mark


> 
> Theo
> 
> 
> 
> 
> From:   Mark Thomas 
> To: Tomcat Users List , 
> Date:   01/09/2015 09:02
> Subject:Re: Tomcat 8 Session Timeout
> 
> 
> 
> On 01/09/2015 08:53, theo.swe...@avios.com wrote:
>> Hi Mark 
>>
>> Tomcat version?
>>
>> v8.0.21
> 
> OK. Fairly recent and no known issues. I'll add session expiration is
> testing as part of the 'unit' tests we run after every commit and I
> don't ever remember it failing. The same tests are also run before every
> release and must pass on multiple platforms before the release is started.
> 
>> The usual causes are:
>>  - something unexpected accessing the session
>>  - the background processing thread is crashed / busy doing something
>>else
>>
>> Is there a command line mechanism to gracefully terminate sessions?
> 
> No, but you can use the Manager app to view session contents and expire
> the sessions.
> 
> Mark
> 
>>
>> Theo
>>
>>
>>
>>
>> From:   Mark Thomas 
>> To: Tomcat Users List , 
>> Date:   28/08/2015 19:13
>> Subject:Re: Tomcat 8 Session Timeout
>>
>>
>>
>> On 28/08/2015 12:08, theo.swe...@avios.com wrote:
>>> Hello - currently HTTP sessions are configured to timeout after 120 
>>> seconds, in $CATALINA_BASE/conf/web.xml
>>>
>>>
>>> 2
>>> 
>>>
>>> However this is not being honoured by the web services, where many 
>> session 
>>> are lasting longer.
>>>
>>> From what I understand - the order for session timeouts is - 
>>>
>>> HttpSession.setMaxInactiveInterval(int) 
>>> $WebApplication/webapp/WEB-INF/web.xml 
>>> $TOMCAT_BASE/conf/web.xml
>>>
>>> Is there something that I'm missing?
>>
>> Tomcat version?
>>
>> The usual causes are:
>>  - something unexpected accessing the session
>>  - the background processing thread is crashed / busy doing something
>>else
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> -
>> The Mileage Company Limited is a limited company registered in England 
> under company number 2260073 whose registered office address is at
>> Astral Towers, Betts Way, London Road, Crawley, West Sussex, RH10 9XY.
>>
>> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
>> are addressed. If you have received this email in error please notify 
> the system manager.
>>
>> This footnote also confirms that this email message has been swept by 
> Mimecast for the presence of computer viruses. 
>>
> -
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> -
> The Mileage Company Limited is a limited company registered in England under 
> company number 2260073 whose registered office address is at
> Astral Towers, Betts Way, London Road, Crawley, West Sussex, RH10 9XY.
> 
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify the 
> system manager.
> 
> This footnote also confirms that this email message has been swept by 
> Mimecast for the presence of computer viruses. 
> -
> 


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

Re: Tomcat 8 Session Timeout

2015-09-01 Thread Theo . Sweeny

Mark - I took a look at the Manager How To Guide  as seen here - 

https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Expire_Sessions

It mentions that it's possible to expire sessions for each individual app 
using a command similar to - 

curl -X GET 
http://username:password@localhost:8080/manager/text/expire?path=/examples&idle=0

Do you know if a wildcard can be used for the app name? 

Theo




From:   Mark Thomas 
To: Tomcat Users List , 
Date:   01/09/2015 09:02
Subject:Re: Tomcat 8 Session Timeout



On 01/09/2015 08:53, theo.swe...@avios.com wrote:
> Hi Mark 
> 
> Tomcat version?
> 
> v8.0.21

OK. Fairly recent and no known issues. I'll add session expiration is
testing as part of the 'unit' tests we run after every commit and I
don't ever remember it failing. The same tests are also run before every
release and must pass on multiple platforms before the release is started.

> The usual causes are:
>  - something unexpected accessing the session
>  - the background processing thread is crashed / busy doing something
>else
> 
> Is there a command line mechanism to gracefully terminate sessions?

No, but you can use the Manager app to view session contents and expire
the sessions.

Mark

> 
> Theo
> 
> 
> 
> 
> From:   Mark Thomas 
> To: Tomcat Users List , 
> Date:   28/08/2015 19:13
> Subject:Re: Tomcat 8 Session Timeout
> 
> 
> 
> On 28/08/2015 12:08, theo.swe...@avios.com wrote:
>> Hello - currently HTTP sessions are configured to timeout after 120 
>> seconds, in $CATALINA_BASE/conf/web.xml
>>
>>
>> 2
>> 
>>
>> However this is not being honoured by the web services, where many 
> session 
>> are lasting longer.
>>
>> From what I understand - the order for session timeouts is - 
>>
>> HttpSession.setMaxInactiveInterval(int) 
>> $WebApplication/webapp/WEB-INF/web.xml 
>> $TOMCAT_BASE/conf/web.xml
>>
>> Is there something that I'm missing?
> 
> Tomcat version?
> 
> The usual causes are:
>  - something unexpected accessing the session
>  - the background processing thread is crashed / busy doing something
>else
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
-
> The Mileage Company Limited is a limited company registered in England 
under company number 2260073 whose registered office address is at
> Astral Towers, Betts Way, London Road, Crawley, West Sussex, RH10 9XY.
> 
> This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify 
the system manager.
> 
> This footnote also confirms that this email message has been swept by 
Mimecast for the presence of computer viruses. 
> 
-
> 


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

-
The Mileage Company Limited is a limited company registered in England under 
company number 2260073 whose registered office address is at
Astral Towers, Betts Way, London Road, Crawley, West Sussex, RH10 9XY.

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the 
system manager.

This footnote also confirms that this email message has been swept by Mimecast 
for the presence of computer viruses. 
-

Re: Tomcat 8 Session Timeout

On 01/09/2015 08:53, theo.swe...@avios.com wrote:
> Hi Mark 
> 
> Tomcat version?
> 
> v8.0.21

OK. Fairly recent and no known issues. I'll add session expiration is
testing as part of the 'unit' tests we run after every commit and I
don't ever remember it failing. The same tests are also run before every
release and must pass on multiple platforms before the release is started.

> The usual causes are:
>  - something unexpected accessing the session
>  - the background processing thread is crashed / busy doing something
>else
> 
> Is there a command line mechanism to gracefully terminate sessions?

No, but you can use the Manager app to view session contents and expire
the sessions.

Mark

> 
> Theo
> 
> 
> 
> 
> From:   Mark Thomas 
> To: Tomcat Users List , 
> Date:   28/08/2015 19:13
> Subject:Re: Tomcat 8 Session Timeout
> 
> 
> 
> On 28/08/2015 12:08, theo.swe...@avios.com wrote:
>> Hello - currently HTTP sessions are configured to timeout after 120 
>> seconds, in $CATALINA_BASE/conf/web.xml
>>
>>
>> 2
>> 
>>
>> However this is not being honoured by the web services, where many 
> session 
>> are lasting longer.
>>
>> From what I understand - the order for session timeouts is - 
>>
>> HttpSession.setMaxInactiveInterval(int) 
>> $WebApplication/webapp/WEB-INF/web.xml 
>> $TOMCAT_BASE/conf/web.xml
>>
>> Is there something that I'm missing?
> 
> Tomcat version?
> 
> The usual causes are:
>  - something unexpected accessing the session
>  - the background processing thread is crashed / busy doing something
>else
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> -
> The Mileage Company Limited is a limited company registered in England under 
> company number 2260073 whose registered office address is at
> Astral Towers, Betts Way, London Road, Crawley, West Sussex, RH10 9XY.
> 
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify the 
> system manager.
> 
> This footnote also confirms that this email message has been swept by 
> Mimecast for the presence of computer viruses. 
> -
> 


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

Re: How do LockOutRealms work ?

On 31/08/2015 20:28, George Sexton wrote:
> 
> 
> On 8/31/2015 8:54 AM, Christopher Schultz wrote:
>> You also tell them how long they have to wait before they can resume
>> their brute-force attack without wasting their own time.
>>> Must better to let a brute force attacker pound away at a locked
>>> account wasting their resources and probably tripping additional
>>> security measures (like an IP block) for the excessive failures
>>> than it is to tell them what they need to do to keep the
>>> authentication system happy.
>>
> 
> I've started using Fail2Ban because of brute force attacks against
> Postfix-SASL. It would be nice if the LockoutRealm also reported the IP
> address so I could use it to cover Tomcat as well. In it's
> implementation, LockoutRealm gives the user n tries per account (at
> least that's my understanding).

The client IP isn't available to the Realm. It would need an API change.

I typically use the access log to trigger fail2ban with Tomcat since
both the client IP and the 403 response code are present.

Mark


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

Re: Tomcat 8 Session Timeout

2015-09-01 Thread Theo . Sweeny

Hi Mark 

Tomcat version?

v8.0.21

The usual causes are:
 - something unexpected accessing the session
 - the background processing thread is crashed / busy doing something
   else

Is there a command line mechanism to gracefully terminate sessions?

Theo

From:   Mark Thomas 
To: Tomcat Users List , 
Date:   28/08/2015 19:13
Subject:Re: Tomcat 8 Session Timeout

On 28/08/2015 12:08, theo.swe...@avios.com wrote:
> Hello - currently HTTP sessions are configured to timeout after 120 
> seconds, in $CATALINA_BASE/conf/web.xml
> 
>
> 2
> 
> 
> However this is not being honoured by the web services, where many 
session 
> are lasting longer.
> 
> From what I understand - the order for session timeouts is - 
> 
> HttpSession.setMaxInactiveInterval(int) 
> $WebApplication/webapp/WEB-INF/web.xml 
> $TOMCAT_BASE/conf/web.xml
> 
> Is there something that I'm missing?

Tomcat version?

The usual causes are:
 - something unexpected accessing the session
 - the background processing thread is crashed / busy doing something
   else

Mark

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

-
The Mileage Company Limited is a limited company registered in England under 
company number 2260073 whose registered office address is at
Astral Towers, Betts Way, London Road, Crawley, West Sussex, RH10 9XY.

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the 
system manager.

This footnote also confirms that this email message has been swept by Mimecast 
for the presence of computer viruses. 
-

Re: How do LockOutRealms work ?