On 21.09.2016 16:40, Christopher Schultz wrote:
Hash: SHA256


On 9/20/16 7:51 PM, André Warnier (tomcat) wrote:
On 20.09.2016 19:21, Dono Harjanto wrote:
Hi André,

-----Original Message----- From: André Warnier (tomcat)
[mailto:a...@ice-sa.com] Sent: Tuesday, September 20, 2016 12:13
AM To: users@tomcat.apache.org Subject: Re: TLS 1.2 Handshake
on Tomcat 7.0.39 Getting Internal Error: Key format must be

On 20.09.2016 09:06, André Warnier (tomcat) wrote:
On 19.09.2016 18:45, Dono Harjanto wrote:
Hi All,

We have a web app deployed on 3 different servers, all
running Tomcat 7.0.39 and Java 8 (update 101/102). Here is
the operating system on each

- Production: CentOS 6.4

- Staging 1: CentOS 6.5

- Staging 2: CentOS 6.7

Java versions ?

Sorry for the noise, did not read the above carefully enough.
Are you sure they are really using the same Java version,
though ? (/etc/alternatives and all that)

Result from running "ps -ef | grep tomcat" command (truncated) on
all instances: Production: 502      29119     1  2 Sep14 ?
03:08:08 /usr/java/latest/bin/java

- -Xms1024m -Xmx20

Staging: 502      25138     1  3 Sep15 ?        03:30:29

- -Xms1024m -Xmx2048m -XX:MaxPermS

The content of /usr/java/ folder which shows latest is pointing
to jre1.8.0_102 instead of jre1.7.0_21.

Production: lrwxrwxrwx. 1 root root   16 Apr 26  2013 default ->
/usr/java/latest drwxr-xr-x. 6 root root 4096 Apr 26  2013
jre1.7.0_21 drwxr-xr-x. 7 root root 4096 Aug  1 20:43
jre1.8.0_102 lrwxrwxrwx. 1 root root   22 Sep 17 00:22 latest ->

Staging: lrwxrwxrwx. 1 root root   16 Aug 14  2014 default ->
/usr/java/latest drwxr-xr-x. 9 root root 4096 Sep  7 18:53
jdk1.8.0_60 drwxr-xr-x. 6 root root 4096 Aug 14  2014
jre1.7.0_60 drwxr-xr-x. 7 root root 4096 Sep 14 21:25
jre1.8.0_102 drwxr-xr-x. 7 root root 4096 Sep  7 18:51
jre1.8.0_60 lrwxrwxrwx. 1 root root   22 Sep 14 21:55 latest ->

So it's definitely using Java 8 instead of Java 7.

The purpose of my question was : - according to your Connector
configuration, you are using the Java BIO Connector, hence the Java
SSL implementation. - so I wanted to ascertain that a possible
hidden difference between the Java version used on the various
systems, could not be linked to your issue. According to the above,
that does not seem to be the case (or at least not since Sept 17).

On the problem itself unfortunately, I am not qualified to help.

Searching Google provides some apparently related links however :

Now just a question related to one of these links : are your
staging servers and your production server located in the same
country ?

This may be the most promising page on the Internet, but of course Red
Hat wants you to pay to read it:


I can't see the "verified solution", or I'd reprint it here without
permission :)

Yes, saw that one too and could not read it either. Neither probably can the OP, since he's using CentOS.. But there is another link further down, to a precise description of the Sun classes involved, where there is some mention of some potentially different underlying Java module, to do with the cryptographic export restrictions. That was the reason for my question : maybe some servers have the same basic Java version, but a different version of said modules.. My knowledge of the underlying SSL is insufficient to determine if this might really be an interesting lead, or just a red herring though.
But my Hercule Poirot genes were tickled.

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

Reply via email to