posted 18 years ago
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.
