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

2016-09-20 Thread 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(Unknown Source)
  at

NPE in SecureNioChannel (TC 8.5.5)

2016-09-20 Thread 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.

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

Thanks,
Colin

Ubuntu 12.04.5 LTS (GNU/Linux 3.0.0-32-virtual x86_64)
java version "1.8.0_101"
Tomcat 8.5.5

14-Sep-2016 17:26:44.052 SEVERE [https-jsse-nio-443-exec-9]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error
reading request, ignored
 java.lang.NullPointerException
at 
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.getSslSupport(NioEndpoint.java:1329)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:792)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)







(Sorry I wasn't subscribed to the list so I can't reply to the original thread.)

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

Re: JreMemoryLeakPreventionListener docs example

2016-09-20 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 9/20/16 12:06 PM, Berneburg, Cris J. - US wrote:
> Around 9/6/16 Chris Schultz replied to the "WAR isolation
> lifecycle" thread with:
> 
>> There are some libraries that don't shut down well, or the
>> applications that use them don't properly shut them down. The
>> solution is to either fix the library (ask them!), or use
>> Tomcat's "leak prevention listener" to pre-load those classes
>> that represent a problem.
>> 
>> http://tomcat.apache.org/tomcat-8.0-doc/config/listeners.html#JRE_Mem
ory_Leak_Prevention_Listener_-_org.apache.catalina.core.JreMemoryLeakPre
ventionListener
>>
>>
>> 
You want to read about the "classesToInitialize" attribute.
> 
> Having recently dealt with some memory leaks, I was curious and
> read through.  Great!  This might help in future struggles.
> However, being still somewhat new to this, I was unable to
> determine how to invoke the classesToInitialize parameter inside
> the server.xml from the documentation page.  Googling around led to
> this:
> 
> http://stackoverflow.com/questions/11872316/tomcat-guice-jdbc-memory-l
eak#19027873
>
>  The critical part is:
> 
>> In tomcat/conf/server.xml, modify (inside the Server element): 
>> > className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>> />
>> 
>> to
>> 
>> > className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>>
>> 
classesToInitialize="com.mysql.jdbc.NonRegisteringDriver" />
> 
> Aha, that's the XML syntax!  Why didn't I know that?
> 
> So, could we add a small example server.xml snippet to the
> JreMemoryLeakPreventionListener documentation to make it clear to
> newbies how to add the classesToInitialize option?  Something
> like:
> 
>  className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>
> 
classesToInitialize="oracle.jdbc.driver.OracleTimeoutThreadPerVM" />

Care to make a formal documentation patch? You'll get your name in the
changelog :)

> Is this also valid?
> 
>  className="org.apache.catalina.core.JreMemoryLeakPreventionListener">
>
> 
oracle.jdbc.driver.OracleTimeoutThreadPerVM
> 

I'm not sure but I don't think so. It all depends upon how Tomcat has
configured the digester, since it treats child elements and element
attributes differently.

> Would examples look better after the Attribute/Description table as
> a separate section or embedded directly within the table?

Definitely outside of the table IMO.

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

iQIcBAEBCAAGBQJX4YDLAAoJEBzwKT+lPKRYU2EQAJK9n62A3aDELeDU8ORMJCKy
GiaUtIOz+aGgf2dzBLFaMGG07mgNr+qhIHHt0/XU0MYnlAL5++bEGuJ+E+gjiLNs
LIOXD3W0C5ocsTNV7bl0GRxbHHqioyWo5x33LMa83R5FCIxfIfEpCCKtJ+xEoymi
ZzFBuZL3Cb7mSFfZrs0VzfOhemlA4UkK2cWxXoOd/nzIdsUOJnurcM8OZbP3BK28
HHTTwCAlVzcuFb/Tt88+o69KrLtwzPAOaRerGcebxs8E1sgAw05Amc7iLryXQUpn
IJGpGOdtHfZ8btbNTfuCPCdfeqQ8rjD7Fh+2jNAoJe1L+1dvk1pqMuuJq1h4rT34
m2WbgcJhaQKm5NPD94j/12pmZLgz/pP+uYgXoBLNCyNKI2mCK1kMYevAweMIneCa
JwD0p+MPqd2QXRmyihzJIaBNTeM2Jjp/HQH7qHxW7SkBBfskK50memFH89JsgUs7
/WjHIs1KvfvV+iigFsr8cqx/qHKRKxcgP3XnaQ4Hqu8CidiwD/1IMhpRGHSDDrkY
hMCs8dtK15dCQ6YkuCHBFLTMJjpowiBjbJYKHUxx6zcLr5q3utQx1hy/nxiES6eA
CeLPeUb/zVpuIsSwcNyZ4HOR+z1ymxmvlkNaNZBkWc1kW/6IKxkg4ptFqmyNTYG5
/Av7DhIUoGO4nGrTvmAv
=aXo7
-END PGP SIGNATURE-

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

Re: mod_rewrite encoding behavior when migrating from 8.0.33 to 8.5.5

2016-09-20 Thread Tiago Oliveira 
Mark,

i suggested a patch for this one issue, hope it helps:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60013#c37

Tiago.

2016-09-20 12:24 GMT-03:00 Mark Thomas :

> On 20/09/2016 14:41, Tiago Oliveira wrote:
> > Mark,
> >
> > i tested with the trunk from 8.5.6:
> >
> > $ svn info
> >> Path: .
> >> Working Copy Root Path: /Users/tiago.oliveira/tmp/tomcat85x
> >> URL: http://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk
> >> Repository Root: http://svn.apache.org/repos/asf
> >> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> >> Revision: 1761569
> >> Node Kind: directory
> >> Schedule: normal
> >> Last Changed Author: markt
> >> Last Changed Rev: 1761560
> >> Last Changed Date: 2016-09-20 08:44:42 -0300 (Ter, 20 Set 2016)
> >
> >
> > $ java -version
> >> java version "1.8.0_77"
> >> Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
> >> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> >
> >
> > I issued *ant clean* & *ant package-tgz* then used the generated
> > *apache-tomcat-8.5.6-dev.tar.gz*.
> > After installing it in my staging box, configuring RewriteValve and
> placing
> > rewrite.config, i still have the same issue:
> >
> > $ curl -I http://ci.behoh.com
> >> HTTP/1.1 302
> >> Location: http%3A//www.ci.behoh.com/
> >> Transfer-Encoding: chunked
> >> Date: Tue, 20 Sep 2016 13:21:54 GMT
> >
> >
> > Am i doing something wrong ? Could you point me to the revision where
> this
> > got mangled/fixed ? Maybe i can help.
>
> My bad. It has only been fixed in trunk (9.0.x) so far. I have one more
> issue to fix before back-porting.
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60013
>
> Help / suggested patches always welcome.
>
> Mark
>
>
> >
> > Thanks again.
> >
> > 2016-09-19 17:55 GMT-03:00 Tiago Oliveira :
> >
> >> Mark,
> >>
> >> will checkout from trunk and test it. I think i can handle the build, no
> >> problem.
> >>
> >> Is 8.5.6 release date already set ?
> >>
> >> Thanks a lot.
> >>
> >> 2016-09-19 17:41 GMT-03:00 Mark Thomas :
> >>
> >>> On 19/09/2016 21:21, Mark Thomas wrote:
>  On 19/09/2016 20:06, Tiago Oliveira wrote:
> > Hello,
> >
> >
> > I'm currently migrating from tomcat 8.0.33 to 8.5.5, as stated in the
> > subject, but have stumbled in an unexpected behavior when using the
> > RewriteValve. I tested in two diferent OS (ubuntu 16.04 LTS and
> Centos
> >>> 6.7).
> 
>  Sorry about that. It is a side effect of my botched attempt to fix
>  handling of UTF-8 encoded values in the re-write valve.
> 
>  It should be fixed already for the 8.5.6 release but I'll add a test
>  case to make sure.
> >>>
> >>> Confirmed.
> >>>
> >>> Building Tomcat from source is straightforward if you want to test this
> >>> with your application. If you want to do that and need any pointers,
> >>> just ask.
> >>>
> >>> Mark
> >>>
> 
>  Mark
> 
> 
> >
> > This is the content of my WEB-INF/rewrite.config (Valve configured
> >>> inside
> > Context):
> >
> >> RewriteCond %{HTTP_HOST} ^ci.behoh.com
> >> RewriteRule ^(.*)$ http://www.%{HTTP_HOST}$1 [R=302,L]
> >
> >
> >
> > In 8.0.33, my response headers are:
> >
> >> HTTP/1.1 302
> >> Location: http://www.ci.behoh.com/
> >> Content-Length: 0
> >> Date: Mon, 19 Sep 2016 18:39:43 GMT
> >
> >
> >
> > In 8.5.5, my response headers are:
> >
> >> HTTP/1.1 302
> >> Location: http%3A//www.ci.behoh.com/
> >> Content-Length: 0
> >> Date: Mon, 19 Sep 2016 18:40:24 GMT
> >
> >
> > Notice the encoded version of ":" (%3A) in 8.5.5.
> >
> > Because of that, the browser (Chrome/Firefox/Safari) is not
> redirecting
> > correctly, but instead appending the encoded string to the end of the
> >>> url,
> > incrementally, until i get a "java.lang.IllegalArgumentException:
> >>> Request
> > header is too large" (final modified  requestURL:
> > https://gist.github.com/tiagojco/b9c3f1a6e8c3fbacf206505b18944c62)
> >
> > I already tried the flag [NE] in the RewriteRule, to no avail.
> >
> > How can i fix this ? Is there any workaround ?
> >
> > Thanks a lot.
> >
> > p.s.: Sorry for my bad english, not my first language.
> >
> 
> 
>  -
>  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
> >>>
> >>>
> >>
> >>
> >> --
> >> [image: Tiago Oliveira] Tiago OliveiraAnálise de sistemas[image:
> Contato]+55
> >> 83 99331.5541 <+5583993315541>/ 83 3506.8310 <+558335068310>[image:
> Email]

RE: apache-tomcat-9.0.0.M10: Change Context-Path in META-INF/context.xml not working

2016-09-20 Thread Caldarale, Charles R 
> From: Maik Brauer [mailto:m...@brauer.nrw] 
> Subject: apache-tomcat-9.0.0.M10: Change Context-Path in META-INF/context.xml 
> not working

> I have a standard Tomcat9 installation. I just put a helloworld.war in the 
> webapps folder 
> and inside the META-INF I put the context.xml with a different path like: 
> 

Which is not allowed.

> But the context is still http://localhost/helloworld instead 
> http://localhost/newcontext.

As it should be.

> I tried so many things, but it is not possible to get Tomcat convinced to use 
> the new path.

Correct.

> Anybody who can help?

Read the doc:
http://tomcat.apache.org/tomcat-9.0-doc/config/context.html

In particular, this sentence describing the path attribute:

"This attribute must only be used when statically defining a Context in 
server.xml. In all other circumstances, the path will be inferred from the 
filenames used for either the .xml context file or the docBase."

Rename your .war file if you want a different context name.  You may also place 
your webapp outside of the appBase directory, and place a [context_name].xml 
file in conf/Catalina/localhost with a docBase attribute pointing to the webapp 
location.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

apache-tomcat-9.0.0.M10: Change Context-Path in META-INF/context.xml not working

2016-09-20 Thread Maik Brauer 
I have a standard Tomcat9 installation. I just put a helloworld.war in the 
webapps folder and inside the META-INF I put the context.xml with a different 
path like: 

But the context is still http://localhost/helloworld instead 
http://localhost/newcontext.

I tried so many things, but it is not possible to get Tomcat convinced to use 
the new path. Anybody who can help? Thanks.

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

2016-09-20 Thread 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)
> >>  at sun.security.ssl.SSLSocketImpl.getSession(Unknown Source)
> >>  at
> >>
> org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFac
> tory.java:215)
> >>  at
> >>
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.ja
> va:298)
> >>  at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
> >>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
> >>  at java.lang.Thread.run(Unknown Source)
> >> http-bio-8443-exec-1, handling exception:
> java.security.ProviderException:
> >>

JreMemoryLeakPreventionListener docs example

2016-09-20 Thread Berneburg, Cris J. - US 
Around 9/6/16 Chris Schultz replied to the "WAR isolation lifecycle" thread 
with:

> There are some libraries that don't shut down well, or the applications
> that use them don't properly shut them down. The solution is to either
> fix the library (ask them!), or use Tomcat's "leak prevention listener"
> to pre-load those classes that represent a problem.
>
> http://tomcat.apache.org/tomcat-8.0-doc/config/listeners.html#JRE_Memory_Leak_Prevention_Listener_-_org.apache.catalina.core.JreMemoryLeakPreventionListener
>
> You want to read about the "classesToInitialize" attribute.

Having recently dealt with some memory leaks, I was curious and read through.  
Great!  This might help in future struggles.  However, being still somewhat new 
to this, I was unable to determine how to invoke the classesToInitialize 
parameter inside the server.xml from the documentation page.  Googling around 
led to this:

http://stackoverflow.com/questions/11872316/tomcat-guice-jdbc-memory-leak#19027873

The critical part is:

> In tomcat/conf/server.xml, modify (inside the Server element):
>  className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>
> to
>
>   classesToInitialize="com.mysql.jdbc.NonRegisteringDriver" />

Aha, that's the XML syntax!  Why didn't I know that?

So, could we add a small example server.xml snippet to the 
JreMemoryLeakPreventionListener documentation to make it clear to newbies how 
to add the classesToInitialize option?  Something like:



Is this also valid?


  
oracle.jdbc.driver.OracleTimeoutThreadPerVM


Would examples look better after the Attribute/Description table as a separate 
section or embedded directly within the table?

--
Cris Berneburg
Lead Software Engineer, CACI

Re: mod_rewrite encoding behavior when migrating from 8.0.33 to 8.5.5

2016-09-20 Thread Mark Thomas 
On 20/09/2016 14:41, Tiago Oliveira wrote:
> Mark,
> 
> i tested with the trunk from 8.5.6:
> 
> $ svn info
>> Path: .
>> Working Copy Root Path: /Users/tiago.oliveira/tmp/tomcat85x
>> URL: http://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk
>> Repository Root: http://svn.apache.org/repos/asf
>> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
>> Revision: 1761569
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: markt
>> Last Changed Rev: 1761560
>> Last Changed Date: 2016-09-20 08:44:42 -0300 (Ter, 20 Set 2016)
> 
> 
> $ java -version
>> java version "1.8.0_77"
>> Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> 
> 
> I issued *ant clean* & *ant package-tgz* then used the generated
> *apache-tomcat-8.5.6-dev.tar.gz*.
> After installing it in my staging box, configuring RewriteValve and placing
> rewrite.config, i still have the same issue:
> 
> $ curl -I http://ci.behoh.com
>> HTTP/1.1 302
>> Location: http%3A//www.ci.behoh.com/
>> Transfer-Encoding: chunked
>> Date: Tue, 20 Sep 2016 13:21:54 GMT
> 
> 
> Am i doing something wrong ? Could you point me to the revision where this
> got mangled/fixed ? Maybe i can help.

My bad. It has only been fixed in trunk (9.0.x) so far. I have one more
issue to fix before back-porting.

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

Help / suggested patches always welcome.

Mark


> 
> Thanks again.
> 
> 2016-09-19 17:55 GMT-03:00 Tiago Oliveira :
> 
>> Mark,
>>
>> will checkout from trunk and test it. I think i can handle the build, no
>> problem.
>>
>> Is 8.5.6 release date already set ?
>>
>> Thanks a lot.
>>
>> 2016-09-19 17:41 GMT-03:00 Mark Thomas :
>>
>>> On 19/09/2016 21:21, Mark Thomas wrote:
 On 19/09/2016 20:06, Tiago Oliveira wrote:
> Hello,
>
>
> I'm currently migrating from tomcat 8.0.33 to 8.5.5, as stated in the
> subject, but have stumbled in an unexpected behavior when using the
> RewriteValve. I tested in two diferent OS (ubuntu 16.04 LTS and Centos
>>> 6.7).

 Sorry about that. It is a side effect of my botched attempt to fix
 handling of UTF-8 encoded values in the re-write valve.

 It should be fixed already for the 8.5.6 release but I'll add a test
 case to make sure.
>>>
>>> Confirmed.
>>>
>>> Building Tomcat from source is straightforward if you want to test this
>>> with your application. If you want to do that and need any pointers,
>>> just ask.
>>>
>>> Mark
>>>

 Mark


>
> This is the content of my WEB-INF/rewrite.config (Valve configured
>>> inside
> Context):
>
>> RewriteCond %{HTTP_HOST} ^ci.behoh.com
>> RewriteRule ^(.*)$ http://www.%{HTTP_HOST}$1 [R=302,L]
>
>
>
> In 8.0.33, my response headers are:
>
>> HTTP/1.1 302
>> Location: http://www.ci.behoh.com/
>> Content-Length: 0
>> Date: Mon, 19 Sep 2016 18:39:43 GMT
>
>
>
> In 8.5.5, my response headers are:
>
>> HTTP/1.1 302
>> Location: http%3A//www.ci.behoh.com/
>> Content-Length: 0
>> Date: Mon, 19 Sep 2016 18:40:24 GMT
>
>
> Notice the encoded version of ":" (%3A) in 8.5.5.
>
> Because of that, the browser (Chrome/Firefox/Safari) is not redirecting
> correctly, but instead appending the encoded string to the end of the
>>> url,
> incrementally, until i get a "java.lang.IllegalArgumentException:
>>> Request
> header is too large" (final modified  requestURL:
> https://gist.github.com/tiagojco/b9c3f1a6e8c3fbacf206505b18944c62)
>
> I already tried the flag [NE] in the RewriteRule, to no avail.
>
> How can i fix this ? Is there any workaround ?
>
> Thanks a lot.
>
> p.s.: Sorry for my bad english, not my first language.
>


 -
 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
>>>
>>>
>>
>>
>> --
>> [image: Tiago Oliveira] Tiago OliveiraAnálise de sistemas[image: Contato]+55
>> 83 99331.5541 <+5583993315541>/ 83 3506.8310 <+558335068310>[image: Email]
>> tiago.olive...@behoh.com 
>> [image: BeHOH]
>> [image: Facebook] [image: Twitter]
>> [image: Instagram]
>> 
>>   [image: Website]behoh.com [image: Localização]
>> goo.gl/FtUZdn 
>>
> 
> 
> 


-
To unsubscribe, e-mail:

Re: mod_rewrite encoding behavior when migrating from 8.0.33 to 8.5.5

2016-09-20 Thread Tiago Oliveira 
Mark,

i tested with the trunk from 8.5.6:

$ svn info
> Path: .
> Working Copy Root Path: /Users/tiago.oliveira/tmp/tomcat85x
> URL: http://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk
> Repository Root: http://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1761569
> Node Kind: directory
> Schedule: normal
> Last Changed Author: markt
> Last Changed Rev: 1761560
> Last Changed Date: 2016-09-20 08:44:42 -0300 (Ter, 20 Set 2016)


$ java -version
> java version "1.8.0_77"
> Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)


I issued *ant clean* & *ant package-tgz* then used the generated
*apache-tomcat-8.5.6-dev.tar.gz*.
After installing it in my staging box, configuring RewriteValve and placing
rewrite.config, i still have the same issue:

$ curl -I http://ci.behoh.com
> HTTP/1.1 302
> Location: http%3A//www.ci.behoh.com/
> Transfer-Encoding: chunked
> Date: Tue, 20 Sep 2016 13:21:54 GMT


Am i doing something wrong ? Could you point me to the revision where this
got mangled/fixed ? Maybe i can help.

Thanks again.

2016-09-19 17:55 GMT-03:00 Tiago Oliveira :

> Mark,
>
> will checkout from trunk and test it. I think i can handle the build, no
> problem.
>
> Is 8.5.6 release date already set ?
>
> Thanks a lot.
>
> 2016-09-19 17:41 GMT-03:00 Mark Thomas :
>
>> On 19/09/2016 21:21, Mark Thomas wrote:
>> > On 19/09/2016 20:06, Tiago Oliveira wrote:
>> >> Hello,
>> >>
>> >>
>> >> I'm currently migrating from tomcat 8.0.33 to 8.5.5, as stated in the
>> >> subject, but have stumbled in an unexpected behavior when using the
>> >> RewriteValve. I tested in two diferent OS (ubuntu 16.04 LTS and Centos
>> 6.7).
>> >
>> > Sorry about that. It is a side effect of my botched attempt to fix
>> > handling of UTF-8 encoded values in the re-write valve.
>> >
>> > It should be fixed already for the 8.5.6 release but I'll add a test
>> > case to make sure.
>>
>> Confirmed.
>>
>> Building Tomcat from source is straightforward if you want to test this
>> with your application. If you want to do that and need any pointers,
>> just ask.
>>
>> Mark
>>
>> >
>> > Mark
>> >
>> >
>> >>
>> >> This is the content of my WEB-INF/rewrite.config (Valve configured
>> inside
>> >> Context):
>> >>
>> >>> RewriteCond %{HTTP_HOST} ^ci.behoh.com
>> >>> RewriteRule ^(.*)$ http://www.%{HTTP_HOST}$1 [R=302,L]
>> >>
>> >>
>> >>
>> >> In 8.0.33, my response headers are:
>> >>
>> >>> HTTP/1.1 302
>> >>> Location: http://www.ci.behoh.com/
>> >>> Content-Length: 0
>> >>> Date: Mon, 19 Sep 2016 18:39:43 GMT
>> >>
>> >>
>> >>
>> >> In 8.5.5, my response headers are:
>> >>
>> >>> HTTP/1.1 302
>> >>> Location: http%3A//www.ci.behoh.com/
>> >>> Content-Length: 0
>> >>> Date: Mon, 19 Sep 2016 18:40:24 GMT
>> >>
>> >>
>> >> Notice the encoded version of ":" (%3A) in 8.5.5.
>> >>
>> >> Because of that, the browser (Chrome/Firefox/Safari) is not redirecting
>> >> correctly, but instead appending the encoded string to the end of the
>> url,
>> >> incrementally, until i get a "java.lang.IllegalArgumentException:
>> Request
>> >> header is too large" (final modified  requestURL:
>> >> https://gist.github.com/tiagojco/b9c3f1a6e8c3fbacf206505b18944c62)
>> >>
>> >> I already tried the flag [NE] in the RewriteRule, to no avail.
>> >>
>> >> How can i fix this ? Is there any workaround ?
>> >>
>> >> Thanks a lot.
>> >>
>> >> p.s.: Sorry for my bad english, not my first language.
>> >>
>> >
>> >
>> > -
>> > 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
>>
>>
>
>
> --
> [image: Tiago Oliveira] Tiago OliveiraAnálise de sistemas[image: Contato]+55
> 83 99331.5541 <+5583993315541>/ 83 3506.8310 <+558335068310>[image: Email]
> tiago.olive...@behoh.com 
> [image: BeHOH]
> [image: Facebook] [image: Twitter]
> [image: Instagram]
> 
>   [image: Website]behoh.com [image: Localização]
> goo.gl/FtUZdn 
>



-- 
[image: Tiago Oliveira] Tiago OliveiraAnálise de sistemas[image: Contato]+55
83 99331.5541 <+5583993315541>/ 83 3506.8310 <+558335068310>[image: Email]
tiago.olive...@behoh.com 
[image: BeHOH]
[image: Facebook] [image: Twitter]
[image: Instagram]

  [image: Website]behoh.com [image: Localização]
goo.gl/FtUZdn

RE: Custom class loader

2016-09-20 Thread Erwan Cancouet 

Erwan,

On 9/19/16 11:36 AM, Erwan Cancouet wrote:
> Hi,
>
> i'm using Tomcat 7.0.70 on ubuntu 15.10.
>
> I have created a SampleClassLoader :
>
> package com.axway.tnt.compliance;
>
> import org.apache.catalina.loader.WebappClassLoader;
>
> import java.io.File; import java.io.IOException;
>
> public class SampleClassLoader extends WebappClassLoader { public
> SampleClassLoader() { super(); }
>
> public SampleClassLoader(final ClassLoader parent) {
> super(parent); }
>
> @Override protected boolean validateJarFile(final File file) throws
> IOException { System.out.println("---Load: " +
> file.getName()); return super.validateJarFile(file); } }
>
> I have put it in a jar in ../apache-tomcat/lib
>
> I have a webapp : apache-tomcat/lwebapps/sample
>
> I have modified  apache-tomcat/lwebapps/sample/meta-inf/context.xml
> to use this classloader :
>
>
> 
>
> 
> WEB-INF/web.xml
>
>   delegate="true"
> loaderClass="com.axway.tnt.compliance.SampleClassLoader"/>
>
> 
>
>
> And it's working fine.
>
> But i don't want to modify my tomcat, i want to put my classloader
> in my webapp/lib and in this case i have :
>
>
> java.lang.ClassNotFoundException:
> com.axway.tnt.compliance.SampleClassLoader at
> java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
> org.apache.catalina.loader.WebappLoader.createClassLoader(WebappLoader
.java:723)
>
>
at
org.apache.catalina.loader.WebappLoader.startInternal(WebappLoader.java:
582)
> Caused by: org.apache.catalina.LifecycleException: Failed to start
> component [WebappLoader[/sample]] at
> org.apache.catalina.loader.WebappLoader.startInternal(WebappLoader.jav
a:632)
>
>
Caused by: java.lang.ClassNotFoundException:
com.axway.tnt.compliance.SampleClassLoader
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
> org.apache.catalina.loader.WebappLoader.createClassLoader(WebappLoader
.java:723)
>
>
at
org.apache.catalina.loader.WebappLoader.startInternal(WebappLoader.java:
582)
>
>
> Any idea to do that ?

Sorry, this is not possible, because otherwise your SampleClassLoader
would have to load itself. You will have to package your custom
ClassLoader and install it into Tomcat's lib/ directory.

- -chris


Hi,

thanks for the response even if it is'nt the one i was expected :-).


Erwan

[ANN] Apache Tomcat 7.0.72 released

2016-09-20 Thread Violeta Georgieva 
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.72.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.70. The notable changes since 7.0.70 include:


- Update the packaged version of the Tomcat Native Library to 1.2.8
- Treat paths used to obtain a request dispatcher as encoded (configurable)


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

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

2016-09-20 Thread 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

2016-09-20 Thread 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