Re: SSL Errors and Warnings with various version of Tomcat

[Richard Tearle]

On Tue, 13 Nov 2018 at 14:10, Mark Thomas  wrote:
>
> On 13/11/2018 14:00, Rémy Maucherat wrote:
> > On Tue, Nov 13, 2018 at 2:50 PM Richard Tearle <
> > richard.tea...@northgateps.com> wrote:
> >
> >> Hi
> >>
> >> Our applications are all working fine with Tomcat 8.5.34 and Tomcat
> >> Native 1.2.17; Centos 7.5; OpenSSL 1.0.2k-fips  26 Jan 2017; Oracle
> >> Java JRE 8u172
> >>
> >> On upgrading to Tomcat 8.5.35 and Tomcat Native 1.2.18, we get the
> >> following warning:
> >>
> >> 12-Nov-2018 14:37:03.459 WARNING [main]
> >> org.apache.tomcat.util.net.openssl.OpenSSLEngine. Failed
> >> getting cipher list
> >>  java.lang.Exception: Invalid Server SSL Protocol
> >> (error::lib(0):func(0):reason(0))
> >> at org.apache.tomcat.jni.SSLContext.make(Native Method)
> >> at org.apache.tomcat.util.net
> >> .openssl.OpenSSLEngine.(OpenSSLEngine.java:73)
> >>
> >
> > There was a patch porting problem in 8.5 in the jni.SSL class.
>
> Sorry. My mistake.
>
> I'll get the necessary fix back-ported for the next 8.5.x release.
>
> Mark

OK - so I just hold off until the next release - we can live with that.

Thanks all!

Richard

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

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

SSL Errors and Warnings with various version of Tomcat

[Richard Tearle]

Hi

Our applications are all working fine with Tomcat 8.5.34 and Tomcat
Native 1.2.17; Centos 7.5; OpenSSL 1.0.2k-fips  26 Jan 2017; Oracle
Java JRE 8u172

On upgrading to Tomcat 8.5.35 and Tomcat Native 1.2.18, we get the
following warning:

12-Nov-2018 14:37:03.459 WARNING [main]
org.apache.tomcat.util.net.openssl.OpenSSLEngine. Failed
getting cipher list
 java.lang.Exception: Invalid Server SSL Protocol
(error::lib(0):func(0):reason(0))
at org.apache.tomcat.jni.SSLContext.make(Native Method)
at 
org.apache.tomcat.util.net.openssl.OpenSSLEngine.(OpenSSLEngine.java:73)
at 
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getImplementedProtocols(OpenSSLUtil.java:63)
at org.apache.tomcat.util.net.SSLUtilBase.(SSLUtilBase.java:67)
at org.apache.tomcat.util.net.SSLUtilBase.(SSLUtilBase.java:51)
at 
org.apache.tomcat.util.net.openssl.OpenSSLUtil.(OpenSSLUtil.java:42)
at 
org.apache.tomcat.util.net.openssl.OpenSSLImplementation.getSSLUtil(OpenSSLImplementation.java:36)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:103)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1087)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:265)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:581)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:68)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:993)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:552)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:638)
at org.apache.catalina.startup.Catalina.load(Catalina.java:661)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)

On downgrading Tomcat Native to 1.2.17, and still keeping Tomcat
8.5.35, we get the following FATAL:

12-Nov-2018 17:24:17.474 SEVERE [https-openssl-nio-8443-exec-2]
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
 java.lang.UnsatisfiedLinkError:
org.apache.tomcat.jni.SSL.renegotiatePending(J)I
at org.apache.tomcat.jni.SSL.renegotiatePending(Native Method)
at 
org.apache.tomcat.util.net.openssl.OpenSSLEngine.getHandshakeStatus(OpenSSLEngine.java:1021)
at 
org.apache.tomcat.util.net.openssl.OpenSSLEngine.wrap(OpenSSLEngine.java:457)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
at 
org.apache.tomcat.util.net.SecureNioChannel.handshakeWrap(SecureNioChannel.java:440)
at 
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:211)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1475)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

Our application is fine with Tomcat 8.5.34 and Tomcat Native 1.2.18 as well.

Our connector configuration is, which we've not changed whilst testing
various version combinations:

   






We'd like to upgrade to Tomcat 8.5.35 and Tomcat Native 1.2.18,
without the warning (our implementers get twitchy when they see
warnings, even more so when it's around SSL/TLS...)

Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in 

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 17 April 2018 at 16:45, Richard Tearle
<richard.tea...@northgateps.com> wrote:
> On 17 April 2018 at 14:54, Mark Thomas <ma...@apache.org> wrote:
>> On 17/04/18 11:36, Mark Thomas wrote:
>>> On 17/04/18 10:14, Richard Tearle wrote:
>>
>> 
>>
>>> Now all we need to to do is to figure out how to fix this. With the
>>> understanding of what is (probably) going wrong, the problem can be
>>> produced with a clean build and the certs we use for unit tests which
>>> makes things a lot easier. I hope to make progress on this today.
>>
>> I believe this is fixed in trunk for both 9.0.x and 8.5.x.
>>
>> Are you able to build either of those from source and test? If not, I
>> can provide a snapshot build for you to test with.
>>
>> Cheers,
>>
>> Mark
>>
>
> I've built from source, re-enabled the health check, and so
> far so good - it's been running an hour without an error.
>
> Once this run has finished, I'll run it overnight, and let you
> know tomorrow morning.
>
> Many thanks for your help on this.
>
> --
> Richard

Just a quick follow up - I've run our test for 8 hours, without the
connection closed error.

Again, many thanks.

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 17 April 2018 at 14:54, Mark Thomas <ma...@apache.org> wrote:
> On 17/04/18 11:36, Mark Thomas wrote:
>> On 17/04/18 10:14, Richard Tearle wrote:
>
> 
>
>> Now all we need to to do is to figure out how to fix this. With the
>> understanding of what is (probably) going wrong, the problem can be
>> produced with a clean build and the certs we use for unit tests which
>> makes things a lot easier. I hope to make progress on this today.
>
> I believe this is fixed in trunk for both 9.0.x and 8.5.x.
>
> Are you able to build either of those from source and test? If not, I
> can provide a snapshot build for you to test with.
>
> Cheers,
>
> Mark
>

I've built from source, re-enabled the health check, and so
far so good - it's been running an hour without an error.

Once this run has finished, I'll run it overnight, and let you
know tomorrow morning.

Many thanks for your help on this.

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 16 April 2018 at 22:04, Mark Thomas <ma...@apache.org> wrote:
> On 11/04/18 09:22, Richard Tearle wrote:
>
> 
>
>> I've built tomcat from source using the link you provided, and rebuilt the
>> containers with this tomcat, and can still reproduce the issue. I've uploaded
>> the logs (30s before the connection closed error), to dropbox:
>>
>> https://www.dropbox.com/s/qe50jbd196krtyo/logs-10-04-17.zip?dl=0
>
> Thanks for these.
>
> I've started to look at them. I don't have any firm conclusions yet. I
> have noticed that the problem occurs after a connection is made to the
> service from localhost rather than the remote IP that is making the
> other requests. The localhost client does not present a certificate.
>
> My working theory (so chances are it is completely wrong) is that the
> missing certificate in the request from localhost puts the OpenSSL
> engine into an error state that is not correctly handled by Tomcat
> causing the subsequent request to fail.
>
> I've also noticed that the debug level log message consistently report 0
> bytes being read which looks wrong but is probably a separate (minor) issue.
>
> Investigations continue.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Ah that rings a bell.

Our containers have a simple health check, simply does

curl --connect-timeout 5 --max-time 20 -k -s -S --stderr -\
https://localhost:${TOMCATS_PORT}/ |\
grep -q "NSS: client certificate not found" || exit 1

just to make sure the ESB is responding, with something we expect.
These are set to run at an interval of every 2m30s. The full parameters
in the docker-compose[1] file are:

healthcheck:
  test: ["CMD", "/usr/local/bin/healthcheck.sh"]
  interval: 2m30s
  timeout: 10s
  retries: 3
  start_period: 20s

I've also disabled the health check on ESB container, and my tests
ran through for an hour, without a connection closed error.

[1] https://docs.docker.com/compose/compose-file/#healthcheck

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 5 April 2018 at 08:35, Richard Tearle <richard.tea...@northgateps.com> wrote:
>
> On 4 April 2018 at 17:58, Mark Thomas <ma...@apache.org> wrote:
> > On 26/03/18 08:25, Richard Tearle wrote:
> >
> > 
> >
> > Thanks. I've got the test application and UI running but I haven't yet
> > reproduced the problem. What parameters are you calling run-test.sh with?
>
> This usually get's a failure within 10 minutes of running:
>
> ./run-test.sh 28800 5000 5000 0 0 true
>
> (I've just tried it and it failed after 4m 23s - from the previous rounds
> of testing, it failed at around the 4m 30s mark 7 times out of 10)
>
> > I'll continue to try and reproduce the issue but I think it makes sense
> > to try and generate some debug data on your system as you can reproduce it.
> >
>
> I'll get onto this, but it might not be until next week.
>
> Thanks
>
> Richard.

I've built tomcat from source using the link you provided, and rebuilt the
containers with this tomcat, and can still reproduce the issue. I've uploaded
the logs (30s before the connection closed error), to dropbox:

https://www.dropbox.com/s/qe50jbd196krtyo/logs-10-04-17.zip?dl=0

Regards

-- 

Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 4 April 2018 at 17:58, Mark Thomas <ma...@apache.org> wrote:
> On 26/03/18 08:25, Richard Tearle wrote:
>
> 
>
> Thanks. I've got the test application and UI running but I haven't yet
> reproduced the problem. What parameters are you calling run-test.sh with?

This usually get's a failure within 10 minutes of running:

./run-test.sh 28800 5000 5000 0 0 true

(I've just tried it and it failed after 4m 23s - from the previous rounds
of testing, it failed at around the 4m 30s mark 7 times out of 10)

> I'll continue to try and reproduce the issue but I think it makes sense
> to try and generate some debug data on your system as you can reproduce it.
>

I'll get onto this, but it might not be until next week.

Thanks

Richard.

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

Hi

On 24 March 2018 at 23:06, Mark Thomas <ma...@apache.org> wrote:
> On 23/03/18 15:00, Richard Tearle wrote:
>> On 22 March 2018 at 23:06, Mark Thomas <ma...@apache.org> wrote:
>>> On 22/03/18 15:27, Richard Tearle wrote:
>>>> On 22 March 2018 at 14:49, Mark Thomas <ma...@apache.org> wrote:
>>>
>>> 
>>>
>
> I've taken another look at the configuration options and
> disableSessionTickets="true" is the only one that stands out as a
> possibility.
>
> I think we have reached the point where we need a reproducible test case.
>
> Mark
>

I've uploaded a ZIP with my test "UI" code (standalone java program),
and the "ESB"
code which goes into tomcat.

https://www.dropbox.com/s/nhfx7va4uzkr728/Source.zip?dl=0

In the support folder within the ZIP are updated scripts to create the
certificates - which
now includes generating the client certificate as well. Also in there
are the server.xml
and other tomcat configuration files that are changed as part of our
installation process
- although these are the same as I'd included in the previous ZIP.

Also included is a very simple shell script I use to call the UI.
Usually setting the ESB
delay to 5 seconds causes the connection closed error to occur in
around 5 minutes of
running the program.

Kinds Regards

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 22 March 2018 at 23:06, Mark Thomas <ma...@apache.org> wrote:
> On 22/03/18 15:27, Richard Tearle wrote:
>> On 22 March 2018 at 14:49, Mark Thomas <ma...@apache.org> wrote:
>
> 
>
> OK. Time to think about this. NIO + JSSE works whereas NIO + OpenSSL
> doesn't with the same configuration apart from the presence of the
> native library.
>
> That points to something OpenSSL specific.
>
> Disabling client verification fixes the problem.
>
> So it looks to be something to do with how OpenSSL handles client
> verification. It feels like configuration at this point rather than a
> bug but it needs some more thought.
>
> There will probably be some configuration combinations to experiment
> with but if they fail, something we can use to reproduce this is going
> to be the next step.
>
> Mark
>

That's fine and many thanks for your help - I can get quite a good turn around
on testing various configuration changes. Anything that looks
promising, I'll run
for 8 hours, and we can usually get an inkling after an hour.

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 22 March 2018 at 14:49, Mark Thomas <ma...@apache.org> wrote:
> On 22/03/18 07:46, Richard Tearle wrote:
>> On 21 March 2018 at 14:54, Mark Thomas <ma...@apache.org> wrote:

[snip]

> Excellent.
>
> There have been a few moving parts here so I'd like to get some
> clarification on exactly where we are. I know from bitter personal
> experience that it is all too easy to end up using a slightly different
> TLS configuration to the one you think you are using so please could you
> confirm the following.
>
> The connector name can be obtained from the logs. You'll see lines that
> look like this:
>
> 22-Mar-2018 14:39:30.156 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["http-nio-8080"]
> 22-Mar-2018 14:39:30.161 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["https-jsse-nio-8443"]
> 22-Mar-2018 14:39:30.163 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["ajp-nio-8009"]
>
> The part I am using below is the bit in the square brackes. The format
> is ---.
>
> What we have so far is:
>
> 8.0.x, http-nio- (this is always JSSE in 8.0.x), clientAuth="true"
> This works.

Yes this works.

> 8.5.x, http-nio-openssl-, certificateVerification="required"
> This fails intermittently

Its https-openssl-nio- and yes this fails intermittently.

> 8.5.x, http-nio-jsse-,  certificateVerification="required"
> This works

Its https-jsse-nio-, and yes this works

> Is this correct?
>
> Thanks,
>
> Mark
>

Also working is 8.5.x, https-openssl-nio-, certificateVerification="none"

Thanks

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 21 March 2018 at 14:54, Mark Thomas  wrote:
>
>
> Progress.
>
> Tomcat 8.0.x is more relaxed about the content of PKCS12 trust stores
> then 8.5.x because of a change[1] made so that the effectiveness of the
> certificateVerificationDepth configuration attribute did not depend on
> the presence of a certificate revocation list.
>
> The PKCS12 store the scripts you provided creates includes the private
> key of the trusted certificate. This is ... unusual. 8.5.x skips this
> cert as it does not expect a trusted cert to include the private key.
>
> I've tried various ways to get openssl to create a PKCS12 file without
> the private key but with the certificate without success. In the end I
> used keytool to do this and that worked. Something along these lines:
>
> keytool -storetype pkcs12 -importcert -file ca-cert.pem \
> -keystore ca-truststore.p12
>
> With the modified trust store 8.5.x started with the same configuration
> as 8.0.x.
>
> Please can you test your set-up with 8.5.x, the modified trust store and
> the same configuration as 8.0.x (NIO, JSSE). That should help us track
> down where the problem may lie.
>
> Thanks,
>
> Mark
>

I created the PKCS12 as you showed above used my 8.0.x configuration and
ran my test application for 8 hours without a single connection closed error .

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 20 March 2018 at 19:58, Mark Thomas <ma...@apache.org> wrote:

> On 20/03/18 14:49, Richard Tearle wrote:
> OK. Can you share you configuration and the steps you used to create the
> self-signed certificate. I'd like to see if I can reproduce this.
>
>
> Mark
>

I thought it might be easier to drop the configuration and certificate
generating scripts into a ZIP on dropbox:

https://www.dropbox.com/s/ib98y6ti2bem53v/TomcatCertsIssue.zip?dl=0

In the root of the ZIP contains two scripts, run the create-cert.sh,
to generate them.

Our Java installation has the Java Cryptography Extension (JCE)
installed, and generally we run with the java security manager
enabled, but I've tested running without it doesn't seem to affect the
error we get.

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 20 March 2018 at 14:49, Richard Tearle
<richard.tea...@northgateps.com> wrote:
> Hello
>
> On 20 March 2018 at 11:29, Mark Thomas <ma...@apache.org> wrote:
>>
>> 
>>
>> There are rather too many factors at play here. It would be good to try
>> and eliminate some of them.
>>
>> What are the known working 8.0.x versions?
>>

Sorry I missed these in my previous reply:

8.0.50, 8.0.48 to 8.0.46, 8.0.41. 8.0.33, 8.0.26

--

 Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

Hello

On 20 March 2018 at 11:29, Mark Thomas <ma...@apache.org> wrote:
>
> On 20/03/18 07:52, Richard Tearle wrote:
> > Hello
> >
> > We have 4 applications built on the same architecture with a web UI
> > and camel based ESB running in separate Tomcat's, using REST/XML to
> > communicate between the two. This is all deployed within separate
> > Docker containers but on the same VM (at least for test), either on
> > Centos Linux or Oracle Linux. This all works on Tomcat 8.0.x. We've
> > been upgrading to Tomcat 8.5.x since November last year, but this has
> > been hampered by what looks to be random connection closed errors when
> > our UI communicates to the ESB. We have a series of Selenium based
> > autotests which will fail in different places, but with the same
> > error:
>
> 
>
> There are rather too many factors at play here. It would be good to try
> and eliminate some of them.
>
> What are the known working 8.0.x versions?
>
> I looks like you are using JSSE with 8.0.x. It should be possible to use
> the exact same configuration with 8.5.x. No need to use the native
> library and no need to switch to the new configuration style.
>
> Lets try and get 8.5.x working with JSSE. That should help narrow down
> the root cause. What happens when you transfer the working 8.0.x config
> to 8.5.x?

On startup we get:

20-Mar-2018 14:43:18.908 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed
to initialize component [Connector[HTTP/1.1-4001]]
 org.apache.catalina.LifecycleException: Protocol handler initialization failed
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:935)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:530)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:852)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at org.apache.catalina.startup.Catalina.load(Catalina.java:633)
at org.apache.catalina.startup.Catalina.load(Catalina.java:656)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
Caused by: java.lang.IllegalArgumentException: the trustAnchors
parameter must be non-empty
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:114)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:85)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:216)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1043)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:540)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:932)
... 13 more
Caused by: java.security.InvalidAlgorithmParameterException: the
trustAnchors parameter must be non-empty
at 
java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
at 
java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130)
at 
org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:389)
at 
org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:313)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:112)
... 19 more

> Also, anything you can do to reduce the complexity of the test
> application (ideally reducing it to simple Servlets/JSPs) would make it
> easier for others to reproduce the issue.

I can ZIP my code and drop it somewhere if that will help.

> Hmm. That looks like a controlled shutdown. Random thought, does setting
> disableSessionTickets="true" help at all when using OpenSSL?
>

I'm afraid that didn't work, but thanks for the suggestion.

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


-- 

Richard

-- 
This email is sent on behalf of Northgate 

Connection closed error and certificateVerification="required"

[Richard Tearle]

Hello

We have 4 applications built on the same architecture with a web UI
and camel based ESB running in separate Tomcat's, using REST/XML to
communicate between the two. This is all deployed within separate
Docker containers but on the same VM (at least for test), either on
Centos Linux or Oracle Linux. This all works on Tomcat 8.0.x. We've
been upgrading to Tomcat 8.5.x since November last year, but this has
been hampered by what looks to be random connection closed errors when
our UI communicates to the ESB. We have a series of Selenium based
autotests which will fail in different places, but with the same
error:

09:30:46.057 [main] ERROR test.ui.Main - Catching
java.util.concurrent.ExecutionException:
org.apache.http.ConnectionClosedException: Connection closed
at org.apache.http.concurrent.BasicFuture.getResult(BasicFuture.java:70)
~[test-ui.jar:?]
at org.apache.http.concurrent.BasicFuture.get(BasicFuture.java:80)
~[test-ui.jar:?]
at org.apache.http.impl.nio.client.FutureWrapper.get(FutureWrapper.java:70)
~[test-ui.jar:?]
at 
org.springframework.util.concurrent.FutureAdapter.get(FutureAdapter.java:81)
~[test-ui.jar:?]
at 
org.springframework.util.concurrent.FutureAdapter.get(FutureAdapter.java:81)
~[test-ui.jar:?]
at test.ui.Main.post(Main.java:182) ~[test-ui.jar:?]
at test.ui.Main.callServer(Main.java:148) [test-ui.jar:?]
at test.ui.Main.main(Main.java:109) [test-ui.jar:?]
Caused by: org.apache.http.ConnectionClosedException: Connection closed
at 
org.apache.http.nio.protocol.HttpAsyncRequestExecutor.endOfInput(HttpAsyncRequestExecutor.java:345)
~[test-ui.jar:?]
at 
org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:261)
~[test-ui.jar:?]
at 
org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:81)
~[test-ui.jar:?]
at 
org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:39)
~[test-ui.jar:?]
at 
org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:121)
~[test-ui.jar:?]
at 
org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
~[test-ui.jar:?]
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
~[test-ui.jar:?]
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
~[test-ui.jar:?]
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
~[test-ui.jar:?]
at 
org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
~[test-ui.jar:?]
at 
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588)
~[test-ui.jar:?]
at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_162]

We've seen this on all of the versions of Tomcat 8.5 we've tried from
8.5.23 onwards - and I've just tried Tomcat 9.0.6 with the same error.
We're using Oracle Java version 1.8u162.

Development have looked at this off and on over the last couple of
months, but without success, so I was asked to reproduce this with a
simple test case (I'm devops usually, but with a development
background). The client stack uses a
PoolingNHttpClientConnectionManager, CloseableHttpAsyncClient and
AsyncRestTemplate to communicate to the ESB. My simple test case
replaces the web UI with a simple jar based application, but it still
replicates the issue. The ESB is a simple Camel route that adds two
supplied numbers, waits for a time (supplied by the UI), and returns
the result. The UI repeatedly calls the ESB (on a single thread, with
no overlapping calls), with two random numbers to be summed, and a set
amount of time to wait before the ESB returns. Between each call to
the ESB there's a set amount of time to wait before the next call. It
seems that when the ESB wait is >= 5secs the time take to fail is
greatly decreased.

The connection between the UI and the ESB is TLSv1.2 with the ESB
configured with certificateVerification="required". The connector
configuration with the ESB's server.xml is:








We are using PEM encoded certificates, and using Tomcat Native Library
version 1.2.16. If I take out certificateVerification="required", we
don't get the error (with my simple test case running for an hour)
I've tried using PKCS12 and JKS certificates, but I can't get Tomcat
8.5.x to work with our self signed trust store (we get the
"trustAnchors parameter must be non-empty" errors), although Tomcat
8.0.x seems happy enough with them. So I can't tell if it's a
difference between using OpenSSL and JSSE.

Enabling SSL debug traces on the client shows that in the error case,
after the initial successful handshaking between the client and the
server, the ESB shuts down the connection just after the client has
sent the data:

*** CertificateVerify
 

Re: Tomcat 8.5.28 SSL - Cannot store non-PrivateKeys

[Richard Tearle]

Hello

On 1 March 2018 at 23:31, George S. <geor...@mhsoftware.com> wrote:

> I'm hitting the error:
>
> SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8443]]
> org.apache.catalina.LifecycleException: Failed to initialize component
> [Connector[HTTP/1.1-8443]]
> Caused by: org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
> Caused by: java.lang.IllegalArgumentException: Cannot store
> non-PrivateKeys
>
> The connector is configured as:
>
>
>  address="10.0.0.62"
>maxThreads="150" SSLEnabled="true">
> 
>  certificateFile="conf/certificate.pem"
>  type="RSA" />
> 
> 
>
> I've verified the tomcat user can read the two files, and I've su'd to
> user tomcat and used:
>
> openssl rsa -in key.pem -text
>
> and the private key was dumped as expected. The key is not encrypted. The
> cert is self-signed and was generated by OpenSSL using CA.sh.
>
> I'm kind of at a loss here. The example server.xml entries show naming PEM
> files directly, and the connector docs seem to imply that pem files are
> supported.
>
> Can anyone give me a pointer on what to do here?
>
> --
> George S.
> *MH Software, Inc.*
> Voice: 303 438 9585
> http://www.mhsoftware.com
>


Are you using the Tomcat Native Library? I think that's required when using
PEM encoded certificates.

-- 

*Richard Tearle BSc(Hons) MCP*

Senior Consultant

*Northgate Public Services (NPS)*

Mobile: +44 (0)7738 888315

Email: richard.tea...@northgateps.com

Web: www.n <http://www.northgate-is.com/>orthgatepublicservices.co.uk

Please consider the environment before printing this e-mail

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

Re: Trouble with TLS/SSL and Tomcat 8.5.23

[Richard Tearle]

On 23 November 2017 at 17:20, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 11/23/17 8:28 AM, Richard Tearle wrote:
>> Yes I read through that thread, but we don't really like Java key
>> stores, and I don't think the work around would work for us.
>
> Java keystores are ... awful.
>
>> Instead, I did what perhaps I should have done a while ago (on
>> version 8.0.x), and built Tomcat Native libraries, deployed, and
>> changed the certificate references in the connector to use our .PEM
>> files (which the PKCS12 files are built from), and fingers crossed,
>> its looking OK at the moment.
>
> So are you using the APR connector, then?
>
> You do have some other options:
>
> 1. JSSE with a PKCS12 keystore. OpenSSL can work with those types of
> keystores.
>
> 2. JSSE with PEM-encoded DER files. I prefer PEM-encoded DER files for
> everything, simply because they are so easy to work with.
>
> 3. JSSE+OpenSSL with PEM-encoded DER files.
>
> Option #3 will get you the performance of OpenSSL's crypto but without
> using the APR connector (which isn't quite as efficient as the
> pure-Java NIO connector). Java's crypto seems to be hobbled for some
> reason... some kind of mistake in the native-optimization that ends up
> falling-back to pure-Java crypto which ... simply isn't fast enough
> for real-world workloads).
>
> I think the APR connector is likely to disappear with the next major
> release of Tomcat (10.x I would guess) as the NIO+OpenSSL combination
> is becoming more mature and offers better performance and scalability.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloXA2AACgkQHPApP6U8
> pFilzA/9E5R4NjcoB1yE6oQ2sXb7TURJg/WDJls00Y7RjwSN1UmkiiAdwktcuH0T
> hL6+2M71yrJ+rnCLbyQGEmPdJdFSAv4rTy+eoHJqDTf9jakUYvLC+XvIdWgz/p6i
> tWhIRZAS/sr4JmwFgrIY4I4iKcmJ/pGjrQHLu59H0gEYFdOCoA+WpsNgmIiFLUr6
> IWochlde/ahxP6vNOZJLYxBb8kQ8JUBWXHN+2jGiD5GU7jav3DmwlFKeaoelbclk
> DUUbzc+no83pSIcwzsNsIcPjxdh9fSIzP3nAdNDlIJtGF3SDwwu6HyP0cEb+r+rg
> l9LjDwUrcIFB7pAas38bUpf8DjSysRLk5Jh013BhxUJIcB5hZflrUqeq6Nb+JonC
> EepZoUNSWFiblB36ofNmyJUXaRshBqVfD/x1teJXpoLVJ/HUY8A84T3DlLIzHMAS
> lMfJ4CaCYyDqeA5KL9PZMyEpiPivn4aqeMeVEkrz/DHamLvWhJ649mfRb9BNOBE0
> 3uJvLHOYanORuVWAyQc6nmpSFuda3lgUCZVN9/jhRNW6AszBjLi/9xb7vP/EE41I
> jXZYnJgra1tdL2wq85cqR3NRIf2HrZrvaVsQOikn+MqHR19Pwm5T3xrlIN9hT4EP
> t9LeqizK0vK0cz0/tDBVmqXjASyP5ArJ0dz6uJqijJtGjUWe+gM=
> =bf9o
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Hi

I think Option #1 was what I was trying to achieve originally. I'll take a look
at option #3 tomorrow.

Thanks for the heads up

Richard.

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Re: Trouble with TLS/SSL and Tomcat 8.5.23

[Richard Tearle]

On 23 November 2017 at 05:33, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 11/22/17 8:40 AM, Richard Tearle wrote:
>> Hello
>>
>> Apache Tomcat 8.5.23 Centos 7.4 (3.10.0-514.16.1.el7.x86_64) Java
>> 1.8.0_152 (with jce) Running in Docker Container
>>
>> I'm upgrading our applications from Apache Tomcat 8.0.47 to
>> 8.5.23, but when trying to get TLS/SSL working on a connector I get
>> the following error:
>>
>> 22-Nov-2017 11:52:46.098 SEVERE [main]
>> org.apache.coyote.AbstractProtocol.init Failed to initialize end
>> point associated with ProtocolHandler ["https-jsse-nio2-18443"]
>> java.lang.IllegalArgumentException:
>> java.security.InvalidAlgorithmParameterException: the trustAnchors
>> parameter must be non-empty at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
> actJsseEndpoint.java:115)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJs
> seEndpoint.java:86)
>> at
>> org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:9
> 82)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpo
> int.java:245)
>>
>>
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
>> at
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Pro
> tocol.java:66)
>>
>>
> at org.apache.catalina.connector.Connector.initInternal(Connector.java:9
> 97)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>
>>
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.ja
> va:549)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>
>>
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java
> :875)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>>
>>
> at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:644) at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62)
>>
>>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498) at
>> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311) at
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>> Caused by: java.security.InvalidAlgorithmParameterException: the
>> trustAnchors parameter must be non-empty at
>> java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:
> 200)
>>
>>
> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
>> at
>> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.
> java:130)
>>
>>
> at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:
> 368)
>> at
>> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.jav
> a:292)
>>
>>
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstrac
> tJsseEndpoint.java:113)
>> ... 20 more
>>
>> I've changed the connector configuration to use
>> SSLHostConfig/Certificate, but our certificate generation process
>> (self signed certificates) has remained the same. I did a quick
>> internet search, and saw that other people had similar, but not
>> exact issues, and going back to 8.5.4 "solved" the issue. So I did
>> this as a quick test, so at least I could see that our
>> configuration changes where correct, and yes the application ran ok
>> with Tomcat 8.5.4. The connector configuration is:
>>
>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>> server="Apache" maxPostSize="10"> > certificateVerification="none" sslProtocol="TLSv1.2"
>> protocols="TLSv1.2"
>> truststoreFile="/usr/local/tomcat/ssl/ca-truststore.p12"
>> truststoreType="PKCS12" truststorePassword="${truststore.pass}"
>> honorCipherOrder="true"
>> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_EC

Re: Trouble with TLS/SSL and Tomcat 8.5.23

[Richard Tearle]

Peter

On 22 November 2017 at 15:08, Peter Kreuser <l...@kreuser.name> wrote:
>
>
>
>
> Richard,
>
>
>
>
>
>> Gesendet: Mittwoch, 22. November 2017 um 14:40 Uhr
>> Von: "Richard Tearle" 
>> <richard.tea...@northgateps.com[mailto:richard.tea...@northgateps.com]>
>> An: users@tomcat.apache.org[mailto:users@tomcat.apache.org]
>> Betreff: Trouble with TLS/SSL and Tomcat 8.5.23
>> Hello
>>
>> Apache Tomcat 8.5.23
>> Centos 7.4 (3.10.0-514.16.1.el7.x86_64)
>> Java 1.8.0_152 (with jce)
>> Running in Docker Container
>>
>> I'm upgrading our applications from Apache Tomcat 8.0.47 to 8.5.23,
>> but when trying to get TLS/SSL working on a connector I get the
>> following error:
>>
>> 22-Nov-2017 11:52:46.098 SEVERE [main]
>> org.apache.coyote.AbstractProtocol.init Failed to initialize end point
>> associated with ProtocolHandler ["https-jsse-nio2-18443"]
>> java.lang.IllegalArgumentException:
>> java.security.InvalidAlgorithmParameterException: the trustAnchors
>> parameter must be non-empty
>> at 
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
>> at 
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
>> at org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
>> at 
>> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:982)
>> at 
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:245)
>> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
>> at 
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66)
>> at org.apache.catalina.connector.Connector.initInternal(Connector.java:997)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at 
>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at 
>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
>> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:644)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>> Caused by: java.security.InvalidAlgorithmParameterException: the
>> trustAnchors parameter must be non-empty
>> at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
>> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
>> at 
>> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130)
>> at org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:368)
>> at 
>> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:292)
>> at 
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
>> ... 20 more
>>
>> I've changed the connector configuration to use
>> SSLHostConfig/Certificate, but our certificate generation process
>> (self signed certificates) has remained the same. I did a quick
>> internet search, and saw that other people had similar, but not exact
>> issues, and going back to 8.5.4 "solved" the issue. So I did this as a
>> quick test, so at least I could see that our configuration changes
>> where correct, and yes the application ran ok with Tomcat 8.5.4. The
>> connector configuration is:
>>
>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>> maxThreads="150" SSLEnabled="true" scheme="https"
>> secure="true" server="Apache" maxPostSize="10">
>> > sslProtocol="TLSv1.2" protocols="TLSv1.2"
>> truststoreFile="/usr/local/tomcat/ssl/ca-truststore.p12"
>> truststoreType="PKCS12"
>> truststorePassword="${truststore.pass}" honorCipherOrder="true"
>
> The error message says that either the file simply is not there or the cert 

Trouble with TLS/SSL and Tomcat 8.5.23

[Richard Tearle]

Hello

Apache Tomcat 8.5.23
Centos 7.4 (3.10.0-514.16.1.el7.x86_64)
Java 1.8.0_152 (with jce)
Running in Docker Container

I'm upgrading our applications from Apache Tomcat 8.0.47 to 8.5.23,
but when trying to get TLS/SSL working on a connector I get the
following error:

22-Nov-2017 11:52:46.098 SEVERE [main]
org.apache.coyote.AbstractProtocol.init Failed to initialize end point
associated with ProtocolHandler ["https-jsse-nio2-18443"]
 java.lang.IllegalArgumentException:
java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:86)
at org.apache.tomcat.util.net.Nio2Endpoint.bind(Nio2Endpoint.java:163)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:982)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:245)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:620)
at 
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:997)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:621)
at org.apache.catalina.startup.Catalina.load(Catalina.java:644)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
Caused by: java.security.InvalidAlgorithmParameterException: the
trustAnchors parameter must be non-empty
at 
java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
at 
java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:130)
at 
org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:368)
at 
org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:292)
at 
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
... 20 more

I've changed the connector configuration to use
SSLHostConfig/Certificate, but our certificate generation process
(self signed certificates) has remained the same. I did a quick
internet search, and saw that other people had similar, but not exact
issues, and going back to 8.5.4 "solved" the issue. So I did this as a
quick test, so at least I could see that our configuration changes
where correct, and yes the application ran ok with Tomcat 8.5.4. The
connector configuration is:


   
  

 


Setting javax.net.debug=all in CATALINA_OPTS and viewing the resultant
logging, seems to indicate that the certificate is being loaded, but
not the trust store, with the only truststore loaded coming from:
/opt/jre1.8.0_152/lib/security/cacerts

Best Regards


Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered