tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat) ...@ice-sa.com>
Subject Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW
Date Wed, 21 Sep 2016 14:47:55 GMT
On 21.09.2016 16:40, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> 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:aw@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
>>>> RAW
>>>>
>>>> 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
>>>> server:
>>>>>>
>>>>>> - 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
>>> -Djava.util.logging.config.file=/var/www/tomcat/conf/logging.properti
> es
>>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>>>
>>>
> - -Xms1024m -Xmx20
>>>
>>> Staging: 502      25138     1  3 Sep15 ?        03:30:29
>>> /usr/java/latest/bin/java
>>> -Djava.util.logging.config.file=/var/www/tomcat/conf/logging.properti
> es
>>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>>>
>>>
> - -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 ->
>>> /usr/java/jre1.8.0_102
>>>
>>> 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 ->
>>> /usr/java/jre1.8.0_102
>>>
>>> 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 :
>> http://lmgtfy.com/?q=java.security.InvalidAlgorithmParameterException%
> 3A+Key+format+must+be+RAW
>>
>>
>>
>> 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:
>
> https://access.redhat.com/solutions/1309153
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message