SHA-1/RSA/PKCS#1: Not Initialized -- websphere

Question

Hi,

I am deploying the Java FTP/s client library on a WebSphere application server. I have the same library deployed on a JBoss App Server, and SSL Handshake is successful. However, on WebSphere, I am getting the following:

2009-07-30 16:42:42,183 INFO [puretls] PureTLS debug level=0
2009-07-30 16:42:42,185 DEBUG [SSLFTPClient] Setting custom validator to com.enterprisedt.net.ftp.ssl.SSLFTPStandardValidator
2009-07-30 16:42:42,429 DEBUG [SSLFTPClient] Setting custom validator to com.enterprisedt.net.ftp.ssl.SSLFTPStandardValidator
2009-07-30 16:42:42,429 DEBUG [SSLFTPClient] Created explicit FTPS client.
2009-07-30 16:42:42,429 DEBUG [SSLFTPClient] Connecting to /192.168.1.102:21
2009-07-30 16:42:42,433 DEBUG [StreamSocketFactory] Connecting to 192.168.1.102:21 via standard socket
2009-07-30 16:42:42,444 DEBUG [FTPControlSocket] 220 QAWEB07.qa.com X2 WS_FTP Server 5.0.4 (3449386031)
2009-07-30 16:42:42,445 DEBUG [SSLFTPControlSocket] DISABLE_CONTROL_SSL_CLOSURE=false
2009-07-30 16:42:42,445 DEBUG [SSLFTPControlSocket] DISABLE_CONTROL_WAIT_ON_CLOSE=true
2009-07-30 16:42:42,445 DEBUG [SSLFTPControlSocket] ALLOW_BASIC_CONSTRAINTS_IN_NON_CA=false
2009-07-30 16:42:42,445 DEBUG [FTPControlSocket] ---> AUTH TLS
2009-07-30 16:42:42,933 DEBUG [FTPControlSocket] 234 SSL enabled and waiting for negotiation
2009-07-30 16:42:42,935 DEBUG [SSLFTPControlSocket] Starting SSL handshake on control socket
2009-07-30 16:42:43,028 DEBUG [X509Cert] verify: alg=SHA-1/RSA/PKCS#1,provider=CryptixEDT
2009-07-30 16:42:43,030 ERROR [X509Cert] verify
java.security.SignatureException: SHA-1/RSA/PKCS#1: Not initialized
at com.enterprisedt.cryptix.provider.rsa.Any_RSA_PKCS1Signature.engineUpdate(Unknown Source)
at java.security.Signature$SignatureImpl.engineUpdate(Unknown Source)
at java.security.Signature.update(Unknown Source)
at com.enterprisedt.net.puretls.cert.X509Cert.verify(Unknown Source)
at com.enterprisedt.net.puretls.cert.X509Cert.verifyCertChain(Unknown Source)
at com.enterprisedt.net.puretls.n.B(Unknown Source)
at com.enterprisedt.net.puretls.Z.B(Unknown Source)
at com.enterprisedt.net.puretls.n.E(Unknown Source)
at com.enterprisedt.net.puretls.i.G(Unknown Source)
at com.enterprisedt.net.puretls.SSLSocket.handshake(Unknown Source)
at com.enterprisedt.net.ftp.ssl.SSLFTPControlSocket.H(Unknown Source)
at com.enterprisedt.net.ftp.ssl.SSLFTPClient.auth(Unknown Source)
2009-07-30 16:42:43,041 DEBUG [SSLFTPControlSocket] Caught: com.enterprisedt.net.puretls.SSLThrewAlertException
2009-07-30 16:42:43,041 DEBUG [SSLFTPControlSocket] Inner throwable = com.enterprisedt.net.puretls.cert.CertificateVerifyException
2009-07-30 16:42:43,041 DEBUG [SSLFTPControlSocket] Rethrowing as SSLFTPCertificateException
2009-07-30 16:42:43,041 DEBUG [SSLFTPClient] Forcing disconnect
2009-07-30 16:42:43,042 WARN [FTPClient] cancelTransfer() called


Please let me know how to resolve this.

Answer 1

Please set the logging level to ALL and email support with the entire log file (zipped).

Answer 2

Please set the logging level to ALL and email support with the entire log file (zipped).

I set the log level to "ALL", but the logging was about the same. I have emailed support with the log file.

Answer 3

We've emailed you a link to a patched jar file - let us know if you haven't received it & we'll send via a private message.

Answer 4

We've emailed you a link to a patched jar file - let us know if you haven't received it & we'll send via a private message.

Thanks! I was able to download this JAR and try it out. The fix works for us on Websphere now.

Out of curiosity, was this a bug that only shows up on WebSphere? Is this something that will be put into the latest version?

Answer 5

I don't think it is related to Websphere but rather to the IBM JVM.

In the Signature class (which the RSA signature class with the error is derived from), in the Sun code there's things like:

public final void initVerify(PublicKey publicKey) 
       throws InvalidKeyException {
   engineInitVerify(publicKey);
   state = VERIFY;
    }

and

public final boolean verify(byte[] signature) throws SignatureException {
   if (state == VERIFY) {
       return engineVerify(signature);
   }
   throw new SignatureException("object not initialized for " +
                 "verification");

So each signature method call either sets or checks the 'state' variable before calling the 'engineXXX' methods which are actually implemented by the subclass (i.e. our code).

We also check the state variable in our code, but we don't really need to do this, as the Sun code checks it before calling our code anyway.

It looks like the IBM JVM doesn't actually bother using the 'state' variable - so it isn't correctly set and our code throws an exception when it checks it.

Easy fix - remove the state checks from our code. Sun JVM checks anyway and IBM JVM doesn't appear to use it.

You can use this patch and we'll add it to 3.1.1 in due course.

Comments

BLAs can be used to start and stop multiple Java EE applications at once. This might be useful if operationally several applications have to be treated together or if there are run-time dependencies between applications. This is especially the case if scripting is used; AdminTask.startBLA and AdminTask.startBLA provide an easy way to restart several "regular" applications.