Adobe & "com.ibm.jsse2.util.h: No trusted certificate found" error

Suddenly a new error on Websphere Application Server, where Adobe PDF Generator runs:

RemoteException occurred in server thread; nested exception is:
java.rmi.RemoteException: org.omg.CORBA.COMM_FAILURE: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET:
JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security.
Reason: com.ibm.jsse2.util.h: No trusted certificate found vmcid: 0x49421000 minor code: 70 completed: No

Found this 6 point help somewhere on the web (thanks Soorya!):

Hi,
You need to obtain signer certificates from remote machine for SSL configuration.
I have explained you the steps below for the same.
1. From administrative console, follow
Security -> SSL certificate and key management -> key stores and certificates - > NodeDefaultTrustStore -> Signer certificates -> Retrive from port.
2. Enter remote machine name at Host.
3. Enter CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS of the remote machine at Port.
4. Enter Alias for reference.
5. Click “Retrieve signer information”.
6. Apply and save the changes.

Hope it will useful.
Regards,
Soorya Prakash.S

Following the hints, I managed to solve using localhost:9043 for points 2 and 3, and "adobe" for point 4. No reboot needed, the application now transforms into PDF nicely.

The story of the secure connection on Websphere 6.0.0

Once upon a time, our web application required to establish a SSL connection. Therefore we added JavaMail 1.4.1 JARs in our WEB-INF/lib directory, deployed the web application on Websphere 6.0.0 and experienced the application server was still loading its 1.3 version.

LESSON #1: use PARENT_LAST and PARENT_FIRST to determine whether the EAR/WAR file JARs are the last or the first to be loaded. A good explanation was found here.

Once we set PARENT_LAST on the Web Module, we ran into several XML casting related errors, such as: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration. That was because of the presence of unneeded JARs in WEB-INF/lib, eventually conflicting with Websphere ones, and previously bypassed by the PARTENT_FIRST option. Also in this care there's a lot of documentation and explanations, such as here, here, and here. However, what it had to be done was to clean up the unused JARs and/or substitute some of them with proper others.

LESSON #2: as a web application grows with time, it arrives the moment to stop and anlayze how many trash JAR it has collected. Therefore procede per steps:

1. remove all JARs;
2. if you are using the API of some suite, make sure you are using the required JARs;
   
3. add JARs one by one, from the most important to the last important, till all compinling errors go away;
4. go round you web application until you face some run time error, then add the remaining missing JARs. (Any suggestion on better ways is highly accepted!)
   

Now that the application can be started without errors and properly use JavaMail 1.4, we face a new error caused by:
javax.net.ssl.SSLException: Unsupported record version Unknown 111.109
at com.ibm.jsse2.a.b(Unknown Source)
at com.ibm.jsse2.a.a(Unknown Source)

Which seems to be due our current Websphere version (alas, still 6.0.0, while RAD 6.0.2 has it fixed). A fix is available here, even though I found it impossible to download APAR PK32916 by Fix Central. Given the fact it's impossible for us to upgrade WAS as of now, we have to find a workaround, but before that:

LESSON #3: should be needless to say, however better make sure your development team is using locally the same version of application server which is running on the test and production environments.

So, if it is impossible to use IBM JSSE API because they are old (as for JavaMail) and buggy, why not give it a try with SUN JSSE. I know it's dirty, however I extracted jsse.jar from Sun Java SDK 1.4 and added it to WEB-INF/lib. It resulted in a new error, which goes like:
java.net.SocketException: Export restriction: this JSSE implementation is non-pluggable.
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(DashoA12275)

Apparently the walkaround for this issue is reported here, and it says to patch org.apache.axis.components.net.JSSESocketFactory, and shows how. The reason is reported on Java 1.4 release notes, and goes like: "The JSSE implementation provided in this release includes strong cipher suites. However, due to U.S. export control restrictions, this release does not allow alternate "pluggable" SSL/TLS implementations to be used. For more information, please see the JSSE Reference Guide."

LESSON #4: you have to know when to stop even if you would like to carry on with the challenge. There are probably more critical things to deal with, so leave your ego apart.

We'll wait till we upgrade Websphere.