Exception calling web service over SSL since upgrade to SP4
Ted Bell
Ranch Hand
Joined: Jan 21, 2002
Posts: 52
posted
0
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:
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):
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.
Ulf Dittmer
Marshal
Joined: Mar 22, 2005
Posts: 35241
7
posted
0
Since there are no takers here, I'll move it over to the Weblogic forum.
0
