You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dono Harjanto <do...@deviceauthority.com> on 2016/09/19 16:45:38 UTC

TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

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


When we accessed the web app on Production server, we were able to connect and connected over TLS 1.2 (as expected). However, when we accessed the web app on both Staging servers we were able to connect, but it was connected over TLS 1.1 not TLS 1.2 as TLS 1.2 handshake failed and server sent an Alert (Level: Fatal, Description: Internal Error) response.


We enabled SSL debugging on Tomcat and we saw Tomcat threw InvalidAlgorithmParameterException exception in catalina.out as shown below:


http-bio-8443-exec-1, READ: TLSv1.2 Handshake, length = 70
*** ECDHClientKeyExchange
ECDH Public value:  { 4, 245, 39, 156, 56, 88, 62, 108, 141, 237, 93, 240, 210, 228, 91, 60, 14, 109, 138, 121, 126, 100, 36, 194, 93, 101, 131, 119, 120, 57, 120, 222, 73, 123, 122, 218, 253, 91, 170, 240, 251, 73, 214, 29, 192, 234, 109, 189, 40, 249, 161, 176, 172, 179, 36, 162, 229, 69, 160, 221, 242, 53, 100, 34, 215 }
SESSION KEYGEN:

PreMaster Secret:
(key bytes not available)
RSA master secret generation error:
java.security.InvalidAlgorithmParameterException: Key format must be RAW
        at com.sun.crypto.provider.TlsMasterSecretGenerator.engineInit(TlsMasterSecretGenerator.java:67)
        at javax.crypto.KeyGenerator.init(KeyGenerator.java:454)
        at javax.crypto.KeyGenerator.init(KeyGenerator.java:430)
        at sun.security.ssl.Handshaker.calculateMasterSecret(Unknown Source)
        at sun.security.ssl.Handshaker.calculateKeys(Unknown Source)
        at sun.security.ssl.ServerHandshaker.processMessage(Unknown Source)
        at sun.security.ssl.Handshaker.processLoop(Unknown Source)
        at sun.security.ssl.Handshaker.process_record(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.getSession(Unknown Source)
        at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:215)
        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
http-bio-8443-exec-1, handling exception: java.security.ProviderException: java.security.InvalidAlgorithmParameterException: Key format must be RAW
%% Invalidated:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
http-bio-8443-exec-1, SEND TLSv1.2 ALERT:  fatal, description = internal_error
http-bio-8443-exec-1, WRITE: TLSv1.2 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 03 00 02 02 50                               ......P
http-bio-8443-exec-1, called closeSocket()
http-bio-8443-exec-1, IOException in getSession():  javax.net.ssl.SSLException: java.security.ProviderException: java.security.InvalidAlgorithmParameterException: Key format must be RAW
http-bio-8443-exec-1, called close()
http-bio-8443-exec-1, called closeInternal(true)



Below is the server.xml configuration we have on all servers:


    <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"

        SSLEnabled="true"
        scheme="https"
        secure="true"
        clientAuth="false"
        sslProtocol="TLS"

        maxHttpHeaderSize="8192"
        maxThreads="150"
        minSpareThreads="25"
        enableLookups="false"
        disableUploadTimeout="true"
        acceptCount="100"
        useBodyEncodingForURI="true"

        keystoreType="pkcs12"
        keystoreFile="/path/to/keystore/.filename.p12"
        keystorePass="<snip>" />



Any idea why Tomcat not able to do TLS 1.2 handshake and throwing "Key format must be RAW" exception? Did we miss anything here?



Thanks for your help,

Don


RE: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by Dono Harjanto <do...@deviceauthority.com>.
Ron,

> -----Original Message-----
> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
> Sent: Wednesday, September 21, 2016 10:17 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 21.09.2016 18:49, Christopher Schultz wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Ron,
> >
> > On 9/21/16 11:58 AM, Roskens, Ronald wrote:
> >>> -----Original Message----- From: Christopher Schultz
> >>> [mailto:chris@christopherschultz.net] Sent: Wednesday, September 21,
> >>> 2016 9:40 AM To: Tomcat Users List Subject: Re: TLS 1.2 Handshake on
> >>> Tomcat 7.0.39 Getting Internal Error: Key format must be RAW
> >>>
> >>
> >> <snipped>
> >>
> >>> 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 :)
> >>

We came across the above link as well, but it requires RedHat login credentials to see the solution :(

> >> The resolution says to either disable TLS 1.2 or FIPS mode.
> >>
> >> The root cause is the PKCS#11 implementation included in Java 7 and
> >> 8 does not support TLS 1.2 when in FIPS mode as documented in OpenJDK
> >> bug JDK-8029661
> >> (https://bugs.openjdk.java.net/browse/JDK-8029661)
> >>
> >> See also:
> >> https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/
> >> F
> > IPS.html
> >
> > Thanks
> >>
> > for posting this.
> >
> > Good old FIPS: hobbling real security since 1994.
> >

Thank you for posting this. Will read through that posting. A quick cat on java.security on Production and staging server indicate no SunPKCS11-NSS is specified for provider #4:

Production:
[Wed Sep 21 20:35:54 root@ip-##-##-##-##:~]$ cat /usr/java/latest/lib/security/java.security | grep -E '^security\.provider'
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC

Staging:
[root@stagedas cp-hosted-downloads]# cat /usr/java/latest/lib/security/java.security | grep -E '^security\.provider'
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC

> 
> Thanks also, but does this explain fully the symptoms seen by the OP ?  As I
> recall, he had 3 apparently similar servers, configured similarly, but where 2
> were seeing the problem and the third one not.
> Or was there another difference which he did not tell us about, and where ?
>

Correct, we did make sure Tomcat and Java version are the same across all 3 servers. The CentOS version on all 3 servers are different:
6.4 (Production/AWS, TLS 1.2 works), 6.5 (Staging, no TLS 1.2), and 6.7 (Staging, no TLS 1.2)

Appreciate all the help. We will continue our investigation and once resolved we will post the resolution in this forum. 
 
Thank you.

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


RE: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by Dono Harjanto <do...@deviceauthority.com>.
Jose,

> -----Original Message-----
> From: Jose María Zaragoza [mailto:demablogia@gmail.com]
> Sent: Wednesday, September 21, 2016 11:46 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key
> format must be RAW
> 
> 2016-09-21 19:16 GMT+02:00 André Warnier (tomcat) <aw...@ice-sa.com>:
> > On 21.09.2016 18:49, Christopher Schultz wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >>
> >> Ron,
> >>
> >> On 9/21/16 11:58 AM, Roskens, Ronald wrote:
> >>>>
> >>>> -----Original Message----- From: Christopher Schultz
> >>>> [mailto:chris@christopherschultz.net] Sent: Wednesday, September
> >>>> 21, 2016 9:40 AM To: Tomcat Users List Subject: Re: TLS 1.2
> >>>> Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must
> >>>> be RAW
> >>>>
> >>>

<snipped>


> >
> > Thanks also, but does this explain fully the symptoms seen by the OP ?
> > As I recall, he had 3 apparently similar servers, configured
> > similarly, but where
> > 2 were seeing the problem and the third one not.
> > Or was there another difference which he did not tell us about, and where ?
> >
> >
> 
> I'd try to run
> 
> cat /proc/sys/crypto/fips_enabled

Thank you and below is the output on Production and staging:

Production (CentOS 6.4):
[Wed Sep 21 20:36:01 root@ip-##-###-##-##:~]$ cat /proc/sys/crypto/fips_enabled
0

Staging (CentOS 6.5):
[root@stagedas cp-hosted-downloads]# cat /proc/sys/crypto/fips_enabled
0

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


Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by Jose María Zaragoza <de...@gmail.com>.
2016-09-21 19:16 GMT+02:00 André Warnier (tomcat) <aw...@ice-sa.com>:
> On 21.09.2016 18:49, Christopher Schultz wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Ron,
>>
>> On 9/21/16 11:58 AM, Roskens, Ronald wrote:
>>>>
>>>> -----Original Message----- From: Christopher Schultz
>>>> [mailto:chris@christopherschultz.net] Sent: Wednesday, September
>>>> 21, 2016 9:40 AM To: Tomcat Users List Subject: Re: TLS 1.2
>>>> Handshake on Tomcat 7.0.39 Getting Internal Error: Key format
>>>> must be RAW
>>>>
>>>
>>> <snipped>
>>>
>>>> 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 :)
>>>
>>>
>>> The resolution says to either disable TLS 1.2 or FIPS mode.
>>>
>>> The root cause is the PKCS#11 implementation included in Java 7 and
>>> 8 does not support TLS 1.2 when in FIPS mode as documented in
>>> OpenJDK bug JDK-8029661
>>> (https://bugs.openjdk.java.net/browse/JDK-8029661)
>>>
>>> See also:
>>> https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/F
>>
>> IPS.html
>>
>> Thanks
>>>
>>>
>> for posting this.
>>
>> Good old FIPS: hobbling real security since 1994.
>>
>
> Thanks also, but does this explain fully the symptoms seen by the OP ?  As I
> recall, he had 3 apparently similar servers, configured similarly, but where
> 2 were seeing the problem and the third one not.
> Or was there another difference which he did not tell us about, and where ?
>
>

I'd try to run

cat /proc/sys/crypto/fips_enabled












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

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


Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 21.09.2016 18:49, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Ron,
>
> On 9/21/16 11:58 AM, Roskens, Ronald wrote:
>>> -----Original Message----- From: Christopher Schultz
>>> [mailto:chris@christopherschultz.net] Sent: Wednesday, September
>>> 21, 2016 9:40 AM To: Tomcat Users List Subject: Re: TLS 1.2
>>> Handshake on Tomcat 7.0.39 Getting Internal Error: Key format
>>> must be RAW
>>>
>>
>> <snipped>
>>
>>> 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 :)
>>
>> The resolution says to either disable TLS 1.2 or FIPS mode.
>>
>> The root cause is the PKCS#11 implementation included in Java 7 and
>> 8 does not support TLS 1.2 when in FIPS mode as documented in
>> OpenJDK bug JDK-8029661
>> (https://bugs.openjdk.java.net/browse/JDK-8029661)
>>
>> See also:
>> https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/F
> IPS.html
>
> Thanks
>>
> for posting this.
>
> Good old FIPS: hobbling real security since 1994.
>

Thanks also, but does this explain fully the symptoms seen by the OP ?  As I recall, he 
had 3 apparently similar servers, configured similarly, but where 2 were seeing the 
problem and the third one not.
Or was there another difference which he did not tell us about, and where ?



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


Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ron,

On 9/21/16 11:58 AM, Roskens, Ronald wrote:
>> -----Original Message----- From: Christopher Schultz
>> [mailto:chris@christopherschultz.net] Sent: Wednesday, September
>> 21, 2016 9:40 AM To: Tomcat Users List Subject: Re: TLS 1.2
>> Handshake on Tomcat 7.0.39 Getting Internal Error: Key format
>> must be RAW
>> 
> 
> <snipped>
> 
>> 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 :)
> 
> The resolution says to either disable TLS 1.2 or FIPS mode.
> 
> The root cause is the PKCS#11 implementation included in Java 7 and
> 8 does not support TLS 1.2 when in FIPS mode as documented in
> OpenJDK bug JDK-8029661
> (https://bugs.openjdk.java.net/browse/JDK-8029661)
> 
> See also:
> https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/F
IPS.html

Thanks
> 
for posting this.

Good old FIPS: hobbling real security since 1994.

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

iQIcBAEBCAAGBQJX4ro3AAoJEBzwKT+lPKRYuwMQALHX2Gcr3u5FH40Gb+PwLPK6
X4ZHDaTCIU8SFO8O4CxSAIBtwAyGr9s4KiHBFghthvxflAXZ7X8IBZVG7Ja/q+jM
EADuBgbc5YoPJZSvCU3LcWLU4eugIwT0S6u/B1wdwOOQk7ju6/K5pSk3zhs8SPYC
LcdffnxsfoVDUjNy3EMnI6nNhJx4eaauIlQRMqloq94ldENilurx/5zigvE6i0jd
QAGY8/GXodTL4pTOAbvdjpYBtPkP5obts4iG4YV7YDrVkiBq8UarrqoUKHFceu6k
IRpHo6e2JKGRjHgfn8OQReByzIz3iv5K4GdTvj8LJ1E9nmxAFAvXl8Vk2EEeovNb
PzDpaMpg7wEsz+psszwDTlm1rwZp72XUV/wTpV9Rjb6aJMDzvaVIqAEHmluaPj/2
hqVdkmtQl9dTzbJhKoSUk2eqyooXu25IR+f7wfmVPxjgFLOPCDC1YkrAODJHkAUk
KbP+mSJ6H0+VW6pcIXgfexCqlmzAhKQt3xy/ZNLwEdZZ1z+OJbPsfI0LnSE52TlT
xuZKsQHImJQLXdtBgxAFlk2aLXZz4xq5pJvKdGlDOw/Z5NkvAmU36x8BIbbAALq6
cT4zk77DUGpup0DFOAruKKmhThxP8/rbo53zv2HlNEz6aObANCetH7KMko/Jiu2m
LeDfOCGtPdFFJeKK/RGG
=XRch
-----END PGP SIGNATURE-----

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


RE: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by "Roskens, Ronald" <Ro...@biworldwide.com>.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Wednesday, September 21, 2016 9:40 AM
> To: Tomcat Users List
> Subject: Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key
> format must be RAW 
>

<snipped>

> 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 :)

The resolution says to either disable TLS 1.2 or FIPS mode.

The root cause is the PKCS#11 implementation included in Java 7 and 8 does not support TLS 1.2 when in FIPS mode as documented in OpenJDK bug JDK-8029661 (https://bugs.openjdk.java.net/browse/JDK-8029661)

See also: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/FIPS.html

Ron

This e-mail message is being sent solely for use by the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by phone or reply by e-mail, delete the original message and destroy all copies. Thank you.

Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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


Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 :)

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

iQIcBAEBCAAGBQJX4pvUAAoJEBzwKT+lPKRY3ycP/RTfuy2wwbDxUcea4H50MSdW
NA9nsVyQpHg0bp1ONF5uuW1zBK9752inZPh7CPU79PcuRzHUoTKvxsHYxYOvM7uo
7p1ufBNmkMySK1aI5gUZJklKnS7va2npMGCuU6DLauRB592Dg82UOISHLohjnWum
hkIvfJmduJezr4Lcjt6Ivje8qB83Up44cA0ngGcRVYX4bmpFo8JlQa1fPFg/Ren9
PHD6HSw9dOzib/h3cOXNS95UReyCRGjZz8hG/+BED26cp8+WBri5GwQGGGoZ0/19
H2JZvvNXB1WaTcLM20VuQcE0qv0WKG5d8lVRyP0ilJ+AWGhR2Xai4RrQxdzlpUZS
7Z++A9g0DWai1Xev/AXvk8es89MzSxNw0ltNPf8uVDXwK2PbyQEeQConXUF056TT
TDtmuXQETwRGKr+3lKEYOnUc6eh5Cwu7eKOHBMAESjaUYt1G/mNCJYDiGWdLA/N5
+HQIMiqannnVFq1I7uxzs7g9gdd1eta5QhQm1adMZNKO7dgeewjn1oiZ9IbSwMZV
WJPJNtsupPkR+D0AzNVg3+uvg9W+7lGA48CfV1qvujE7thQXn0Q90jBCBZpxxJYM
E0HYx3OijLC0xEQuBRioK5dV0T+dl1EEvNx9tzTAQi4Pd5OcG2xiXDRk/3vMs7eU
NxeTCeNhRBqznkK59EYn
=CLl+
-----END PGP SIGNATURE-----

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


Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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.properties -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.properties -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 ?

>
>>>
>>>
>>>> When we accessed the web app on Production server, we were able to
>>>> connect and connected over TLS 1.2 (as expected). However, when we
>>>> accessed the web app on both Staging servers we were able to connect,
>>>> but it was connected over TLS 1.1 not TLS 1.2 as TLS
>>>> 1.2 handshake failed and server sent an Alert (Level: Fatal,
>>>> Description: Internal
>>>> Error) response.
>>>>
>>>>
>>>> We enabled SSL debugging on Tomcat and we saw Tomcat threw
>>>> InvalidAlgorithmParameterException exception in catalina.out as shown
>> below:
>>>>
>>>>
>>>> http-bio-8443-exec-1, READ: TLSv1.2 Handshake, length = 70
>>>> *** ECDHClientKeyExchange
>>>> ECDH Public value:  { 4, 245, 39, 156, 56, 88, 62, 108, 141, 237, 93,
>>>> 240, 210, 228, 91, 60, 14, 109, 138, 121, 126, 100, 36, 194, 93, 101,
>>>> 131, 119, 120, 57, 120, 222, 73, 123, 122, 218, 253, 91, 170, 240,
>>>> 251, 73, 214, 29, 192, 234, 109, 189, 40, 249, 161, 176, 172, 179,
>>>> 36, 162, 229, 69, 160, 221, 242, 53, 100, 34, 215 } SESSION KEYGEN:
>>>>
>>>> PreMaster Secret:
>>>> (key bytes not available)
>>>> RSA master secret generation error:
>>>> java.security.InvalidAlgorithmParameterException: Key format must be
>> RAW
>>>>           at
>>>> com.sun.crypto.provider.TlsMasterSecretGenerator.engineInit(TlsMaster
>>>> SecretGenerator.java:67)
>>>>
>>>>           at javax.crypto.KeyGenerator.init(KeyGenerator.java:454)
>>>>           at javax.crypto.KeyGenerator.init(KeyGenerator.java:430)
>>>>           at sun.security.ssl.Handshaker.calculateMasterSecret(Unknown
>> Source)
>>>>           at sun.security.ssl.Handshaker.calculateKeys(Unknown Source)
>>>>           at sun.security.ssl.ServerHandshaker.processMessage(Unknown
>> Source)
>>>>           at sun.security.ssl.Handshaker.processLoop(Unknown Source)
>>>>           at sun.security.ssl.Handshaker.process_record(Unknown Source)
>>>>           at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
>>>>           at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown
>> Source)
>>>>           at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
>>>>           at sun.security.ssl.SSLSocketImpl.getSession(Unknown Source)
>>>>           at
>>>>
>> org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFac
>> tory.java:215)
>>>>           at
>>>>
>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.ja
>> va:298)
>>>>           at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
>> Source)
>>>>           at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>> Source)
>>>>           at java.lang.Thread.run(Unknown Source)
>>>> http-bio-8443-exec-1, handling exception:
>> java.security.ProviderException:
>>>> java.security.InvalidAlgorithmParameterException: Key format must be
>>>> RAW %% Invalidated:  [Session-1,
>>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
>>>> http-bio-8443-exec-1, SEND TLSv1.2 ALERT:  fatal, description =
>>>> internal_error http-bio-8443-exec-1, WRITE: TLSv1.2 Alert, length = 2
>>>> [Raw write]: length = 7
>>>> 0000: 15 03 03 00 02 02 50                               ......P
>>>> http-bio-8443-exec-1, called closeSocket() http-bio-8443-exec-1,
>>>> IOException in getSession():  javax.net.ssl.SSLException:
>>>> java.security.ProviderException:
>>>> java.security.InvalidAlgorithmParameterException: Key format must be
>>>> RAW http-bio-8443-exec-1, called close() http-bio-8443-exec-1, called
>>>> closeInternal(true)
>>>>
>>>>
>>>>
>>>> Below is the server.xml configuration we have on all servers:
>>>>
>>>>
>>>>       <Connector port="8443"
>> protocol="org.apache.coyote.http11.Http11Protocol"
>>>>
>>>>           SSLEnabled="true"
>>>>           scheme="https"
>>>>           secure="true"
>>>>           clientAuth="false"
>>>>           sslProtocol="TLS"
>>>>
>>>>           maxHttpHeaderSize="8192"
>>>>           maxThreads="150"
>>>>           minSpareThreads="25"
>>>>           enableLookups="false"
>>>>           disableUploadTimeout="true"
>>>>           acceptCount="100"
>>>>           useBodyEncodingForURI="true"
>>>>
>>>>           keystoreType="pkcs12"
>>>>           keystoreFile="/path/to/keystore/.filename.p12"
>>>>           keystorePass="<snip>" />
>>>>
>>>>
>>>>
>>>> Any idea why Tomcat not able to do TLS 1.2 handshake and throwing
>>>> "Key format must be RAW" exception? Did we miss anything here?
>>>>
>>>>
>>>>
>>>> Thanks for your help,
>>>>
>>>> Don
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


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


RE: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by Dono Harjanto <do...@deviceauthority.com>.
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.properties -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.properties -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.

> >
> >
> >> When we accessed the web app on Production server, we were able to
> >> connect and connected over TLS 1.2 (as expected). However, when we
> >> accessed the web app on both Staging servers we were able to connect,
> >> but it was connected over TLS 1.1 not TLS 1.2 as TLS
> >> 1.2 handshake failed and server sent an Alert (Level: Fatal,
> >> Description: Internal
> >> Error) response.
> >>
> >>
> >> We enabled SSL debugging on Tomcat and we saw Tomcat threw
> >> InvalidAlgorithmParameterException exception in catalina.out as shown
> below:
> >>
> >>
> >> http-bio-8443-exec-1, READ: TLSv1.2 Handshake, length = 70
> >> *** ECDHClientKeyExchange
> >> ECDH Public value:  { 4, 245, 39, 156, 56, 88, 62, 108, 141, 237, 93,
> >> 240, 210, 228, 91, 60, 14, 109, 138, 121, 126, 100, 36, 194, 93, 101,
> >> 131, 119, 120, 57, 120, 222, 73, 123, 122, 218, 253, 91, 170, 240,
> >> 251, 73, 214, 29, 192, 234, 109, 189, 40, 249, 161, 176, 172, 179,
> >> 36, 162, 229, 69, 160, 221, 242, 53, 100, 34, 215 } SESSION KEYGEN:
> >>
> >> PreMaster Secret:
> >> (key bytes not available)
> >> RSA master secret generation error:
> >> java.security.InvalidAlgorithmParameterException: Key format must be
> RAW
> >>          at
> >> com.sun.crypto.provider.TlsMasterSecretGenerator.engineInit(TlsMaster
> >> SecretGenerator.java:67)
> >>
> >>          at javax.crypto.KeyGenerator.init(KeyGenerator.java:454)
> >>          at javax.crypto.KeyGenerator.init(KeyGenerator.java:430)
> >>          at sun.security.ssl.Handshaker.calculateMasterSecret(Unknown
> Source)
> >>          at sun.security.ssl.Handshaker.calculateKeys(Unknown Source)
> >>          at sun.security.ssl.ServerHandshaker.processMessage(Unknown
> Source)
> >>          at sun.security.ssl.Handshaker.processLoop(Unknown Source)
> >>          at sun.security.ssl.Handshaker.process_record(Unknown Source)
> >>          at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
> >>          at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown
> Source)
> >>          at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
> >>          at sun.security.ssl.SSLSocketImpl.getSession(Unknown Source)
> >>          at
> >>
> org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFac
> tory.java:215)
> >>          at
> >>
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.ja
> va:298)
> >>          at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
> >>          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
> >>          at java.lang.Thread.run(Unknown Source)
> >> http-bio-8443-exec-1, handling exception:
> java.security.ProviderException:
> >> java.security.InvalidAlgorithmParameterException: Key format must be
> >> RAW %% Invalidated:  [Session-1,
> >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
> >> http-bio-8443-exec-1, SEND TLSv1.2 ALERT:  fatal, description =
> >> internal_error http-bio-8443-exec-1, WRITE: TLSv1.2 Alert, length = 2
> >> [Raw write]: length = 7
> >> 0000: 15 03 03 00 02 02 50                               ......P
> >> http-bio-8443-exec-1, called closeSocket() http-bio-8443-exec-1,
> >> IOException in getSession():  javax.net.ssl.SSLException:
> >> java.security.ProviderException:
> >> java.security.InvalidAlgorithmParameterException: Key format must be
> >> RAW http-bio-8443-exec-1, called close() http-bio-8443-exec-1, called
> >> closeInternal(true)
> >>
> >>
> >>
> >> Below is the server.xml configuration we have on all servers:
> >>
> >>
> >>      <Connector port="8443"
> protocol="org.apache.coyote.http11.Http11Protocol"
> >>
> >>          SSLEnabled="true"
> >>          scheme="https"
> >>          secure="true"
> >>          clientAuth="false"
> >>          sslProtocol="TLS"
> >>
> >>          maxHttpHeaderSize="8192"
> >>          maxThreads="150"
> >>          minSpareThreads="25"
> >>          enableLookups="false"
> >>          disableUploadTimeout="true"
> >>          acceptCount="100"
> >>          useBodyEncodingForURI="true"
> >>
> >>          keystoreType="pkcs12"
> >>          keystoreFile="/path/to/keystore/.filename.p12"
> >>          keystorePass="<snip>" />
> >>
> >>
> >>
> >> Any idea why Tomcat not able to do TLS 1.2 handshake and throwing
> >> "Key format must be RAW" exception? Did we miss anything here?
> >>
> >>
> >>
> >> Thanks for your help,
> >>
> >> Don
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org


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


Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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)

>
>
>> When we accessed the web app on Production server, we were able to connect and connected
>> over TLS 1.2 (as expected). However, when we accessed the web app on both Staging
>> servers we were able to connect, but it was connected over TLS 1.1 not TLS 1.2 as TLS
>> 1.2 handshake failed and server sent an Alert (Level: Fatal, Description: Internal
>> Error) response.
>>
>>
>> We enabled SSL debugging on Tomcat and we saw Tomcat threw
>> InvalidAlgorithmParameterException exception in catalina.out as shown below:
>>
>>
>> http-bio-8443-exec-1, READ: TLSv1.2 Handshake, length = 70
>> *** ECDHClientKeyExchange
>> ECDH Public value:  { 4, 245, 39, 156, 56, 88, 62, 108, 141, 237, 93, 240, 210, 228, 91,
>> 60, 14, 109, 138, 121, 126, 100, 36, 194, 93, 101, 131, 119, 120, 57, 120, 222, 73, 123,
>> 122, 218, 253, 91, 170, 240, 251, 73, 214, 29, 192, 234, 109, 189, 40, 249, 161, 176,
>> 172, 179, 36, 162, 229, 69, 160, 221, 242, 53, 100, 34, 215 }
>> SESSION KEYGEN:
>>
>> PreMaster Secret:
>> (key bytes not available)
>> RSA master secret generation error:
>> java.security.InvalidAlgorithmParameterException: Key format must be RAW
>>          at
>> com.sun.crypto.provider.TlsMasterSecretGenerator.engineInit(TlsMasterSecretGenerator.java:67)
>>
>>          at javax.crypto.KeyGenerator.init(KeyGenerator.java:454)
>>          at javax.crypto.KeyGenerator.init(KeyGenerator.java:430)
>>          at sun.security.ssl.Handshaker.calculateMasterSecret(Unknown Source)
>>          at sun.security.ssl.Handshaker.calculateKeys(Unknown Source)
>>          at sun.security.ssl.ServerHandshaker.processMessage(Unknown Source)
>>          at sun.security.ssl.Handshaker.processLoop(Unknown Source)
>>          at sun.security.ssl.Handshaker.process_record(Unknown Source)
>>          at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
>>          at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
>>          at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
>>          at sun.security.ssl.SSLSocketImpl.getSession(Unknown Source)
>>          at
>> org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:215)
>>          at
>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
>>          at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>>          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>          at java.lang.Thread.run(Unknown Source)
>> http-bio-8443-exec-1, handling exception: java.security.ProviderException:
>> java.security.InvalidAlgorithmParameterException: Key format must be RAW
>> %% Invalidated:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
>> http-bio-8443-exec-1, SEND TLSv1.2 ALERT:  fatal, description = internal_error
>> http-bio-8443-exec-1, WRITE: TLSv1.2 Alert, length = 2
>> [Raw write]: length = 7
>> 0000: 15 03 03 00 02 02 50                               ......P
>> http-bio-8443-exec-1, called closeSocket()
>> http-bio-8443-exec-1, IOException in getSession():  javax.net.ssl.SSLException:
>> java.security.ProviderException: java.security.InvalidAlgorithmParameterException: Key
>> format must be RAW
>> http-bio-8443-exec-1, called close()
>> http-bio-8443-exec-1, called closeInternal(true)
>>
>>
>>
>> Below is the server.xml configuration we have on all servers:
>>
>>
>>      <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
>>
>>          SSLEnabled="true"
>>          scheme="https"
>>          secure="true"
>>          clientAuth="false"
>>          sslProtocol="TLS"
>>
>>          maxHttpHeaderSize="8192"
>>          maxThreads="150"
>>          minSpareThreads="25"
>>          enableLookups="false"
>>          disableUploadTimeout="true"
>>          acceptCount="100"
>>          useBodyEncodingForURI="true"
>>
>>          keystoreType="pkcs12"
>>          keystoreFile="/path/to/keystore/.filename.p12"
>>          keystorePass="<snip>" />
>>
>>
>>
>> Any idea why Tomcat not able to do TLS 1.2 handshake and throwing "Key format must be
>> RAW" exception? Did we miss anything here?
>>
>>
>>
>> Thanks for your help,
>>
>> Don
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


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


Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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 ?


> When we accessed the web app on Production server, we were able to connect and connected over TLS 1.2 (as expected). However, when we accessed the web app on both Staging servers we were able to connect, but it was connected over TLS 1.1 not TLS 1.2 as TLS 1.2 handshake failed and server sent an Alert (Level: Fatal, Description: Internal Error) response.
>
>
> We enabled SSL debugging on Tomcat and we saw Tomcat threw InvalidAlgorithmParameterException exception in catalina.out as shown below:
>
>
> http-bio-8443-exec-1, READ: TLSv1.2 Handshake, length = 70
> *** ECDHClientKeyExchange
> ECDH Public value:  { 4, 245, 39, 156, 56, 88, 62, 108, 141, 237, 93, 240, 210, 228, 91, 60, 14, 109, 138, 121, 126, 100, 36, 194, 93, 101, 131, 119, 120, 57, 120, 222, 73, 123, 122, 218, 253, 91, 170, 240, 251, 73, 214, 29, 192, 234, 109, 189, 40, 249, 161, 176, 172, 179, 36, 162, 229, 69, 160, 221, 242, 53, 100, 34, 215 }
> SESSION KEYGEN:
>
> PreMaster Secret:
> (key bytes not available)
> RSA master secret generation error:
> java.security.InvalidAlgorithmParameterException: Key format must be RAW
>          at com.sun.crypto.provider.TlsMasterSecretGenerator.engineInit(TlsMasterSecretGenerator.java:67)
>          at javax.crypto.KeyGenerator.init(KeyGenerator.java:454)
>          at javax.crypto.KeyGenerator.init(KeyGenerator.java:430)
>          at sun.security.ssl.Handshaker.calculateMasterSecret(Unknown Source)
>          at sun.security.ssl.Handshaker.calculateKeys(Unknown Source)
>          at sun.security.ssl.ServerHandshaker.processMessage(Unknown Source)
>          at sun.security.ssl.Handshaker.processLoop(Unknown Source)
>          at sun.security.ssl.Handshaker.process_record(Unknown Source)
>          at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
>          at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
>          at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
>          at sun.security.ssl.SSLSocketImpl.getSession(Unknown Source)
>          at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:215)
>          at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
>          at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>          at java.lang.Thread.run(Unknown Source)
> http-bio-8443-exec-1, handling exception: java.security.ProviderException: java.security.InvalidAlgorithmParameterException: Key format must be RAW
> %% Invalidated:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
> http-bio-8443-exec-1, SEND TLSv1.2 ALERT:  fatal, description = internal_error
> http-bio-8443-exec-1, WRITE: TLSv1.2 Alert, length = 2
> [Raw write]: length = 7
> 0000: 15 03 03 00 02 02 50                               ......P
> http-bio-8443-exec-1, called closeSocket()
> http-bio-8443-exec-1, IOException in getSession():  javax.net.ssl.SSLException: java.security.ProviderException: java.security.InvalidAlgorithmParameterException: Key format must be RAW
> http-bio-8443-exec-1, called close()
> http-bio-8443-exec-1, called closeInternal(true)
>
>
>
> Below is the server.xml configuration we have on all servers:
>
>
>      <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
>
>          SSLEnabled="true"
>          scheme="https"
>          secure="true"
>          clientAuth="false"
>          sslProtocol="TLS"
>
>          maxHttpHeaderSize="8192"
>          maxThreads="150"
>          minSpareThreads="25"
>          enableLookups="false"
>          disableUploadTimeout="true"
>          acceptCount="100"
>          useBodyEncodingForURI="true"
>
>          keystoreType="pkcs12"
>          keystoreFile="/path/to/keystore/.filename.p12"
>          keystorePass="<snip>" />
>
>
>
> Any idea why Tomcat not able to do TLS 1.2 handshake and throwing "Key format must be RAW" exception? Did we miss anything here?
>
>
>
> Thanks for your help,
>
> Don
>
>


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


RE: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by Dono Harjanto <do...@deviceauthority.com>.
Hi Chris,

> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Monday, September 19, 2016 1:24 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key
> format must be RAW
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Dono,
> 
> On 9/19/16 12:45 PM, 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
> >
> >
> > When we accessed the web app on Production server, we were able to
> > connect and connected over TLS 1.2 (as expected). However, when we
> > accessed the web app on both Staging servers we were able to connect,
> > but it was connected over TLS 1.1 not TLS 1.2 as TLS 1.2 handshake
> > failed and server sent an Alert (Level: Fatal,
> > Description: Internal Error) response.
> >
> >
> > We enabled SSL debugging on Tomcat and we saw Tomcat threw
> > InvalidAlgorithmParameterException exception in catalina.out as shown
> > below:
> >
> >
> > http-bio-8443-exec-1, READ: TLSv1.2 Handshake, length = 70 ***
> > ECDHClientKeyExchange ECDH Public value:  { 4, 245, 39, 156, 56, 88,
> > 62, 108, 141, 237, 93, 240, 210, 228, 91, 60, 14, 109, 138, 121, 126,
> > 100, 36, 194, 93, 101, 131, 119, 120, 57, 120, 222, 73, 123, 122, 218,
> > 253, 91, 170, 240, 251, 73, 214, 29, 192, 234, 109, 189, 40, 249, 161,
> > 176, 172, 179, 36, 162, 229, 69, 160, 221, 242, 53, 100, 34, 215 }
> > SESSION KEYGEN:
> >
> > PreMaster Secret: (key bytes not available) RSA master secret
> > generation error: java.security.InvalidAlgorithmParameterException:
> > Key format must be RAW at
> > com.sun.crypto.provider.TlsMasterSecretGenerator.engineInit(TlsMasterS
> ecretGenerator.java:67)
> >
> >
> at javax.crypto.KeyGenerator.init(KeyGenerator.java:454)
> > at javax.crypto.KeyGenerator.init(KeyGenerator.java:430) at
> > sun.security.ssl.Handshaker.calculateMasterSecret(Unknown Source) at
> > sun.security.ssl.Handshaker.calculateKeys(Unknown Source) at
> > sun.security.ssl.ServerHandshaker.processMessage(Unknown Source) at
> > sun.security.ssl.Handshaker.processLoop(Unknown Source) at
> > sun.security.ssl.Handshaker.process_record(Unknown Source) at
> > sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at
> > sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown
> > Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown
> > Source) at sun.security.ssl.SSLSocketImpl.getSession(Unknown
> > Source) at
> > org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocket
> Factory.java:215)
> >
> >
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.j
> ava:298)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> > Source) at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at
> > java.lang.Thread.run(Unknown Source) http-bio-8443-exec-1, handling
> > exception: java.security.ProviderException:
> > java.security.InvalidAlgorithmParameterException: Key format must be
> > RAW %% Invalidated:  [Session-1,
> > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256] http-bio-8443-exec-1,
> SEND
> > TLSv1.2 ALERT:  fatal, description = internal_error
> > http-bio-8443-exec-1, WRITE: TLSv1.2 Alert, length = 2 [Raw write]:
> > length = 7 0000: 15 03 03 00 02 02 50
> > ......P http-bio-8443-exec-1, called closeSocket()
> > http-bio-8443-exec-1, IOException in getSession():
> > javax.net.ssl.SSLException: java.security.ProviderException:
> > java.security.InvalidAlgorithmParameterException: Key format must be
> > RAW http-bio-8443-exec-1, called close() http-bio-8443-exec-1, called
> > closeInternal(true)
> >
> >
> >
> > Below is the server.xml configuration we have on all servers:
> >
> >
> > <Connector port="8443"
> > protocol="org.apache.coyote.http11.Http11Protocol"
> >
> > SSLEnabled="true" scheme="https" secure="true" clientAuth="false"
> > sslProtocol="TLS"
> >
> > maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25"
> > enableLookups="false" disableUploadTimeout="true"
> > acceptCount="100" useBodyEncodingForURI="true"
> >
> > keystoreType="pkcs12"
> > keystoreFile="/path/to/keystore/.filename.p12"
> > keystorePass="<snip>" />
> >
> >
> >
> > Any idea why Tomcat not able to do TLS 1.2 handshake and throwing "Key
> > format must be RAW" exception? Did we miss anything here?
> 
> 
> I've never seen anything like that before.
> 
> What is the client?

The client is Chrome/FireFox browser, which connected just fine to the web application hosted on Production server (on public internet) and the connection was using TLS 1.2.
Only on staging servers Chrome/FireFox was unable to connect using TLS 1.2, but successfully connected using TLS 1.1.

> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCAAGBQJX4ElgAAoJEBzwKT+lPKRY8aIP/j7QKuhxbxAvJdFXT3/0yMvt
> 5dr1s3Y5Lq8YaeVUjgrcXhWCiC8ncsh5K9PmVW+RWiD1XNMYGLxqo16T+Z6ib
> 9gA
> zhrcvlhO8ClRXXzmsLQztzdncyfAmq3nijQAekJ82pBLN7zgzY+COoNnPox5Ax7
> w
> ZtpNyTFspKCktuEv3hfh9zfhUPaI9c6pW9QSQYshsxmm74TwEyQHg84iXfIKSlA
> V
> iB1G2xPTB6Dsdr4ErSWg7qyeAcm9eQsp7Sv3gJ8jRV788L9L45HqyeIZLvyY7UM
> q
> VtsABiFLpc5EeP+uDjarkNYU1lYPnxrsHpwM1atlqqAtHcGaUV3e0Kxi8dSI3GN
> m
> ffQjFHwjHYitsRiNRp1yMjoMngM+8y+g7dBIIKJHrju7REnq/ztdvYLLyb/pHq5B
> 0J1MREbp+UDBB+wMmrjOhRajjihFsKyXyH7xM/+B0xpWbIG5jOK3JtxJiySXo8
> Cn
> L+3EdINS5ziLjT982jCqOzprXFJEvUhaXo4pdhKszgUqeC0lvclDzox0IYejZ4A2
> khRd9tA+jPypGpMaiM15jVyEmOosX2hXSpBSFqeVDDZNJct3H6Yq6gT+nPssO
> RKC
> /fsRx3BB3WjDKPaXnfgwSmTveoWjZIJsZARPmJBFFxv0FhlsCvDM/IRGGkxsnl
> Wt
> S8iD1ZjrJhK7NQtvUMSM
> =OfA9
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org


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


Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dono,

On 9/19/16 12:45 PM, 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
> 
> 
> When we accessed the web app on Production server, we were able to
> connect and connected over TLS 1.2 (as expected). However, when we
> accessed the web app on both Staging servers we were able to
> connect, but it was connected over TLS 1.1 not TLS 1.2 as TLS 1.2
> handshake failed and server sent an Alert (Level: Fatal,
> Description: Internal Error) response.
> 
> 
> We enabled SSL debugging on Tomcat and we saw Tomcat threw
> InvalidAlgorithmParameterException exception in catalina.out as
> shown below:
> 
> 
> http-bio-8443-exec-1, READ: TLSv1.2 Handshake, length = 70 ***
> ECDHClientKeyExchange ECDH Public value:  { 4, 245, 39, 156, 56,
> 88, 62, 108, 141, 237, 93, 240, 210, 228, 91, 60, 14, 109, 138,
> 121, 126, 100, 36, 194, 93, 101, 131, 119, 120, 57, 120, 222, 73,
> 123, 122, 218, 253, 91, 170, 240, 251, 73, 214, 29, 192, 234, 109,
> 189, 40, 249, 161, 176, 172, 179, 36, 162, 229, 69, 160, 221, 242,
> 53, 100, 34, 215 } SESSION KEYGEN:
> 
> PreMaster Secret: (key bytes not available) RSA master secret
> generation error: java.security.InvalidAlgorithmParameterException:
> Key format must be RAW at
> com.sun.crypto.provider.TlsMasterSecretGenerator.engineInit(TlsMasterS
ecretGenerator.java:67)
>
> 
at javax.crypto.KeyGenerator.init(KeyGenerator.java:454)
> at javax.crypto.KeyGenerator.init(KeyGenerator.java:430) at
> sun.security.ssl.Handshaker.calculateMasterSecret(Unknown Source) 
> at sun.security.ssl.Handshaker.calculateKeys(Unknown Source) at
> sun.security.ssl.ServerHandshaker.processMessage(Unknown Source) at
> sun.security.ssl.Handshaker.processLoop(Unknown Source) at
> sun.security.ssl.Handshaker.process_record(Unknown Source) at
> sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown
> Source) at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown
> Source) at sun.security.ssl.SSLSocketImpl.getSession(Unknown
> Source) at
> org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocket
Factory.java:215)
>
> 
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.j
ava:298)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source) at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
> at java.lang.Thread.run(Unknown Source) http-bio-8443-exec-1,
> handling exception: java.security.ProviderException:
> java.security.InvalidAlgorithmParameterException: Key format must
> be RAW %% Invalidated:  [Session-1,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256] http-bio-8443-exec-1, SEND
> TLSv1.2 ALERT:  fatal, description = internal_error 
> http-bio-8443-exec-1, WRITE: TLSv1.2 Alert, length = 2 [Raw write]:
> length = 7 0000: 15 03 03 00 02 02 50
> ......P http-bio-8443-exec-1, called closeSocket() 
> http-bio-8443-exec-1, IOException in getSession():
> javax.net.ssl.SSLException: java.security.ProviderException:
> java.security.InvalidAlgorithmParameterException: Key format must
> be RAW http-bio-8443-exec-1, called close() http-bio-8443-exec-1,
> called closeInternal(true)
> 
> 
> 
> Below is the server.xml configuration we have on all servers:
> 
> 
> <Connector port="8443"
> protocol="org.apache.coyote.http11.Http11Protocol"
> 
> SSLEnabled="true" scheme="https" secure="true" clientAuth="false" 
> sslProtocol="TLS"
> 
> maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" 
> enableLookups="false" disableUploadTimeout="true" 
> acceptCount="100" useBodyEncodingForURI="true"
> 
> keystoreType="pkcs12" 
> keystoreFile="/path/to/keystore/.filename.p12" 
> keystorePass="<snip>" />
> 
> 
> 
> Any idea why Tomcat not able to do TLS 1.2 handshake and throwing
> "Key format must be RAW" exception? Did we miss anything here?


I've never seen anything like that before.

What is the client?

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

iQIcBAEBCAAGBQJX4ElgAAoJEBzwKT+lPKRY8aIP/j7QKuhxbxAvJdFXT3/0yMvt
5dr1s3Y5Lq8YaeVUjgrcXhWCiC8ncsh5K9PmVW+RWiD1XNMYGLxqo16T+Z6ib9gA
zhrcvlhO8ClRXXzmsLQztzdncyfAmq3nijQAekJ82pBLN7zgzY+COoNnPox5Ax7w
ZtpNyTFspKCktuEv3hfh9zfhUPaI9c6pW9QSQYshsxmm74TwEyQHg84iXfIKSlAV
iB1G2xPTB6Dsdr4ErSWg7qyeAcm9eQsp7Sv3gJ8jRV788L9L45HqyeIZLvyY7UMq
VtsABiFLpc5EeP+uDjarkNYU1lYPnxrsHpwM1atlqqAtHcGaUV3e0Kxi8dSI3GNm
ffQjFHwjHYitsRiNRp1yMjoMngM+8y+g7dBIIKJHrju7REnq/ztdvYLLyb/pHq5B
0J1MREbp+UDBB+wMmrjOhRajjihFsKyXyH7xM/+B0xpWbIG5jOK3JtxJiySXo8Cn
L+3EdINS5ziLjT982jCqOzprXFJEvUhaXo4pdhKszgUqeC0lvclDzox0IYejZ4A2
khRd9tA+jPypGpMaiM15jVyEmOosX2hXSpBSFqeVDDZNJct3H6Yq6gT+nPssORKC
/fsRx3BB3WjDKPaXnfgwSmTveoWjZIJsZARPmJBFFxv0FhlsCvDM/IRGGkxsnlWt
S8iD1ZjrJhK7NQtvUMSM
=OfA9
-----END PGP SIGNATURE-----

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


Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by Daniel Savard <da...@gmail.com>.
2016-09-22 6:16 GMT-04:00 André Warnier (tomcat) <aw...@ice-sa.com>:

> Dono,
>
> Ok, this is  really a long shot, and I really do not know what I am
> talking about..
>
> I just want to point out that in the course of doing some searches on the
> WWW with keywords related to your issue, I seemed several times to come
> across articles which were referring to some restrictions in Java
> cryptography, having to do with US export regulations (cryptography being
> an area submitted in part to such rules).
> In my limited understanding, the apparent gist of it seemed to be that
> - for systems based in the US, by default some java-cryptographic modules
> allow some encryption methods (or key strengths etc.)
> - while for non-US-based systems some of these methods/strengths are by
> default disabled
> To re-enable these methods, one has to either change some java parameters
> (at the risk of falling foul of said export restrictions), or replace some
> standard underlying libraries, by other similar ones developed outside of
> the US.
> And, in some cases, such "similar" libraries may throw exceptions where
> the standard ones would not.
> All of the above to take with a grain of salt, considering my almost total
> lack of knowledge in the matter.
> But, considering that your production system may be one case, and your
> staging systems another, and considering that so far nobody seems to have
> found the ultimate answer to your problem, this could be an area to
> investigate.
>
> I will make another wild guess : a lot of people on this list probably
> either work predominantly on US-based systems, or don't know about such
> restrictions, or are unfamilar with them, and for such reasons have
> probably never encountered the kind of issue which you mention.  So it is
> probably no wonder that everyone seems to be a bit in the dark (including
> myself).
>
>
Not exactly that. By default, Java is shipped or distributed without the
Unlimited Strength Policy Files (you have to replace 2 jar in
jre/lib/security). The reason they are not installed by default being they
are not legal everywhere. If it is legal in your country, you can simply
install them and you have exactly the same libraries and algorithms as
those who are having by default an unrestricted installation. For Oracle
JDK 1.8, you can download the files from this URL:
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

I have many Tomcat instances doing TLSv1.2 without problem. I only
encountered problems with Tomcat 7 on one server for a still unknown reason
and very unlikely related to Java itself.

I have over 70 Tomcat instances all running TLSv1.2 and in usage daily
7/24. I am using the Unlimited Strength Juristiction Policy Files for Java
8.

Regards,

Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
Dono,

On 22.09.2016 01:06, Igor Cicimov wrote:
> On 20 Sep 2016 2:45 am, "Dono Harjanto" <do...@deviceauthority.com> 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
>>
>>
>> When we accessed the web app on Production server, we were able to
> connect and connected over TLS 1.2 (as expected). However, when we accessed
> the web app on both Staging servers we were able to connect, but it was
> connected over TLS 1.1 not TLS 1.2 as TLS 1.2 handshake failed and server
> sent an Alert (Level: Fatal, Description: Internal Error) response.
>>
>>
>> We enabled SSL debugging on Tomcat and we saw Tomcat threw
> InvalidAlgorithmParameterException exception in catalina.out as shown below:
>>
>>
>> http-bio-8443-exec-1, READ: TLSv1.2 Handshake, length = 70
>> *** ECDHClientKeyExchange
>> ECDH Public value:  { 4, 245, 39, 156, 56, 88, 62, 108, 141, 237, 93,
> 240, 210, 228, 91, 60, 14, 109, 138, 121, 126, 100, 36, 194, 93, 101, 131,
> 119, 120, 57, 120, 222, 73, 123, 122, 218, 253, 91, 170, 240, 251, 73, 214,
> 29, 192, 234, 109, 189, 40, 249, 161, 176, 172, 179, 36, 162, 229, 69, 160,
> 221, 242, 53, 100, 34, 215 }
>> SESSION KEYGEN:
>>
>> PreMaster Secret:
>> (key bytes not available)
>> RSA master secret generation error:
>> java.security.InvalidAlgorithmParameterException: Key format must be RAW
>>          at
> com.sun.crypto.provider.TlsMasterSecretGenerator.engineInit(TlsMasterSecretGenerator.java:67)
>>          at javax.crypto.KeyGenerator.init(KeyGenerator.java:454)
>>          at javax.crypto.KeyGenerator.init(KeyGenerator.java:430)
>>          at sun.security.ssl.Handshaker.calculateMasterSecret(Unknown
> Source)
>>          at sun.security.ssl.Handshaker.calculateKeys(Unknown Source)
>>          at sun.security.ssl.ServerHandshaker.processMessage(Unknown
> Source)
>>          at sun.security.ssl.Handshaker.processLoop(Unknown Source)
>>          at sun.security.ssl.Handshaker.process_record(Unknown Source)
>>          at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
>>          at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown
> Source)
>>          at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
>>          at sun.security.ssl.SSLSocketImpl.getSession(Unknown Source)
>>          at
> org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:215)
>>          at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
>>          at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
>>          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
>>          at java.lang.Thread.run(Unknown Source)
>> http-bio-8443-exec-1, handling exception:
> java.security.ProviderException:
> java.security.InvalidAlgorithmParameterException: Key format must be RAW
>> %% Invalidated:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
>> http-bio-8443-exec-1, SEND TLSv1.2 ALERT:  fatal, description =
> internal_error
>> http-bio-8443-exec-1, WRITE: TLSv1.2 Alert, length = 2
>> [Raw write]: length = 7
>> 0000: 15 03 03 00 02 02 50                               ......P
>> http-bio-8443-exec-1, called closeSocket()
>> http-bio-8443-exec-1, IOException in getSession():
> javax.net.ssl.SSLException: java.security.ProviderException:
> java.security.InvalidAlgorithmParameterException: Key format must be RAW
>> http-bio-8443-exec-1, called close()
>> http-bio-8443-exec-1, called closeInternal(true)
>>
>>
>>
>> Below is the server.xml configuration we have on all servers:
>>
>>
>>      <Connector port="8443"
> protocol="org.apache.coyote.http11.Http11Protocol"
>>
>>          SSLEnabled="true"
>>          scheme="https"
>>          secure="true"
>>          clientAuth="false"
>>          sslProtocol="TLS"
>>
>>          maxHttpHeaderSize="8192"
>>          maxThreads="150"
>>          minSpareThreads="25"
>>          enableLookups="false"
>>          disableUploadTimeout="true"
>>          acceptCount="100"
>>          useBodyEncodingForURI="true"
>>
>>          keystoreType="pkcs12"
>>          keystoreFile="/path/to/keystore/.filename.p12"
>>          keystorePass="<snip>" />
>>
>>
>>
>> Any idea why Tomcat not able to do TLS 1.2 handshake and throwing "Key
> format must be RAW" exception? Did we miss anything here?
>>
>>
>>
>> Thanks for your help,
>>
>> Don
>>
> This sounds like something specific to pkcs can you convert to jks
> keystore?
>

Ok, this is  really a long shot, and I really do not know what I am talking about..

I just want to point out that in the course of doing some searches on the WWW with 
keywords related to your issue, I seemed several times to come across articles which were 
referring to some restrictions in Java cryptography, having to do with US export 
regulations (cryptography being an area submitted in part to such rules).
In my limited understanding, the apparent gist of it seemed to be that
- for systems based in the US, by default some java-cryptographic modules allow some 
encryption methods (or key strengths etc.)
- while for non-US-based systems some of these methods/strengths are by default disabled
To re-enable these methods, one has to either change some java parameters (at the risk of 
falling foul of said export restrictions), or replace some standard underlying libraries, 
by other similar ones developed outside of the US.
And, in some cases, such "similar" libraries may throw exceptions where the standard ones 
would not.
All of the above to take with a grain of salt, considering my almost total lack of 
knowledge in the matter.
But, considering that your production system may be one case, and your staging systems 
another, and considering that so far nobody seems to have found the ultimate answer to 
your problem, this could be an area to investigate.

I will make another wild guess : a lot of people on this list probably either work 
predominantly on US-based systems, or don't know about such restrictions, or are unfamilar 
with them, and for such reasons have probably never encountered the kind of issue which 
you mention.  So it is probably no wonder that everyone seems to be a bit in the dark 
(including myself).


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


Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

Posted by Igor Cicimov <ic...@gmail.com>.
On 20 Sep 2016 2:45 am, "Dono Harjanto" <do...@deviceauthority.com> 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
>
>
> When we accessed the web app on Production server, we were able to
connect and connected over TLS 1.2 (as expected). However, when we accessed
the web app on both Staging servers we were able to connect, but it was
connected over TLS 1.1 not TLS 1.2 as TLS 1.2 handshake failed and server
sent an Alert (Level: Fatal, Description: Internal Error) response.
>
>
> We enabled SSL debugging on Tomcat and we saw Tomcat threw
InvalidAlgorithmParameterException exception in catalina.out as shown below:
>
>
> http-bio-8443-exec-1, READ: TLSv1.2 Handshake, length = 70
> *** ECDHClientKeyExchange
> ECDH Public value:  { 4, 245, 39, 156, 56, 88, 62, 108, 141, 237, 93,
240, 210, 228, 91, 60, 14, 109, 138, 121, 126, 100, 36, 194, 93, 101, 131,
119, 120, 57, 120, 222, 73, 123, 122, 218, 253, 91, 170, 240, 251, 73, 214,
29, 192, 234, 109, 189, 40, 249, 161, 176, 172, 179, 36, 162, 229, 69, 160,
221, 242, 53, 100, 34, 215 }
> SESSION KEYGEN:
>
> PreMaster Secret:
> (key bytes not available)
> RSA master secret generation error:
> java.security.InvalidAlgorithmParameterException: Key format must be RAW
>         at
com.sun.crypto.provider.TlsMasterSecretGenerator.engineInit(TlsMasterSecretGenerator.java:67)
>         at javax.crypto.KeyGenerator.init(KeyGenerator.java:454)
>         at javax.crypto.KeyGenerator.init(KeyGenerator.java:430)
>         at sun.security.ssl.Handshaker.calculateMasterSecret(Unknown
Source)
>         at sun.security.ssl.Handshaker.calculateKeys(Unknown Source)
>         at sun.security.ssl.ServerHandshaker.processMessage(Unknown
Source)
>         at sun.security.ssl.Handshaker.processLoop(Unknown Source)
>         at sun.security.ssl.Handshaker.process_record(Unknown Source)
>         at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
>         at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown
Source)
>         at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
>         at sun.security.ssl.SSLSocketImpl.getSession(Unknown Source)
>         at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:215)
>         at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
Source)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
>         at java.lang.Thread.run(Unknown Source)
> http-bio-8443-exec-1, handling exception:
java.security.ProviderException:
java.security.InvalidAlgorithmParameterException: Key format must be RAW
> %% Invalidated:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
> http-bio-8443-exec-1, SEND TLSv1.2 ALERT:  fatal, description =
internal_error
> http-bio-8443-exec-1, WRITE: TLSv1.2 Alert, length = 2
> [Raw write]: length = 7
> 0000: 15 03 03 00 02 02 50                               ......P
> http-bio-8443-exec-1, called closeSocket()
> http-bio-8443-exec-1, IOException in getSession():
javax.net.ssl.SSLException: java.security.ProviderException:
java.security.InvalidAlgorithmParameterException: Key format must be RAW
> http-bio-8443-exec-1, called close()
> http-bio-8443-exec-1, called closeInternal(true)
>
>
>
> Below is the server.xml configuration we have on all servers:
>
>
>     <Connector port="8443"
protocol="org.apache.coyote.http11.Http11Protocol"
>
>         SSLEnabled="true"
>         scheme="https"
>         secure="true"
>         clientAuth="false"
>         sslProtocol="TLS"
>
>         maxHttpHeaderSize="8192"
>         maxThreads="150"
>         minSpareThreads="25"
>         enableLookups="false"
>         disableUploadTimeout="true"
>         acceptCount="100"
>         useBodyEncodingForURI="true"
>
>         keystoreType="pkcs12"
>         keystoreFile="/path/to/keystore/.filename.p12"
>         keystorePass="<snip>" />
>
>
>
> Any idea why Tomcat not able to do TLS 1.2 handshake and throwing "Key
format must be RAW" exception? Did we miss anything here?
>
>
>
> Thanks for your help,
>
> Don
>
This sounds like something specific to pkcs can you convert to jks
keystore?