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