Forms 12C customers should know this. The jar files/the standard code delivered by Oracle is signed with the Digicert certificates and these certificates, which are there for the code signing, are used ensure the security on the client side. I won't go into the details of how code signing works, and I suppose most of my followers already know this.
Here, I want to share something interesting.. This is based on a true story, on an issue escalated to me.
The environment was a clustered Forms 12C (12.2.1.3). It was highly critical and very crowded.(3000 active users)
The issue appeared suddenly and clients started to complain about the slowness of client-side forms. Actually forms java client startup was taking time and java console gave us the clues.
We had read timeouts recorded in the java console output both for ocsp and crl3 urls of the Digicert..
Following is an example of ocsp related output taken from the java console:
Our java output: network: Connecting socket://ocsp.digicert.com:80 with proxy=DIRECT security: Revocation Status Unknown com.sun.deploy.security.RevocationChecker$StatusUnknownException: java.net.SocketTimeoutException: Read timed out
Clients had internet connection, no issues were found on firewall but we had read timeouts, and we started analyzing it.
We had the following 3 workarounds:
1)Use FSAL mode of running forms.
2)Modify the "Certificate revocation check" to "Publisher's certificate only." Follow Start -> Control Panel -> Java to access the Java Control Panel then click on the Advanced tab. Under "Perform signed code certificate revocation checks on" check the "Publisher's certificate only" or do not check option using radio button. -- note that.
3)Disable ocsp and crl based revocaction checks on the java client using java control panel.
But! our customer didn't accept these.. (due to the difficulty of delivering these configurations to 3000 clients)
Then, we analyzed deeper, and found that the issue is caused by Digicert itself.
Digicert was having troubles giving these ocsp and crl3 services and due to that, forms clients were facing these issues. (openssl can be used to test the revocation checks manually..)
We also found the following web pages in the digicert website and these let us see the current status of digicert services and follow the incidents and planned maintenance tasks (noted to be used for the future)
https://status.digicert.com
https://status.digicert.com/history
Anyways, problem disappeared when the Digicert's crl3 and ocsp services started working again.
But this showed us Oracle's dependency to Digicert. (Oracle Forms in this case), and we had no possible solutions for getting rid of this dependency.
That dependency cannot be destroyed as the forms jar files are signed using the Digicert certificates. Again, workaround comes into picture.
We thought we can resign the jar files with --let's say-- a Verisign certificate and get rid of the dependency to Digicert, but it is not supported.. The default forms jar file should not be signed with any custom certificates.
Anyways.. It was an interesting issue but we learned something.. You can't easily find client-server architecture in the enterprise environments nowadays, but if you have one, this might help you one day.
Again, these tiny little details gives you a lot of information.
Of course information is contextual and it is never absolute! But, this might save your day one day :) --especially if you are in the same context --> using Oracle Forms..
By the way, clients having Oracle Forms 12.2.1.3 should consider 12.2.1.4 upgrade.
Actually it was expected that customers will move away from 12.2.1.3.0 in 2020, one year after 12.2.1.4.0 was released.
Upgrading to 12.2.1.4.0 is not so hard and you can even do it with zero down time. You can also use the same domain files. Also keep in mind that 12.2.1.4.0 will be out of support in September this year, so I encourage you to upgrade to 12.2.1.19.0 and receive the full support you deserve for the same money you are paying for an obsolete version.
