If Forms has no awareness of digital signature certificates or anything else related to it, would resigning frmall.jar or any other required Oracle supplied jar with a trusted certificate that we purchased work?
Technically, yes. Resigning Oracle provided jars with a trusted and known certificate will work. However, Oracle does not recommend nor will they support doing that. The reason is that if you attempt to alter the Oracle provided jars and you then have issues, Oracle has no idea if the problem is being caused because their product is broken or because you improperly resigned/altered a jar file that we knew worked when it was delivered. We cannot take responsibility if you damage something we knew previously worked, but didn't after you altered it. This obviously does not apply to things like configuration files because, well that's what configuration files are for... to be configured.
Here is a quote from the Oracle Technical Support Policy:
Technical support is provided for issues (including problems you create) that are demonstrable in the currently supported release(s) of an Oracle licensed program, running unaltered, and on a certified hardware, database and operating system configuration, as specified in your order or program documentation.
So what this basically means is that assuming you have not altered what is not allowed to be altered Oracle Support will do the best they can to assist in determining if the Oracle product is not functioning as expected. However, it is your responsibility to investigate that part of issues that are not part of the Oracle product. In other words, don't assume that Oracle Support will help you determine what is broken about your Windows operating system. That would be something you need to address with Microsoft.
I think I figured out a fix for this:
1. Close browser. 2. Open Terminal. 3. Enter: cd /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/ 4. Enter: sudo open –a textedit java.security 5. If the java.security file comes up as “locked”, close TextEdit and run the following command: sudo chflags nouchg java.security, repeat step 4. 6. In the java.security file, Command+Find to search for jdk.jar 7. Delete MD5 so the resulting line is: jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024 8. Save file and exit TextEdit. 9. Quit Terminal. 10. Restart browser.
1. Close browser. 2. Run Notepad as administrator. 3. Open java.security in C:\Program Files\Java\jre1.8.0_131\lib\security (you may have to change the file type from ‘Text Document (*txt) to ‘All Files’ to see the file. 4. After opening the file, Ctrl+Find to search for jdk.jar 5. Delete MD5 so the resulting line is: jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024 6. Save the file and exit Notepad. 7. Restart browser.
Thanks. Worked for us.
Thank you! You are a life safer! That worked perfectly. Of course I contacted the application administrator that they should update their certificate. After that I will rollback to the default java.security file.
You don't even need to purchase a certificate.
Just create a signing certificate in your keystore following the instructions at:
remove the previous signature from all signed jar files:
zip -d filename.jar 'META-INF/*.SF' 'META-INF/*.RSA'
and then sign again all the jar files with the new certificate
jarsigner -keystore path_to_keystore filename.jar aliasname
you'll be prompted with both the keystore password and the certificate password (that protects the private key)
I made it work with forms 10.2
Hope it helps,
We have also encountered issue with MD5 signed jars and use already the Deployment Rule Set. When we update the Deployment Rule Set with the SHA256 certificate fingerprints of the MD5 signed jars, it did not work.
Is option 2 verified? Is it possible to overrule the jdk.jar.disabledAlgorithms settings with Deployment Rule Set settings?
At the end of the day, the right thing to do is upgrade, most anything else is just a hack. If you are working in a production environment I don't recommend tinkering. I understand the difficulties sometimes associated with upgrading, but the real question is/are: Is your organization concerned about having ongoing support AND are they concerned about ensuring the system and application are secure?. If either one of these questions is answered with "yes" then I'm sure finding a way to upgrade can be made to happen.
As I said, the solution to the problem in this thread is to do one of the following:
- Get new jars from Oracle that have been properly signed
- Upgrade to the latest version (which includes new jars)
- Resign the jars and update the manifest on your own (not recommended)
- Attempt to hack the client side Java .properties files (not recommended)
The last two options (3 and 4) fall into that "hack" category. Although they might not technically be hacks, they are considered not supportable and therefore you would be doing this at your own risk. Given that the entire discussion relates to security, doing something that isn't supportable would not be something I would personally consider doing UNLESS I fully understood the risk involved and understood my organization's risk tolerance.
We've had the same issue in our environment after a recent upgrade. We've already gone after the vendor and application owners to upgrade Oracle Forms or at least have them resign the applets. Our issue is that the DRS doesn't appear to be effective at mitigating the issue as it usually is fully capable of. Granted I'm not going so far as to allow the site to use a previous version of Java, as I don't like app owners even knowing that's an option. If there a setting in the DRS I'm unaware of that could get them up and running while we wait on the vendor or are we better off downgrading their JRE while we wait. As you might expect that's one of the least favorite options.