Re-signing Forms JAR file
5 September 2005 at 09:58 CEST | In Forms, Oracle, SUN JPI/JVM, Signing and certificates | 4 CommentsThe default JAR file that comes with Oracle Forms is signed by a certificate issued to “Developer” by “Oracle”. This doesn’t sound very trustworthy to most users. Besides that, the dialog of Sun’s JPI/JRE mentions that the security certificate was issued by a company that is not trusted.

You can choose to re-sign the JAR file yourself and have your own company name in this warning. You can even get Sun JPI to trust the company that signed it.
When you’re going to re-sign the JAR file you can either buy a commercial certificate from any of the well known vendors like Verisign or Thawte. You can also decide to issue your own certificate. This is not as secure, but might do the trick for you. If you issue your own certificate, you’re best of using Oracle Certificate Authority, which is part of Oracle Application Server. That way, you can make all your self-issued certificates use one and the same root certificate. You just have to import this one root certificate in your browser and JVM and all your self-issued certificates will be trusted. Read another blog entry for more information.
Signing the JAR file with your own certificate is documented in an Oracle whitepaper. The section about “Problems With Multiple Signing Identities” explains how to resign the f90all.jar yourself. I just used the JDK that comes with Oracle Developer Suite. Be sure to use RSA as the key algorithm as the default won’t work. Basically the steps using Oracle Certificate Authority are as follows:
rem Create key (and keystore) %ORACLE_HOME%\jdk\bin\keytool -genkey -keyalg RSA -dname "cn=YourName,o=YourCompany,c=NL" -alias signing_cert -keypass ******** -keystore c:\keystore -storepass ******** -validity 2922 rem Create Certification request (get it approved by CA) %ORACLE_HOME%\jdk\bin\keytool -certreq -file c:\signing_cert.req -alias signing_cert -keypass ******** -keystore c:\keystore -storepass ******** rem Import the root certificate of your OCA %ORACLE_HOME%\jdk\bin\keytool -import -alias root_cert -file c:\root.cer -keystore c:\keystore -storepass ******** rem Import the approved certificate into the keystore %ORACLE_HOME%\jdk\bin\keytool -import -alias signing_cert -file c:\signing_cert.cert -keypass ******** -keystore c:\keystore -storepass ******** rem extract Forms 90420 JAR file md c:\temp\f90all cd c:\temp\f90all %ORACLE_HOME%\jdk\bin\jar -xvf %ORACLE_HOME%\forms90\java\f90all.jar rem delete meta information from extracted JAR rd c:\temp\f90all\META-INF /s/q rem repackage JAR cd c:\temp\f90all %ORACLE_HOME%\jdk\bin\jar -cvf c:\temp\f90all_repackaged.jar *.* rem Sign the new JAR %ORACLE_HOME%\jdk\bin\jarsigner -keystore c:\keystore -storepass ******** -keypass ******** c:\temp\f90all_repackaged.jar signing_cert
If you do not want to use Oracle Certificate Authority you can just skip the steps to create a certification request and importing the two certificates from OCA. You can also choose to buy a real signing certificate in which case you do not use OCA to process your certification request, but you use a trusted company like Verisign or Thawte.
Now that you have your self-signed JAR file, just place it in the forms90/java directory on your application server and refer to it in the archive and/or archive_jini parameters of your formsweb.cfg.
Sun JPI will still raise a dialog-box asking the user to allow the Forms applet to run outside of its sandbox. You cannot get rid of this dialog as it is by the design of Java that the user always has to allow an applet to run outside of its sandbox. But now at least it shows your own name and not “Oracle” and “Developer”.
If you’ve not bought a “real” certificate from a commercial party, the dialog will warn the user that the security certificate was issued by a company that is not trusted. You can get rid of this one by importing your own certificate (or root certificate from OCA) in the keystore of your JVM. You can read all about that in a separate blog entry. In the end your warning will look like this:

Importing self-signed certificates in Sun JPI
5 September 2005 at 09:57 CEST | In Forms, Oracle, SUN JPI/JVM, Signing and certificates | 7 CommentsAs you might now from other blog entries, we’re running Oracle Forms using Sun’s JRE/JPI and not JInitiator. We’re using commercial certificates for some of our webservers, but we’re also using some self-signed certificates for our development/test server and for code signing. Up until now all users where presented with a warning about these “invalid” certificates by Sun’s JPI.
I tried before to import our self-issued certificates in Sun’s keystore, but I never managed to get it working. It was allways asking for the keystore password, and I couldn’t find anywhere what the default password for such a keystore would be. Lukelly I found it today on the internet and the default password is "changeit". That’s probably some good advice
I’ve blogged before about importing certificates in JInitiator. You could read there that we are using oracle Certificate Authority to create our own certificates. The advantage to that is that all self-issued certificates are “children” of our self-issued root certificate. This gives me the advantage that I only have to import this root certificate in a browser/JVM and not all certificates that were created of this root certificate.
You could export the certificate from OCA, or you can just get it from Internet Explorer. Just visit a HTTP site that uses the certificate and double-click on the yellow lock in the status bar. Go to the Certification Path tab and double-click the root certificate to open it. No go to the Details tab. If you do not have a self-issued root certificate you can just start of at the Details tab of your initial certificate. Click on Copy to File and save the certificate in base64 encoding.
Now open a command box and change your working directory to the lib\security subdirectory of your Sun JPI. Then execute the keystore command to import your certificate:
C:\>cd "\Program Files\Java\j2re1.4.2_09\lib\security"
C:\Program Files\Java\j2re1.4.2_09\lib\security>..\..\bin\keytool
-import -file "c:\temp\self.cer" -keystore cacerts
-storepass changeit -alias myRootCA
Owner: O=Eurotransplant International Foundation, C=NL
Issuer: O=Eurotransplant International Foundation, C=NL
Serial number: 1
Valid from: Mon Feb 21 08:59:26 CET 2005
until: Thu Feb 19 08:59:26 CET 2015
Certificate fingerprints:
MD5: **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**
SHA1: **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**
Trust this certificate? [no]: yes
Certificate was added to keystore
Now, when you try to start your Oracle Forms application the applet will no longer complain about untrusted certificates for SSL communication. It will still ask the user to accept the Java applet as it is trying to run outside its sandbox. You cannot get rid of this message, as it is by design that Java will ask the user permission for an applet to run outside its sandbox.
The applet as shipped by Oracle is signed by “Developer/Oracle” and uses a self-issued certificate. If you want to get rid of this, you’ll have to re-sign the JAR file yourself with your own certificate. For more information see another blog entry.
Using self-signed SSL certificates with JInitiator
11 July 2005 at 10:26 CEST | In Forms, Oracle, Signing and certificates | 14 CommentsAs you might know from previous blog entries we are using Sun JPI for running Oracle Forms. We are having a performance issue and I would like to test if it also exists using Oracle’s own JInitiator. I’ve set up a new configuration section in my formsweb.cfg to start the application with JInitiator in stead of Sun JPI.
However, we use SSL encryption on all our webservers including Forms. For all non-production servers these certificates are self-signed. Sun JPI raises a nice warning and asks the user what to do, but JInitiator just refuses to setup the connection and fails. Below are the steps to include a self-signed certificate in the store of JInitiator. Even better, I’ve included our self-signed root-certificate so that all development/test servers are accepted by JInitiator.
First of all, try to start the application. JInitiator v1.3.1.18 will start and the applet will fail with 'java.lang.ClassNotFoundException: oracle.forms.engine.Main'. Open the JInitiator console (right-mouse click on the JInitiator icon in the system tray) and it will show 'java.io.IOException: javax.net.ssl.SSLException: SSL handshake failed: X509CertChainInvalidErr'
Double-click on the yellow lock in the status bar of Internet Explorer. Navigate to the ‘Certification Path’ tab and see if the self-signed certificate has a root certificate. If that’s the case, select the root certificate and press the ‘View Certificate’ button. If there is no root certificate, just continue with the self-signed cerficate.
Go to the ‘Details’ tab and press the ‘Copy to File’ button. Save the certificate as Base-64 encoded. Open the base-64 encoded certificate in a text-editor. Copy the entire contents (including BEGIN CERTIFICATE and END CERTIFICATE lines).
Now open the certdb.txt file in the lib/security directory of your Oracle JInitiator (in my case C:\Program Files\Oracle\JInitiator 1.3.1.18\lib\security\certdb.txt). Add the copied certificate to this file and prepend it with some comment lines (beginning with #) to explain what the certificate is.
Close any open web browsers to close the associated JVM’s and try to start the application again. It should work.
Update 5-sep-2005: Also see http://www.oratransplant.nl/2005/09/05/importing-self-signed-certificates-in-sun-jpi/ on how to import your self-signed certificate in Sun’s JPI/JRE.
Powered by WordPress with Pool theme design by Borja Fernandez.
Entries and comments feeds.

