As of JRE version 1.7.0_51 unsigned Java Applets are blocked by default. This prevents users from running the JIS Java client. Our server and XHTML client are not affected. See in depth discussion of the reasons for this in my previous posts Java 1.7.0_21 and its impact on JIS - webMethods - Software AG Tech Community & Forums and Deployment using Java 1.7.0_25 - webMethods - Software AG Tech Community & Forums
There is no good workaround, Oracle really insists that you sign your code. However if you need an immediate solution and are willing to settle for a workstation specific solution which requires administrator rights to implement, you can add the URL site to the exception list - Java Control Panel::Security Tab click “Edit Site List” and add the domain name from which the Applet is downloaded to the list of sites. Confirm any security warning in the process. Restart the browser. This will reduce security level only for your specific web site.
Java will still display a warning message but it won’t block you.
You can also use this workaround in your development environment.
- Obtain a code signing certificate (not SSL certificate and not a test certificate) your IT department should have one.
- Sign your code.
As of JIS 9.2.1 the signing procedure is automated by the new IzPack runtime installation procedure. Please read about it in the product release notes. We warmly recommend that you use the automated procedure instead of the procedure outlined below.
Note: this is a fairly complex and time consuming procedure, we cannot do it for you but we can give you a few hints.
Read my previous forum posts on this subject.
Read the official tutorial (seriously):
Download and Install the latest Java JDK 1.7 or 1.8 (not JRE), you can download it from here:
Add the <JAVA_HOME>\bin folder to your PATH environment variable.
Create a manifest file named MANIFEST.MF with the following text, make sure to leave one blank line at the end. Use notepad ++ for editing:
- Package a Jar file per library without manifest. We recommend that you create one Jar file per library.
Assuming your library is named MYLIB you should open a command window and navigate to the \JacadaFiles\classes folder then run the following command after replacing MYLIB with your actual library name:
jar cvf MYLIB.jar appls\MYLIB\user appls\MYLIB\original appls\MYLIB\images appls\MYLIB\resources
Then update the manifest file you created earlier into the Jar file:
jar uvmf \MANIFEST.MF MYLIB.jar
Now sign the Jar file (you may need to make some changes here depending on your specific certificate format, consult with IT):
jarsigner -storepass -storetype PKCS12 -keystore -tsa http://tsa.starfieldtech.com/
Open the resulting Jar file using any zip software and verify that a MANIFEST.MF file exists in the META-INF folder and that it contains the text you added above.
Copy the Jar file to the …\classes folder of your runtime installation and list it in the archive attribute of the applet tag of the launcher Html.
Here is a simple package.bat file which can serve as example:
jar cvf cst%1.jar appls%1\user appls%1\original appls%1\images appls%1\resources
jar uvmf cst\signed-MYLIB.mf cst%1.jar
jarsigner -keystore c:\jis\mykeystore -signedjar cst%1-signed.jar -storepass mypass cst%1.jar
To invoke it run from the classes directory:
The resulting Jar file is MYLIB-signed.jar placed in the cst folder.
Delete the folders …\classes\appls<AppName>\user and …\classes\appls<AppName>\original from your runtime installation (not from the development environment). These folders contain the .class files which are otherwise loaded before the signed Jar file.
Clean the Java Plugin cache - from the Windows Control Panel - Java - Java Control Panel - General tab click the <Settings…> button and then
Now open the browser and the Applet should load without any security prompt.
If you perform the above steps and still encounter a problem, we ask that you send the following information for analysis:
- Log of the command window showing the commands you performed (omit any sensitive information such as certificate passwords).
- The Jar file itself.
- The log from the Java plugin console when an error occurs.
- Screen capture of error or warning dialog