Could not create cipher AES (error -12229 with Netscape/FireFox)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Could not create cipher AES (error -12229 with Netscape/FireFox)

Benjamin Benson
I have spent hours researching this problem but the answer has eluded  
me...

I have Jetty configured for SSL support and it is working on browsers  
other than Netscape/Firefox.  I receive a -12229 error code from  
Netscape after certificates are accepted.  There is a lot of discussion  
on this - and it appears that Jetty is unable to support the AES  
alogrithm.  I have added the Bouncy Castle provider as was recommended  
but Jetty is not showing an attempt to use it:


1)  I added a line to the java security policy to statically register  
the new provider:

security.provider.1=sun.security.provider.Sun
security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.rsajca.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider


2)  I added the bouncy castle jar to  
java/jre/lib/ext/bcprov-jdk14-129.jar

3)  I have created a self-signed test keystore following the exact  
instructions show on Jetty's tutorial  (I get the same results whether  
I use a purchased certificate or the self-signed one -- so I'm pretty  
sure it has nothing to do with the certificate.  Here's my jetty.xml  
configuration:

   <Call name="addListener">
     <Arg>
       <New class="org.mortbay.http.SunJsseListener">
         <Set name="Port">443</Set>
         <Set name="PoolName">P1</Set>
         <Set name="MaxIdleTimeMs">30000</Set>
         <Set name="lowResources">30</Set>
         <Set name="LowResourcePersistTimeMs">2000</Set>
<!--         <Set  
name="KeystoreProviderName">org.bouncycastle.jce.provider.BouncyCastlePr
ovider</Set> -->
         <Set name="Keystore">/spiderline/conf/ssl/keystore</Set>
         <Set name="Password">ardykpatton</Set>
         <Set name="KeyPassword">ardykpatton</Set>

         <Set name="HttpHandler">
           <New class="org.mortbay.http.handler.MsieSslHandler">
             <Set name="UserAgentSubString">MSIE 5</Set>
           </New>
         </Set>
       </New>
     </Arg>
   </Call>

I tried setting the provider directly in the jetty.xml (as shown above  
in comments) but then Jetty complains that there is no such provider!
Here is the error I get with the above configuration when accessing the  
server via SSL from FireFox or Netsacpe:

DEBUG Listener-3 org.mortbay.http.HttpConnection - readRequest() ...
DEBUG P1-1 org.mortbay.http.HttpConnection - EXCEPTION
javax.net.ssl.SSLException: Algorithm missing:
         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.m(DashoA6275)
         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
         at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
         at org.mortbay.util.LineInput.fill(LineInput.java:469)
         at org.mortbay.util.LineInput.fillLine(LineInput.java:547)
         at org.mortbay.util.LineInput.readLineBuffer(LineInput.java:293)
         at org.mortbay.util.LineInput.readLineBuffer(LineInput.java:277)
         at org.mortbay.http.HttpRequest.readHeader(HttpRequest.java:238)
         at  
org.mortbay.http.HttpConnection.readRequest(HttpConnection.java:861)
         at  
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:907)
         at  
org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
         at  
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:
244)
         at  
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
         at  
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Caused by: java.security.NoSuchAlgorithmException: Could not create  
cipher AES/128
         at  
com.sun.net.ssl.internal.ssl.CipherBox$JCECipherBox.a(DashoA6275)
         at com.sun.net.ssl.internal.ssl.SunJSSE_h.a(DashoA6275)
         at  
com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.a(DashoA6275)
         at com.sun.net.ssl.internal.ssl.SunJSSE_ax.b(DashoA6275)
         ... 16 more
Caused by: java.security.NoSuchAlgorithmException: No implementation  
for AES/CBC/NoPadding found
         at com.sun.net.ssl.internal.ssl.SunJSSE_i.d(DashoA6275)
         at com.sun.net.ssl.internal.ssl.SunJSSE_i.a(DashoA6275)
         at  
com.sun.net.ssl.internal.ssl.CipherBox$JCECipherBox.<init>(DashoA6275)
         ... 20 more



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Could not create cipher AES (error -12229 with Netscape/FireFox)

Chris Haynes
No solutions, only observations / questions:

1) This is the first I've seen of a Jetty-Netscape/Firefox problem re SSL. That
combination works fine for me with the server being Suse Linux and with clients
of Suse & WXP pro. Is there something unusual about your JVM/OS?

1) The stack trace and your commentary indicate that the SSL hand-shake is
completing OK. The problem seems to come when content encryption starts.

2) Have you tried putting Bouncy Castle first in the provider sequence? It's jus
a thought that the JVM SSL implementation may stick with the provider which gave
it what it needed to fix the handshake, and not re-search the providers when the
encryption algorithm is needed.

3) These operational details of the way SSL operates are way below Jetty. It
just feeds the parameters into the JVM's security provider interface and let's
it get on with it.  The Jetty code is very short (see the source code - about 30
liones, from memory). However that config. interface is somewhat rich and
confusing, so it is possible that Jetty is missing an opportunity to 'tweak' the
info provided . Do you know of other web servers, with an identical JVM/OS/SP,
on which this does work.

HTH

Chris Haynes



>I have spent hours researching this problem but the answer has eluded  me...
>
> I have Jetty configured for SSL support and it is working on browsers  other
> than Netscape/Firefox.  I receive a -12229 error code from  Netscape after
> certificates are accepted.  There is a lot of discussion  on this - and it
> appears that Jetty is unable to support the AES  alogrithm.  I have added the
> Bouncy Castle provider as was recommended  but Jetty is not showing an attempt
> to use it:
>
>
> 1)  I added a line to the java security policy to statically register  the new
> provider:
>
> security.provider.1=sun.security.provider.Sun
> security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
> security.provider.3=com.sun.net.ssl.internal.ssl.Provider
> security.provider.4=com.sun.rsajca.Provider
> security.provider.5=com.sun.crypto.provider.SunJCE
> security.provider.6=sun.security.jgss.SunProvider
>
>
> 2)  I added the bouncy castle jar to  java/jre/lib/ext/bcprov-jdk14-129.jar
>
> 3)  I have created a self-signed test keystore following the exact
> instructions show on Jetty's tutorial  (I get the same results whether  I use
> a purchased certificate or the self-signed one -- so I'm pretty  sure it has
> nothing to do with the certificate.  Here's my jetty.xml  configuration:
>
>   <Call name="addListener">
>     <Arg>
>       <New class="org.mortbay.http.SunJsseListener">
>         <Set name="Port">443</Set>
>         <Set name="PoolName">P1</Set>
>         <Set name="MaxIdleTimeMs">30000</Set>
>         <Set name="lowResources">30</Set>
>         <Set name="LowResourcePersistTimeMs">2000</Set>
> <!--         <Set
> name="KeystoreProviderName">org.bouncycastle.jce.provider.BouncyCastlePr
> ovider</Set> -->
>         <Set name="Keystore">/spiderline/conf/ssl/keystore</Set>
>         <Set name="Password">ardykpatton</Set>
>         <Set name="KeyPassword">ardykpatton</Set>
>
>         <Set name="HttpHandler">
>           <New class="org.mortbay.http.handler.MsieSslHandler">
>             <Set name="UserAgentSubString">MSIE 5</Set>
>           </New>
>         </Set>
>       </New>
>     </Arg>
>   </Call>
>
> I tried setting the provider directly in the jetty.xml (as shown above  in
> comments) but then Jetty complains that there is no such provider!
> Here is the error I get with the above configuration when accessing the
> server via SSL from FireFox or Netsacpe:
>
> DEBUG Listener-3 org.mortbay.http.HttpConnection - readRequest() ...
> DEBUG P1-1 org.mortbay.http.HttpConnection - EXCEPTION
> javax.net.ssl.SSLException: Algorithm missing:
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.m(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
>         at org.mortbay.util.LineInput.fill(LineInput.java:469)
>         at org.mortbay.util.LineInput.fillLine(LineInput.java:547)
>         at org.mortbay.util.LineInput.readLineBuffer(LineInput.java:293)
>         at org.mortbay.util.LineInput.readLineBuffer(LineInput.java:277)
>         at org.mortbay.http.HttpRequest.readHeader(HttpRequest.java:238)
>         at
> org.mortbay.http.HttpConnection.readRequest(HttpConnection.java:861)
>         at
> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:907)
>         at  org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
>         at
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java: 244)
>         at  org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
>         at  org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> Caused by: java.security.NoSuchAlgorithmException: Could not create  cipher
> AES/128
>         at  com.sun.net.ssl.internal.ssl.CipherBox$JCECipherBox.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SunJSSE_h.a(DashoA6275)
>         at  com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SunJSSE_ax.b(DashoA6275)
>         ... 16 more
> Caused by: java.security.NoSuchAlgorithmException: No implementation  for
> AES/CBC/NoPadding found
>         at com.sun.net.ssl.internal.ssl.SunJSSE_i.d(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SunJSSE_i.a(DashoA6275)
>         at
> com.sun.net.ssl.internal.ssl.CipherBox$JCECipherBox.<init>(DashoA6275)
>         ... 20 more
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>
>
>





-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Could not create cipher AES (error -12229 with Netscape/FireFox)

Greg Wilkins-5
In reply to this post by Benjamin Benson

The bouncy castle stuff is only needed for certificate manipulation and
should not be needed to run the server once you have loaded the certificate.

Jetty 5 does not recommend bouncy castle at all.  It also has an updated
listener that just uses the JSSE API rather than the Sun dependant
versions of it.

cheers


Benjamin Benson wrote:

> I have spent hours researching this problem but the answer has eluded  
> me...
>
> I have Jetty configured for SSL support and it is working on browsers  
> other than Netscape/Firefox.  I receive a -12229 error code from  
> Netscape after certificates are accepted.  There is a lot of discussion  
> on this - and it appears that Jetty is unable to support the AES  
> alogrithm.  I have added the Bouncy Castle provider as was recommended  
> but Jetty is not showing an attempt to use it:
>
>
> 1)  I added a line to the java security policy to statically register  
> the new provider:
>
> security.provider.1=sun.security.provider.Sun
> security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
> security.provider.3=com.sun.net.ssl.internal.ssl.Provider
> security.provider.4=com.sun.rsajca.Provider
> security.provider.5=com.sun.crypto.provider.SunJCE
> security.provider.6=sun.security.jgss.SunProvider
>
>
> 2)  I added the bouncy castle jar to  java/jre/lib/ext/bcprov-jdk14-129.jar
>
> 3)  I have created a self-signed test keystore following the exact  
> instructions show on Jetty's tutorial  (I get the same results whether  
> I use a purchased certificate or the self-signed one -- so I'm pretty  
> sure it has nothing to do with the certificate.  Here's my jetty.xml  
> configuration:
>
>   <Call name="addListener">
>     <Arg>
>       <New class="org.mortbay.http.SunJsseListener">
>         <Set name="Port">443</Set>
>         <Set name="PoolName">P1</Set>
>         <Set name="MaxIdleTimeMs">30000</Set>
>         <Set name="lowResources">30</Set>
>         <Set name="LowResourcePersistTimeMs">2000</Set>
> <!--         <Set  
> name="KeystoreProviderName">org.bouncycastle.jce.provider.BouncyCastlePr
> ovider</Set> -->
>         <Set name="Keystore">/spiderline/conf/ssl/keystore</Set>
>         <Set name="Password">ardykpatton</Set>
>         <Set name="KeyPassword">ardykpatton</Set>
>
>         <Set name="HttpHandler">
>           <New class="org.mortbay.http.handler.MsieSslHandler">
>             <Set name="UserAgentSubString">MSIE 5</Set>
>           </New>
>         </Set>
>       </New>
>     </Arg>
>   </Call>
>
> I tried setting the provider directly in the jetty.xml (as shown above  
> in comments) but then Jetty complains that there is no such provider!
> Here is the error I get with the above configuration when accessing the  
> server via SSL from FireFox or Netsacpe:
>
> DEBUG Listener-3 org.mortbay.http.HttpConnection - readRequest() ...
> DEBUG P1-1 org.mortbay.http.HttpConnection - EXCEPTION
> javax.net.ssl.SSLException: Algorithm missing:
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.m(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
>         at org.mortbay.util.LineInput.fill(LineInput.java:469)
>         at org.mortbay.util.LineInput.fillLine(LineInput.java:547)
>         at org.mortbay.util.LineInput.readLineBuffer(LineInput.java:293)
>         at org.mortbay.util.LineInput.readLineBuffer(LineInput.java:277)
>         at org.mortbay.http.HttpRequest.readHeader(HttpRequest.java:238)
>         at  
> org.mortbay.http.HttpConnection.readRequest(HttpConnection.java:861)
>         at  
> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:907)
>         at  org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
>         at  
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java: 244)
>         at  org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
>         at  org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> Caused by: java.security.NoSuchAlgorithmException: Could not create  
> cipher AES/128
>         at  
> com.sun.net.ssl.internal.ssl.CipherBox$JCECipherBox.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SunJSSE_h.a(DashoA6275)
>         at  
> com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SunJSSE_ax.b(DashoA6275)
>         ... 16 more
> Caused by: java.security.NoSuchAlgorithmException: No implementation  
> for AES/CBC/NoPadding found
>         at com.sun.net.ssl.internal.ssl.SunJSSE_i.d(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SunJSSE_i.a(DashoA6275)
>         at  
> com.sun.net.ssl.internal.ssl.CipherBox$JCECipherBox.<init>(DashoA6275)
>         ... 20 more
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

RE: Re: Could not create cipher AES (error -12229 with Netscape/FireFox)

Jiang, Tony
In reply to this post by Benjamin Benson
J2SE 5.0 supports AES by default.
security.provider.5=com.sun.crypto.provider.SunJCE

If you are going to test encryption higher than 128 bits
(such as 192 bits or 256 bits), please make sure you
have download the Java(TM) Cryptography Extension
(JCE) Unlimited Strength Jurisdiction Policy Files 5.0.
The link can be found here:

http://java.sun.com/j2se/1.5.0/download.jsp


Cheers,
Tony.


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Greg
Wilkins
Sent: Thursday, August 04, 2005 9:23 AM
To: [hidden email]
Subject: [Jetty-support] Re: Could not create cipher AES (error -12229
with Netscape/FireFox)


The bouncy castle stuff is only needed for certificate manipulation and
should not be needed to run the server once you have loaded the
certificate.

Jetty 5 does not recommend bouncy castle at all.  It also has an updated
listener that just uses the JSSE API rather than the Sun dependant
versions of it.

cheers


Benjamin Benson wrote:
> I have spent hours researching this problem but the answer has eluded

> me...
>
> I have Jetty configured for SSL support and it is working on browsers

> other than Netscape/Firefox.  I receive a -12229 error code from  
> Netscape after certificates are accepted.  There is a lot of
discussion  
> on this - and it appears that Jetty is unable to support the AES  
> alogrithm.  I have added the Bouncy Castle provider as was recommended

> but Jetty is not showing an attempt to use it:
>
>
> 1)  I added a line to the java security policy to statically register

> the new provider:
>
> security.provider.1=sun.security.provider.Sun
> security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider
> security.provider.3=com.sun.net.ssl.internal.ssl.Provider
> security.provider.4=com.sun.rsajca.Provider
> security.provider.5=com.sun.crypto.provider.SunJCE
> security.provider.6=sun.security.jgss.SunProvider
>
>
> 2)  I added the bouncy castle jar to
java/jre/lib/ext/bcprov-jdk14-129.jar
>
> 3)  I have created a self-signed test keystore following the exact  
> instructions show on Jetty's tutorial  (I get the same results whether

> I use a purchased certificate or the self-signed one -- so I'm pretty

> sure it has nothing to do with the certificate.  Here's my jetty.xml  
> configuration:
>
>   <Call name="addListener">
>     <Arg>
>       <New class="org.mortbay.http.SunJsseListener">
>         <Set name="Port">443</Set>
>         <Set name="PoolName">P1</Set>
>         <Set name="MaxIdleTimeMs">30000</Set>
>         <Set name="lowResources">30</Set>
>         <Set name="LowResourcePersistTimeMs">2000</Set>
> <!--         <Set  
>
name="KeystoreProviderName">org.bouncycastle.jce.provider.BouncyCastlePr

> ovider</Set> -->
>         <Set name="Keystore">/spiderline/conf/ssl/keystore</Set>
>         <Set name="Password">ardykpatton</Set>
>         <Set name="KeyPassword">ardykpatton</Set>
>
>         <Set name="HttpHandler">
>           <New class="org.mortbay.http.handler.MsieSslHandler">
>             <Set name="UserAgentSubString">MSIE 5</Set>
>           </New>
>         </Set>
>       </New>
>     </Arg>
>   </Call>
>
> I tried setting the provider directly in the jetty.xml (as shown above

> in comments) but then Jetty complains that there is no such provider!
> Here is the error I get with the above configuration when accessing
the  

> server via SSL from FireFox or Netsacpe:
>
> DEBUG Listener-3 org.mortbay.http.HttpConnection - readRequest() ...
> DEBUG P1-1 org.mortbay.http.HttpConnection - EXCEPTION
> javax.net.ssl.SSLException: Algorithm missing:
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.m(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
>         at
com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
>         at org.mortbay.util.LineInput.fill(LineInput.java:469)
>         at org.mortbay.util.LineInput.fillLine(LineInput.java:547)
>         at
org.mortbay.util.LineInput.readLineBuffer(LineInput.java:293)
>         at
org.mortbay.util.LineInput.readLineBuffer(LineInput.java:277)
>         at
org.mortbay.http.HttpRequest.readHeader(HttpRequest.java:238)
>         at  
> org.mortbay.http.HttpConnection.readRequest(HttpConnection.java:861)
>         at  
> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:907)
>         at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
>         at  
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:
244)
>         at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
>         at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)

> Caused by: java.security.NoSuchAlgorithmException: Could not create  
> cipher AES/128
>         at  
> com.sun.net.ssl.internal.ssl.CipherBox$JCECipherBox.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SunJSSE_h.a(DashoA6275)
>         at  
> com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.a(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SunJSSE_ax.b(DashoA6275)
>         ... 16 more
> Caused by: java.security.NoSuchAlgorithmException: No implementation  
> for AES/CBC/NoPadding found
>         at com.sun.net.ssl.internal.ssl.SunJSSE_i.d(DashoA6275)
>         at com.sun.net.ssl.internal.ssl.SunJSSE_i.a(DashoA6275)
>         at  
> com.sun.net.ssl.internal.ssl.CipherBox$JCECipherBox.<init>(DashoA6275)
>         ... 20 more
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Odd Warning (Part 2)

Tony Seebregts
Hi Greg,

Follow-up to the earlier mail about the Bad Request-Missing Content warning:

Having worked through the logic it seems that a redirect from a servlet
commits the HttpResponse - and in the commit() method the input stream
Expect-Continue flag is cleared. HttpConnection handleNext() then tries
to cleanup the connection and because the Expect-Continue flag that was
there is now cleared, tries to read from a 'closed' InputStream.

I have a temporary workaround which involves setting an additional
pendingExpectContinue flag, but its a huge kluge :-( . Think there might
be a cleaner way to handle it.

regards

Tony Seebregts



> FYI, I'm getting an odd warning with redirects and authentication
> failures:
>
> WARN  [SocketListener0-1] org.mortbay.http.HttpConnection - POST
> /cibecs/test HTTP/1.1 HttpException(400,Bad Request,Missing Content).
>
> Its generated at line 1029 in HttpConnection.
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Odd Warning (Part 2)

Greg Wilkins-5

I've put a fix in CVS that relies on only reading content if the
input stream says there is content to read.

appears to work for my tests.


Tony Seebregts wrote:

> Hi Greg,
>
> Follow-up to the earlier mail about the Bad Request-Missing Content
> warning:
>
> Having worked through the logic it seems that a redirect from a servlet
> commits the HttpResponse - and in the commit() method the input stream
> Expect-Continue flag is cleared. HttpConnection handleNext() then tries
> to cleanup the connection and because the Expect-Continue flag that was
> there is now cleared, tries to read from a 'closed' InputStream.
>
> I have a temporary workaround which involves setting an additional
> pendingExpectContinue flag, but its a huge kluge :-( . Think there might
> be a cleaner way to handle it.
>
> regards
>
> Tony Seebregts
>
>
>
>> FYI, I'm getting an odd warning with redirects and authentication
>> failures:
>>
>> WARN  [SocketListener0-1] org.mortbay.http.HttpConnection - POST
>> /cibecs/test HTTP/1.1 HttpException(400,Bad Request,Missing Content).
>>
>> Its generated at line 1029 in HttpConnection.
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support