RE: log4j2 configuration in tomcat 8.5.5

[Chen Levy]

Bill,

From: Mark Thomas
Sent: Wednesday, September 21, 2016 17:58
To: Tomcat Users List
Subject: Re: log4j2 configuration in tomcat 8.5.5

On 21/09/2016 22:49, Bill Phillips wrote:
> My team has elected me to upgrade Tomcat from 7.X to 8.5.5+ on our very
> old and very large web application.
> 
> Under Tomcat 7.x, this application uses the tomcat-juli-adapters to replace
> JULI with log4j1.16. Worked like a charm for years.
> 
> 
> Under Tomcat 8.5.5, I'm getting exceptions such as:
>    java.lang.NoClassDefFoundError: org/apache/juli/WebappProperties
> 
> 
> Googling this led me to the discovery that log4j1.x support via
> tomcat-juli-adapters was
> discontinued in Tomcat 8.5, as described here:
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58588
> 
> 
> My understanding is that JULI can be replaced by log4j2 without the
> adapters,
> but I cannot find a description on how to do this.
> 
> 
> Can anyone describe to me how this is done?

https://logging.apache.org/log4j/log4j-2.6.1/log4j-jul/index.html

should point you in the right direction.

Mark


> 
> 
> It is no longer covered in the user documentation as it was on earlier
> versions:
> 
> https://tomcat.apache.org/tomcat-8.5-doc/logging.html
> 
> 
> 
> Thanks,
> 
> Bill
> 

You can read about how I configured my tomcat 8.5.4 to use log4j2 here:
http://mail-archives.apache.org/mod_mbox/tomcat-users/201607.mbox/%3CBAY406-EAS165A578E6D90447E4CC9B0B96010%40phx.gbl%3E
Chen


-
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

[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: log4j2 configuration in tomcat 8.5.5

[Mark Thomas]

On 21/09/2016 22:49, Bill Phillips wrote:
> My team has elected me to upgrade Tomcat from 7.X to 8.5.5+ on our very
> old and very large web application.
> 
> Under Tomcat 7.x, this application uses the tomcat-juli-adapters to replace
> JULI with log4j1.16. Worked like a charm for years.
> 
> 
> Under Tomcat 8.5.5, I'm getting exceptions such as:
>java.lang.NoClassDefFoundError: org/apache/juli/WebappProperties
> 
> 
> Googling this led me to the discovery that log4j1.x support via
> tomcat-juli-adapters was
> discontinued in Tomcat 8.5, as described here:
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58588
> 
> 
> My understanding is that JULI can be replaced by log4j2 without the
> adapters,
> but I cannot find a description on how to do this.
> 
> 
> Can anyone describe to me how this is done?

https://logging.apache.org/log4j/log4j-2.6.1/log4j-jul/index.html

should point you in the right direction.

Mark


> 
> 
> It is no longer covered in the user documentation as it was on earlier
> versions:
> 
> https://tomcat.apache.org/tomcat-8.5-doc/logging.html
> 
> 
> 
> Thanks,
> 
> Bill
> 


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

log4j2 configuration in tomcat 8.5.5

[Bill Phillips]

My team has elected me to upgrade Tomcat from 7.X to 8.5.5+ on our very
old and very large web application.

Under Tomcat 7.x, this application uses the tomcat-juli-adapters to replace
JULI with log4j1.16. Worked like a charm for years.


Under Tomcat 8.5.5, I'm getting exceptions such as:
   java.lang.NoClassDefFoundError: org/apache/juli/WebappProperties


Googling this led me to the discovery that log4j1.x support via
tomcat-juli-adapters was
discontinued in Tomcat 8.5, as described here:

https://bz.apache.org/bugzilla/show_bug.cgi?id=58588


My understanding is that JULI can be replaced by log4j2 without the
adapters,
but I cannot find a description on how to do this.


Can anyone describe to me how this is done?


It is no longer covered in the user documentation as it was on earlier
versions:

https://tomcat.apache.org/tomcat-8.5-doc/logging.html



Thanks,

Bill

RE: AT WITS END regarding JVM arguments

[Jeffrey Janner]

Sorry for reviving an old thread, but this one caught my eye and I just had to 
make some, admittedly off-topic, comments per the concept of assumptions that 
pervaded a number of the posts here.

1) Having worked with all manner of IBM systems, as well as some environments 
you guys probably never heard of, why anyone would assume that the way you do 
it in an IBM environment is the way you would do it anywhere else is beyond me. 
 Heck, it often doesn't work the same way going from one IBM environment to 
another.  (obligatory IBM dig here)

2) Trying to implement something in the Windows environment, I would assume 
that someone would go ahead and use the fine Windows installer that someone has 
been kind enough to create and maintain over the years -- instead of installing 
from the zip file.  But then again, people on this list keep proving me wrong 
on this point.

3) Assuming something works on Windows, or any Microsoft implementation, the 
same way it works in other environments is also beyond me (obligatory Microsoft 
dig here)

4) Someone beginning to work in a new environment would read all available 
documentation on said environment as well as the related documentation of the 
application they wish to use that specifically targets that environment.  But 
that takes time, and with the sorry state of documentation these days, or lack 
thereof, it doesn't really surprise me that someone wouldn't.  Pretty soon, we 
will be at the other end of the spectrum from the old IBM 360/370 days, where 
documentation was not only voluminous, but also incomprehensible.  That end of 
the spectrum ends with "completely non-existent, good luck reading the source 
code".

It's been one of those weeks, and I had to get that off my chest.  I've been in 
this industry since 1982, and the only thing that's really changed is the 
names.  That and we can really mess things up much faster now.

Jeff



> -Original Message-
> From: James H. H. Lampert [mailto:jam...@touchtonecorp.com]
> Sent: Thursday, September 08, 2016 3:49 PM
> To: Tomcat Users List 
> Subject: Re: AT WITS END regarding JVM arguments
> 
> On 9/8/16, 12:23 PM, Christopher Schultz wrote:
> 
> > Would you care to create an account on the Tomcat Wiki[1] and post
> > your CL program? It may help someone else running in similar
> > environments. In fact, if you want to write-up a whole page about
> > "Running Tomcat on IBM Midrange", you could include that as well as
> > any other nuggets you've collected throughout the years.
> 
> Hmm. Looks like there are scant resources there for Tomcat on Midrange.
> (I bookmarked a page at mysamplecode.com that was very helpful with my
> first few installations.)
> 
> I now have a Tomcat Wiki account, but it appears I need to request
> posting privileges (apparently via this very list?) in order to receive
> them.
> 
> I'm enrolled as "JamesLampert"; I'll see what I can put together offline
> until I'm informed that I have posting privileges on the Wiki.
> 
> --
> JHHL
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Apache TomCat 5.5

[Jeffrey Janner]

Mary -
First, sorry for the top-post.

I noticed in your original post that you have upgraded to the latest Java 8, 
and nearly latest Windows version (at least new than the release available when 
Tomcat 5.5 was first available).  I don't understand why you can't just go 
ahead and upgrade to the latest Tomcat 8 or 8.5 implementation.  As others have 
said, it is quite likely that your application will run just fine.
Without more details of your exact implementation environment, I can't give 
full advice, but here are some things to take into account:

1) If you are terminating SSL at the IIS7 client interface, then that is where 
you need to enable HSTS. It only needs to be on the IIS7-Tomcat conversation if 
that is also using SSL on its linkage (not normally needed for an internal 
network, but your requirements may specify otherwise).  Strip it out of headers 
on the way to Tomcat and add it back on the way to client if necessary.

2) When going from such an old Version of Tomcat to a newer one, be aware that 
Tomcat configuration files and options HAVE changed.  You cannot just copy 
server.xml, context.xml, etc. files from the old version to the new.  You must 
migrate your settings to the new versions.  This is not that difficult or 
time-consuming, but it is best to do this manually.

3) Beware of any changes to provided valves/filters that you rely on.  Changes 
to those in new versions may require you to handle them differently.

4) Do this all in a test/dev environment, possibly several times, before even 
thinking about changing production.

5) If the addition of an additional/unknown HTTP header is causing problems 
with your backend processing, then you have more problems than you think you 
do. You application is in violation of the most basic tenets of the HTTP 
protocol stack, as those headers should just be ignored according to the 
protocol.  Your application may stop working correctly in the next few months 
even without you doing anything to your current setup.

Respectfully,
Jeff


> -Original Message-
> From: Pham, Mary (NIH/OD/ORS) [E] [mailto:maryp...@mail.nih.gov]
> Sent: Wednesday, September 21, 2016 9:52 AM
> To: 'Tomcat Users List' 
> Subject: RE: Apache TomCat 5.5
> 
> Thank you.  Chris, Chuck, Andre, Mark who had answered and I've done
> this far.
> My report.
> - I installed the "URL rewrite" module on IIS 7.  To make short, it
> worked.  http to https redirected then enforced hsts on the IIS site.
> - but broke all the scripts run on Tomcat due to Strick Transport
> Security when HTTPS.
> - so I have to disable in/outbound of URL rewrite.
> Back to square one.  We will not be able to upgrade Tomcat at this time.
> 
> Please help.
> 
> -Mary
> 
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Thursday, September 15, 2016 11:01 AM
> To: Tomcat Users List 
> Subject: Re: Apache TomCat 5.5
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> André,
> 
> On 9/14/16 7:04 PM, André Warnier (tomcat) wrote:
> > Mary, have a look here :
> > http://tomcat.apache.org/whichversion.html Tomcat 5.5 was first
> > released about 10 years ago, and the last modification to it was in
> > 2012. The current "stable" version is Tomcat 8.5.5.
> >
> > For Open Source and free software such as Apache Tomcat, that means
> > that your chances of getting support and help for such an old version
> > are really not good, because most of the people which would be able to
> > help you probably do not run that version anywhere anymore. Even the
> > documentation is not directly available on-line anymore.
> >
> > Regarding your particular issue, it is even possible that the
> > requirement which you are mentioning is younger than Tomcat 5.5 and
> > cannot be met by such an old software version. It is even likely that,
> > considering the age of your Tomcat and the age of the Java JVM it is
> > probably running under, there are a whole lot of other security issues
> > with your server, which make it impossible to make it "secure as the
> > government requires".
> >
> > What I am saying is that you are probably wasting your time, and
> > ultimately your employer's time, with this approach.
> >
> > You seem to mention below that you are using Tomcat "with IIS".
> > Maybe this IIS is a front-end to Tomcat, and users access Tomcat
> > always through IIS. If so, then as long as the connection between IIS
> > and Tomcat is secure (e.g. they run on the same host), then you should
> > probably take care of the SSL/HTTPS (and header) aspect on the IIS
> > front-end. That is, if you /really/ cannot upgrade Tomcat and if your
> > applications /really/ do not run under a newer version of Tomcat and
> > Java.
> 
> HSTS is just an HTTP header thing. It can be deployed on any version of
> anything basically back until the beginning of (HTTP) time.
> 
> It's slightly easier to do with more recent Tomcats 

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: Apache TomCat 5.5

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mary,

On 9/21/16 10:51 AM, Pham, Mary (NIH/OD/ORS) [E] wrote:
> Thank you.  Chris, Chuck, Andre, Mark who had answered and I've
> done this far. My report.
> 
> - I installed the "URL rewrite" module on IIS 7.  To make short,
> it worked.  http to https redirected then enforced hsts on the IIS 
> site. - but broke all the scripts run on Tomcat due to Strick
> Transport Security when HTTPS. - so I have to disable in/outbound
> of URL rewrite.
> 
> Back to square one.  We will not be able to upgrade Tomcat at this
> time.

So you have several requirements, here:

1. Stay on Tomcat 5.5
2. Implement HSTS
3. Have your scripts all work

It sounds like #2 and #3 conflict, since evidently HSTS "broke all the
scripts to run on Tomcat".

Your only option is to fix your application so that it will work with
HSTS enabled.

Upgrading Tomcat doesn't really have any bearing on any of this, since
you could upgrade Tomcat and still not enable HSTS.

- -chris

> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Thursday, September 15,
> 2016 11:01 AM To: Tomcat Users List  
> Subject: Re: Apache TomCat 5.5
> 
> André,
> 
> On 9/14/16 7:04 PM, André Warnier (tomcat) wrote:
>> Mary, have a look here : 
>> http://tomcat.apache.org/whichversion.html Tomcat 5.5 was first 
>> released about 10 years ago, and the last modification to it was
>> in 2012. The current "stable" version is Tomcat 8.5.5.
> 
>> For Open Source and free software such as Apache Tomcat, that
>> means that your chances of getting support and help for such an
>> old version are really not good, because most of the people which
>> would be able to help you probably do not run that version
>> anywhere anymore. Even the documentation is not directly
>> available on-line anymore.
> 
>> Regarding your particular issue, it is even possible that the 
>> requirement which you are mentioning is younger than Tomcat 5.5
>> and cannot be met by such an old software version. It is even
>> likely that, considering the age of your Tomcat and the age of
>> the Java JVM it is probably running under, there are a whole lot
>> of other security issues with your server, which make it
>> impossible to make it "secure as the government requires".
> 
>> What I am saying is that you are probably wasting your time, and
>>  ultimately your employer's time, with this approach.
> 
>> You seem to mention below that you are using Tomcat "with IIS". 
>> Maybe this IIS is a front-end to Tomcat, and users access Tomcat
>>  always through IIS. If so, then as long as the connection
>> between IIS and Tomcat is secure (e.g. they run on the same
>> host), then you should probably take care of the SSL/HTTPS (and
>> header) aspect on the IIS front-end. That is, if you /really/
>> cannot upgrade Tomcat and if your applications /really/ do not
>> run under a newer version of Tomcat and Java.
> 
> HSTS is just an HTTP header thing. It can be deployed on any
> version of anything basically back until the beginning of (HTTP)
> time.
> 
> It's slightly easier to do with more recent Tomcats because of the
> inclusion of both the HTTP Header Security Filter[1] and the
> rewrite valve[2] (oddly not mentioned in the "Valves" section of
> the "Configuration" reference), but anyone can write a simple
> Filter and add it to their web application to add these headers. In
> fact, I wouldn't surprised if Tomcat's HTTP Header Security Filter
> included with Tomcat 8+ would work just fine on Tomcat 5.5. You
> just need to grab the code, compile it, and drop it into your own
> application.
> 
> Since you mentioned IIS, I think you're right that IIS is probably
> a better place to configure these HSTS headers.
> 
> Mary, ultimately, Tomcat 5.5 should definitely be upgraded to
> Tomcat 8 or later. You should take your web application and deploy
> it on Tomcat 8.0 or Tomcat 8.5 in a testing environment and just
> see what happens. You might be surprised: it will probably with
> right away without any modifications.
> 
> Hope that helps, -chris
> 
> [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html [2]
> http://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
> 
> -
>
> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX4rkBAAoJEBzwKT+lPKRYa6cP/jtLjcSwgDchFVib86/5NJ1z
b4Sb6v0M+0XXTej5FUBe7YUWpBSsuwl/XqOwvuqP+JtPaUMHLdUIK4S3MEw6r1UT
ap/xXqneQK+U9lZEloMWpvCcXKfxKVrhx4ZsOqNWOS4KqHTklcnJmtqFpdmgvPdq

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: Apache TomCat 5.5

[Pham, Mary (NIH/OD/ORS) [E]]

Thank you.  Chris, Chuck, Andre, Mark who had answered and I've done this far.  
My report.
- I installed the "URL rewrite" module on IIS 7.  To make short, it worked.  
http to https redirected then enforced hsts on the IIS site.
- but broke all the scripts run on Tomcat due to Strick Transport Security when 
HTTPS.
- so I have to disable in/outbound of URL rewrite.
Back to square one.  We will not be able to upgrade Tomcat at this time.

Please help.

-Mary

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, September 15, 2016 11:01 AM
To: Tomcat Users List 
Subject: Re: Apache TomCat 5.5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 9/14/16 7:04 PM, André Warnier (tomcat) wrote:
> Mary, have a look here :
> http://tomcat.apache.org/whichversion.html Tomcat 5.5 was first 
> released about 10 years ago, and the last modification to it was in 
> 2012. The current "stable" version is Tomcat 8.5.5.
> 
> For Open Source and free software such as Apache Tomcat, that means 
> that your chances of getting support and help for such an old version 
> are really not good, because most of the people which would be able to 
> help you probably do not run that version anywhere anymore. Even the 
> documentation is not directly available on-line anymore.
> 
> Regarding your particular issue, it is even possible that the 
> requirement which you are mentioning is younger than Tomcat 5.5 and 
> cannot be met by such an old software version. It is even likely that, 
> considering the age of your Tomcat and the age of the Java JVM it is 
> probably running under, there are a whole lot of other security issues 
> with your server, which make it impossible to make it "secure as the 
> government requires".
> 
> What I am saying is that you are probably wasting your time, and 
> ultimately your employer's time, with this approach.
> 
> You seem to mention below that you are using Tomcat "with IIS".
> Maybe this IIS is a front-end to Tomcat, and users access Tomcat 
> always through IIS. If so, then as long as the connection between IIS 
> and Tomcat is secure (e.g. they run on the same host), then you should 
> probably take care of the SSL/HTTPS (and header) aspect on the IIS 
> front-end. That is, if you /really/ cannot upgrade Tomcat and if your 
> applications /really/ do not run under a newer version of Tomcat and 
> Java.

HSTS is just an HTTP header thing. It can be deployed on any version of 
anything basically back until the beginning of (HTTP) time.

It's slightly easier to do with more recent Tomcats because of the inclusion of 
both the HTTP Header Security Filter[1] and the rewrite valve[2] (oddly not 
mentioned in the "Valves" section of the "Configuration" reference), but anyone 
can write a simple Filter and add it to their web application to add these 
headers. In fact, I wouldn't surprised if Tomcat's HTTP Header Security Filter 
included with Tomcat 8+ would work just fine on Tomcat 5.5. You just need to 
grab the code, compile it, and drop it into your own application.

Since you mentioned IIS, I think you're right that IIS is probably a better 
place to configure these HSTS headers.

Mary, ultimately, Tomcat 5.5 should definitely be upgraded to Tomcat 8 or 
later. You should take your web application and deploy it on Tomcat
8.0 or Tomcat 8.5 in a testing environment and just see what happens.
You might be surprised: it will probably with right away without any 
modifications.

Hope that helps,
- -chris

[1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html
[2] http://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX2reWAAoJEBzwKT+lPKRYp7MQAJ6nRq3m47o2BEX6nwTBNFFb
lcOfn/2L0dTfhESp/7EHqAcJaTvCHT6JH+RKplQ4gito4cJ8F2tp0HBiLRNukxjB
dxnZL7q5j6Z/41vrLMWX94WI4zz1PMqlhrEMI0/pEtRQFx07h0aE7WLp4CY6JMTl
dCGcuqkEgzNmjL1se+3+Aj3uVd0QAYESfT24AbLK0MHyrkmtIhRfr8W03C/ouD8M
9xcZ9f9BemvneI2zwiUelXaTvE4sCkPf3ULp/xw0MNYGLgl6VS8yByt1KwQsFzal
YPK+UL+k/JK6sxvGpsVLTvmY6StWYXOJZzp4C38YHxj7L5exDpDc/gCAClGm5kM/
uS1vVLL8jlkxby6k3mk5eU43M/HZkgAL+3FNjYCOcnvlsyJKsvQ9qai7Mal2N1Zt
jolFNDZCxWxfXLBPM/BLnfaYTYS6FXWZmAT5QrbnqAoxG9iKWsiMloPym8xdO36+
vIxOeNevWZif7MbpRUw84oOtcCAm1aZcyjXjwxQwWNciczocZg8d3DSJY53wqcrL
nAx5zVbxE5h3nBKSuuNl3s1WGXf7hySYxWyCg7Ya67EsGGeDT1rlLaotXI8PdKOL
qB32fz6PRJZspxJDefQGSHWrjq3gBAqeNFzp/3vj9tmvdCDkdzT0xNJH9s/6YGVE
7whnGB6jlseII/fYe6s1
=hetE
-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 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

AW: Tomcat 7.0.65 + Java 6 Update 121 64-bit - Cipher Suite Names

[Kreuser, Peter]

Roman,

>I know it did not worked because as soon as I add the ciphers entry to the
>SSL HTTPS connector in the server.xml file, it tells me that value is not
>supported.
>
>On Wed, Sep 21, 2016 at 6:45 PM, Mark Thomas  wrote:
>
>> On 21/09/2016 11:22, Román Valoria wrote:
>> > Before anyone tells me, I cannot upgrade either Tomcat or Java to the
>> > latest major release.
>> >
>> > My setup is running on Windows Server 2008 R2 64-bit OS.
>>
>> What configuration have you tried?
>>
>> How do you know it didn't work?
>>
>> Mark
>>
>> >
>> > On Wed, Sep 21, 2016 at 6:18 PM, Román Valoria 
>> > wrote:
>> >
>> >> Dear all:
>> >>
>> >> I need to configure Tomcat 7.0.65 with Java 6, both 64-bit.
>> >>
>> >> I have managed to make it work with update 121 in using the SSL protocol
>> >> TLS 1.2.
>> >>
>> >> Now I need to exert some control over the cipher suites used on that
>> >> protocol.
>> >>
>> >> I am unable to come up with the list of supported cipher suite names to
>> >> use.
>> >>
>> >> Both JRE and JDK are in:
>> >>
>> >> https://support.oracle.com/epmos/faces/PatchResultsNDetails?patchId=
>> >> 9553040
>> >>
>> >> I am using both the Java 6 and 7 documentation to come up with the
>> cipher
>> >> suite names:
>> >>
>> >> Java Cryptography Architecture Sun ProvidersDocumentation
>> >> > guides/security/SunProviders.html>
>> >>
>> >>
>> >> Java PKCS#11 Reference Guide
>> >> > guides/security/p11guide.html#ALG>
>> >>
>> >>
>> >> Standard Algorithm Name Documentation
>> >> > guides/security/StandardNames.html#Cipher>
>> >>
>> >>
>> >> Java Cryptography Architecture Oracle ProvidersDocumentation
>> >> > guides/security/SunProviders.html#SunJSSEProvider>
>> >>
>> >>
>> >> As per the above I even tried downloading the Java Cryptography
>> Extension
>> >> for Java 6 from:
>> >>
>> >> Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy
>> >> Files 6
>> >> > embedded-se/downloads/jce-6-download-429243.html>
>> >>
>> >>
>> >> But that is for 32-bit and failed anyway.
>> >>
>> >> Am I missing something?
>> >>
>> >> Thanks and regards.
>> >>
>> >
Would you mind to share your connector configuration and the ciphers you chose?

Peter

Re: Tomcat 7.0.65 + Java 6 Update 121 64-bit - Cipher Suite Names

[Román Valoria]

I know it did not worked because as soon as I add the ciphers entry to the
SSL HTTPS connector in the server.xml file, it tells me that value is not
supported.

On Wed, Sep 21, 2016 at 6:45 PM, Mark Thomas  wrote:

> On 21/09/2016 11:22, Román Valoria wrote:
> > Before anyone tells me, I cannot upgrade either Tomcat or Java to the
> > latest major release.
> >
> > My setup is running on Windows Server 2008 R2 64-bit OS.
>
> What configuration have you tried?
>
> How do you know it didn't work?
>
> Mark
>
> >
> > On Wed, Sep 21, 2016 at 6:18 PM, Román Valoria 
> > wrote:
> >
> >> Dear all:
> >>
> >> I need to configure Tomcat 7.0.65 with Java 6, both 64-bit.
> >>
> >> I have managed to make it work with update 121 in using the SSL protocol
> >> TLS 1.2.
> >>
> >> Now I need to exert some control over the cipher suites used on that
> >> protocol.
> >>
> >> I am unable to come up with the list of supported cipher suite names to
> >> use.
> >>
> >> Both JRE and JDK are in:
> >>
> >> https://support.oracle.com/epmos/faces/PatchResultsNDetails?patchId=
> >> 9553040
> >>
> >> I am using both the Java 6 and 7 documentation to come up with the
> cipher
> >> suite names:
> >>
> >> Java Cryptography Architecture Sun ProvidersDocumentation
> >>  guides/security/SunProviders.html>
> >>
> >>
> >> Java PKCS#11 Reference Guide
> >>  guides/security/p11guide.html#ALG>
> >>
> >>
> >> Standard Algorithm Name Documentation
> >>  guides/security/StandardNames.html#Cipher>
> >>
> >>
> >> Java Cryptography Architecture Oracle ProvidersDocumentation
> >>  guides/security/SunProviders.html#SunJSSEProvider>
> >>
> >>
> >> As per the above I even tried downloading the Java Cryptography
> Extension
> >> for Java 6 from:
> >>
> >> Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy
> >> Files 6
> >>  embedded-se/downloads/jce-6-download-429243.html>
> >>
> >>
> >> But that is for 32-bit and failed anyway.
> >>
> >> Am I missing something?
> >>
> >> Thanks and regards.
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 7.0.65 + Java 6 Update 121 64-bit - Cipher Suite Names

[Harrie Robins]

Please see: https://community.qualys.com/thread/11882
Disable the weak ciphers.

The Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction
Policy is needed when you want to run AES256 (you want this).

Regards,

Harrie

On 21 September 2016 at 12:18, Román Valoria  wrote:

> Dear all:
>
> I need to configure Tomcat 7.0.65 with Java 6, both 64-bit.
>
> I have managed to make it work with update 121 in using the SSL protocol
> TLS 1.2.
>
> Now I need to exert some control over the cipher suites used on that
> protocol.
>
> I am unable to come up with the list of supported cipher suite names to
> use.
>
> Both JRE and JDK are in:
>
> https://support.oracle.com/epmos/faces/PatchResultsNDetails?patchId=
> 9553040
>
> I am using both the Java 6 and 7 documentation to come up with the cipher
> suite names:
>
> Java Cryptography Architecture Sun ProvidersDocumentation
>  guides/security/SunProviders.html>
>
>
> Java PKCS#11 Reference Guide
>  guides/security/p11guide.html#ALG>
>
>
> Standard Algorithm Name Documentation
>  guides/security/StandardNames.html#Cipher>
>
>
> Java Cryptography Architecture Oracle ProvidersDocumentation
>  guides/security/SunProviders.html#SunJSSEProvider>
>
>
> As per the above I even tried downloading the Java Cryptography Extension
> for Java 6 from:
>
> Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy
> Files 6
>  embedded-se/downloads/jce-6-download-429243.html>
>
>
> But that is for 32-bit and failed anyway.
>
> Am I missing something?
>
> Thanks and regards.
>

AW: Tomcat 7.0.65 + Java 6 Update 121 64-bit - Cipher Suite Names

[Kreuser, Peter]

Roman,

> On 21/09/2016 11:22, Román Valoria wrote:
> > Before anyone tells me, I cannot upgrade either Tomcat or Java to the
> > latest major release.
> > 
> > My setup is running on Windows Server 2008 R2 64-bit OS.
> 
> What configuration have you tried?
> 
> How do you know it didn't work?
> 
> Mark
> 
> > 
> > On Wed, Sep 21, 2016 at 6:18 PM, Román Valoria 
> > wrote:
> > 
> >> Dear all:
> >>
> >> I need to configure Tomcat 7.0.65 with Java 6, both 64-bit.
> >>
> >> I have managed to make it work with update 121 in using the SSL protocol
> >> TLS 1.2.
> >>
> >> Now I need to exert some control over the cipher suites used on that
> >> protocol.
> >>
> >> I am unable to come up with the list of supported cipher suite names to
> >> use.
> >>
> >> Both JRE and JDK are in:
> >>
> >> https://support.oracle.com/epmos/faces/PatchResultsNDetails?patchId=
> >> 9553040
> >>
> >> I am using both the Java 6 and 7 documentation to come up with the cipher
> >> suite names:
> >>
> >> Java Cryptography Architecture Sun ProvidersDocumentation
> >> 
> >>
> >>
> >> Java PKCS#11 Reference Guide
> >> 
> >>
> >>
> >> Standard Algorithm Name Documentation
> >> 
> >>
> >>
> >> Java Cryptography Architecture Oracle ProvidersDocumentation
> >> 
> >>
> >>
> >> As per the above I even tried downloading the Java Cryptography Extension
> >> for Java 6 from:
> >>
> >> Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy
> >> Files 6
> >> 
> >>
> >>
> >> But that is for 32-bit and failed anyway.
> >>
> >> Am I missing something?
> >>
> >> Thanks and regards.
> >>
> > 
> 

I have had good experiences with SSLInfo.java 
(https://gist.github.com/MikeN123/8810553). That will provide you with the 
possible Ciphers in you JRE.
Converting a good openssl cipher string to Java syntax can be found on 
http://blog.bitmelt.com/2013/11/tomcat-ssl-hardening.html

Given Java6, you will not have many working options. Most browsers will limit 
usage of old ciphers. Plus you lose TLS 1.1/1.2.

Best regards

Peter 



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

Re: Tomcat 7.0.65 + Java 6 Update 121 64-bit - Cipher Suite Names

[Mark Thomas]

On 21/09/2016 11:22, Román Valoria wrote:
> Before anyone tells me, I cannot upgrade either Tomcat or Java to the
> latest major release.
> 
> My setup is running on Windows Server 2008 R2 64-bit OS.

What configuration have you tried?

How do you know it didn't work?

Mark

> 
> On Wed, Sep 21, 2016 at 6:18 PM, Román Valoria 
> wrote:
> 
>> Dear all:
>>
>> I need to configure Tomcat 7.0.65 with Java 6, both 64-bit.
>>
>> I have managed to make it work with update 121 in using the SSL protocol
>> TLS 1.2.
>>
>> Now I need to exert some control over the cipher suites used on that
>> protocol.
>>
>> I am unable to come up with the list of supported cipher suite names to
>> use.
>>
>> Both JRE and JDK are in:
>>
>> https://support.oracle.com/epmos/faces/PatchResultsNDetails?patchId=
>> 9553040
>>
>> I am using both the Java 6 and 7 documentation to come up with the cipher
>> suite names:
>>
>> Java Cryptography Architecture Sun ProvidersDocumentation
>> 
>>
>>
>> Java PKCS#11 Reference Guide
>> 
>>
>>
>> Standard Algorithm Name Documentation
>> 
>>
>>
>> Java Cryptography Architecture Oracle ProvidersDocumentation
>> 
>>
>>
>> As per the above I even tried downloading the Java Cryptography Extension
>> for Java 6 from:
>>
>> Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy
>> Files 6
>> 
>>
>>
>> But that is for 32-bit and failed anyway.
>>
>> Am I missing something?
>>
>> Thanks and regards.
>>
> 


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

Re: Tomcat 7.0.65 + Java 6 Update 121 64-bit - Cipher Suite Names

[Román Valoria]

Before anyone tells me, I cannot upgrade either Tomcat or Java to the
latest major release.

My setup is running on Windows Server 2008 R2 64-bit OS.

On Wed, Sep 21, 2016 at 6:18 PM, Román Valoria 
wrote:

> Dear all:
>
> I need to configure Tomcat 7.0.65 with Java 6, both 64-bit.
>
> I have managed to make it work with update 121 in using the SSL protocol
> TLS 1.2.
>
> Now I need to exert some control over the cipher suites used on that
> protocol.
>
> I am unable to come up with the list of supported cipher suite names to
> use.
>
> Both JRE and JDK are in:
>
> https://support.oracle.com/epmos/faces/PatchResultsNDetails?patchId=
> 9553040
>
> I am using both the Java 6 and 7 documentation to come up with the cipher
> suite names:
>
> Java Cryptography Architecture Sun ProvidersDocumentation
> 
>
>
> Java PKCS#11 Reference Guide
> 
>
>
> Standard Algorithm Name Documentation
> 
>
>
> Java Cryptography Architecture Oracle ProvidersDocumentation
> 
>
>
> As per the above I even tried downloading the Java Cryptography Extension
> for Java 6 from:
>
> Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy
> Files 6
> 
>
>
> But that is for 32-bit and failed anyway.
>
> Am I missing something?
>
> Thanks and regards.
>

Tomcat 7.0.65 + Java 6 Update 121 64-bit - Cipher Suite Names

[Román Valoria]

Dear all:

I need to configure Tomcat 7.0.65 with Java 6, both 64-bit.

I have managed to make it work with update 121 in using the SSL protocol
TLS 1.2.

Now I need to exert some control over the cipher suites used on that
protocol.

I am unable to come up with the list of supported cipher suite names to use.

Both JRE and JDK are in:

https://support.oracle.com/epmos/faces/PatchResultsNDetails?patchId=9553040

I am using both the Java 6 and 7 documentation to come up with the cipher
suite names:

Java Cryptography Architecture Sun ProvidersDocumentation



Java PKCS#11 Reference Guide



Standard Algorithm Name Documentation



Java Cryptography Architecture Oracle ProvidersDocumentation



As per the above I even tried downloading the Java Cryptography Extension
for Java 6 from:

Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy
Files 6



But that is for 32-bit and failed anyway.

Am I missing something?

Thanks and regards.

Re: NPE in SecureNioChannel (TC 8.5.5)

[Rémy Maucherat]

2016-09-20 21:51 GMT+02:00 Colin Ingarfield :

> Hello,
>
> A thread from a day or two ago mentioned a NPE in SecureNioChannel
> when the connector is configured with Http11NioProtocol.  OP mentioned
> using Http11Nio2Protocol resolves the issue.  I am also seeing this
> exception and it is resolved by switching to the Nio2 protocol
> implementation.
>

This is not the same NPE, but it is probably caused by the same thing as
the previous one and it will be fixed in Tomcat 8.5.6. The SSL engine seems
null, probably due to processSNI not doing anything while not returning an
error.


>
> Is this a reasonable workaround until TC 8.5.6?  Are there
> dis/advantages to using Nio2 instead of Nio?
>

There's no workaround.
NIO2 is a cleaner API, and it has fancy capabilities. The code in Tomcat
looks better IMO compared to the NIO or APR connectors, but NIO2 is missing
a few features so some algorithms are very complex. Also the fancy features
haven't given any performance benefit (HTTP/2 could have benefited but it's
still too high level).

Rémy