Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Exception calling web service over SSL since upgrade to SP4

 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

We recently upgraded from WebLogic Server 8.1 to 8.1 SP4. This has an associated upgrade in the JDK from (for us) 1.4.1_07 to 1.4.2_05 (bundled with SP4). Since the upgrade, we have had some issues making a particular web service call over SSL. The application is deployed as a web application deployed in an EAR file. The web service uses a self-signed certificate (one way), and was working fine prior to the upgrade. We use (in a separate module of the application) an nCipher device and software to encrypt sensitive data. This portion is actually working correctly, but the outbound web service call (having nothing to do with nCipher) is now failing since the upgrade. The precise error is:

java.security.InvalidKeyException: In nCImportedKey with key class - javax.crypto.spec.SecretKeySpec, algorithm RC4

A portion of the stack trace reveals something puzzling (to me at least):


at com.ncipher.provider.nCImportedKey.<init>(nCImportedKey.java:74)
at com.ncipher.provider.Utils.getKeySize(Utils.java:500)
at com.ncipher.provider.nCBlockCipher.engineGetKeySize(nCBlockCipher.java:485)
at javax.crypto.Cipher.init(DashoA6275)
at com.certicom.tls.provider.Cipher.init(Unknown Source)
at com.certicom.tls.ciphersuite.SecurityParameters.createWriteCipher(Unknown Source)

Notice that at some point the 'certicom' libraries/provider (bundled with WebLogic) give way to the ncipher classes (which again should not be used for the HTTPS call, only to encrypt customer data). Thinking this is might be an issue with the security providers in the java.security file. Before the upgrade (1.4.1_07):

security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=cryptix.provider.Cryptix
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=com.ncipher.provider.km.nCipherKM
security.provider.7=sun.security.jgss.SunProvider

After the upgrade, under JDK 1.4.2_05:

security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=cryptix.provider.Cryptix
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.ncipher.provider.km.nCipherKM

The nCipher provider was moved to the bottom of the list as a troubleshooting step in attempts to block that provider for being used at the wrong time. No changes made thus far have had any effect. WebLogic support have suggested to remove the "com.sun.crypto.provider.SunJCE" entry from the security file, which we will be doing tomorrow.

We tried the solution described in CR206178, which was to move all the jar files from the /jre/lib/ext folder of JDK 1.4.1 into the /jre/lib/ext of JDK 1.4.2. This had no effect.

Stack trace of error printed to stderr:

java.security.InvalidKeyException: In nCImportedKey with key class - javax.crypto.spec.SecretKeySpec, algorithm RC4
at com.ncipher.provider.nCImportedKey.<init>(nCImportedKey.java:74)
at com.ncipher.provider.Utils.getKeySize(Utils.java:500)
at com.ncipher.provider.nCBlockCipher.engineGetKeySize(nCBlockCipher.java:485)
at javax.crypto.Cipher.init(DashoA6275)
at com.certicom.tls.provider.Cipher.init(Unknown Source)
at com.certicom.tls.ciphersuite.SecurityParameters.createWriteCipher(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.changeCipherSpec(Unknown Source)
at com.certicom.tls.record.handshake.ClientStateReceivedCertificate.handle(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Source)

Additional trace information from the WLS domain log file:

<Exception during handshake, stack trace follows
java.lang.IllegalStateException: Cipher not initialized
at javax.crypto.Cipher.update(DashoA6275)
at com.certicom.tls.provider.Cipher.update(Unknown Source)
at com.certicom.tls.record.MessageEncryptor.compressEncryptSend(Unknown Source)
at com.certicom.tls.record.MessageEncryptor.compressEncryptSend(Unknown Source)
at com.certicom.tls.record.MessageFragmentor.write(Unknown Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.write(Unknown Source)
at com.certicom.tls.record.handshake.ClientStateReceivedCertificate.handle(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Source)
at com.certicom.tls.record.ReadHandler.processRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.io.OutputSSLIOStreamWrapper.write(Unknown Source)
at com.certicom.net.ssl.HttpsClient.doHandshake(Unknown Source)
at com.certicom.net.ssl.internal.HttpURLConnection.getInputStream(Unknown Source)
at weblogic.webservice.client.https.HttpsURLConnection.getInputStream(HttpsURLConnection.java:228)
at weblogic.webservice.tools.wsdlp.DefinitionFactory.createDefinition(DefinitionFactory.java:106)
at weblogic.webservice.tools.wsdlp.WSDLParser.<init>(WSDLParser.java:76)
at weblogic.webservice.WebServiceFactory.createFromWSDL(WebServiceFactory.java:108)
at weblogic.webservice.core.rpc.ServiceImpl.<init>(ServiceImpl.java:91)
at weblogic.webservice.core.rpc.ServiceImpl.<init>(ServiceImpl.java:66)



<NEW ALERT with Severity: FATAL, Type: 40
java.lang.Exception: New alert stack
at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Source)
at com.certicom.tls.record.ReadHandler.processRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.io.OutputSSLIOStreamWrapper.write(Unknown Source)
at com.certicom.net.ssl.HttpsClient.doHandshake(Unknown Source)
at com.certicom.net.ssl.internal.HttpURLConnection.getInputStream(Unknown Source)
at weblogic.webservice.client.https.HttpsURLConnection.getInputStream(HttpsURLConnection.java:228)
at weblogic.webservice.tools.wsdlp.DefinitionFactory.createDefinition(DefinitionFactory.java:106)
at weblogic.webservice.tools.wsdlp.WSDLParser.<init>(WSDLParser.java:76)
at weblogic.webservice.WebServiceFactory.createFromWSDL(WebServiceFactory.java:108)
at weblogic.webservice.core.rpc.ServiceImpl.<init>(ServiceImpl.java:91)
at weblogic.webservice.core.rpc.ServiceImpl.<init>(ServiceImpl.java:66)


The same web service call made in an environment without the nCipher device and software has no issues. A web service call over HTTPS to a completely different target run outside the WebLogic server (using the same JDK 1.4.2_05) on a server with the nCipher device and software installed also works fine.

Hoping someone might have had a similar problem or be familiar enough with security providers, etc. and be able to offer some suggestions.

Thanks for any help.
 
Rancher
Posts: 43016
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since there are no takers here, I'll move it over to the Weblogic forum.
 
    Bookmark Topic Watch Topic
  • New Topic