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

[Daniel Savard]

2016-09-22 6:16 GMT-04:00 André Warnier (tomcat) :

> 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

[tomcat]

Dono,

On 22.09.2016 01:06, Igor Cicimov wrote:

On 20 Sep 2016 2:45 am, "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(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
: 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:


 
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="" />



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 

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

[Igor Cicimov]

On 20 Sep 2016 2:45 am, "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(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
> : 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:
>
>
> 
> 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="" />
>
>
>
> 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?

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

[Dono Harjanto]

Jose,

> -Original Message-
> From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> Sent: Wednesday, September 21, 2016 11:46 AM
> To: Tomcat Users List 
> 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) :
> > 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:ch...@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
> >>>>
> >>>




> >
> > 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-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

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

[Dono Harjanto]

Ron,

> -Original Message-
> From: André Warnier (tomcat) [mailto:a...@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:ch...@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
> >>>
> >>
> >> 
> >>
> >>> 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

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

[Jose María Zaragoza]

2016-09-21 19:16 GMT+02:00 André Warnier (tomcat) :
> 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:ch...@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
>>>>
>>>
>>> 
>>>
>>>> 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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

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

[tomcat]

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:ch...@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






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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ron,

On 9/21/16 11:58 AM, Roskens, Ronald wrote:
>> -Original Message- From: Christopher Schultz
>> [mailto:ch...@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
>> 
> 
> 
> 
>> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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

[Roskens, Ronald]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@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 
>



> 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

[tomcat]

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: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
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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

[Christopher Schultz]

-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: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
>>> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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

[tomcat]

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 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(U

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

[Dono Harjanto]

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

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

[tomcat]

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


 



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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




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

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

[tomcat]

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


 



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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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

[Dono Harjanto]

Hi Chris,

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Monday, September 19, 2016 1:24 PM
> To: Tomcat Users List 
> 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 : 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:
> >
> >
> >  > 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"
>

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

[Christopher Schultz]

-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 : 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:
> 
> 
>  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="" />
> 
> 
> 
> 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

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

[Dono Harjanto]

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






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