Forms 11g – Java client hangs at security warning with “The application’s digital signature cannot be verified”

Having modified our formsweb.cfg file recently to configure WebUtil in our Forms 11g installation, we started hitting issues when trying to access various form-based application URLs.

When the security warning window appears (below), usually you would tick the check-box and run the application:

In this instance however, the window turned completely unresponsive and just hung, resulting in the Java process having to be killed via Window Task Manager.

One of the MOS notes with almost identical symptoms reveals this:

A workaround that sometimes helps is to change the order of the jar files listed in the archive parameter in the formsweb.cfg file. When using webutil then a suggestion would be to list jacob.jar before frmwebutil.jar in the webutilArchive parameter of formsweb.cfg.

So I tried re-arranging the sequence of JAR files for webutilArchive…

cd $DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2/config

Edit the form config file and then look for WebUtilArchive references:

vi formsweb.cfg

…and then change the order of the JAR files, so that jacob.jar is first:


No restart was required, and this resolved the issue immediately 🙂

NOTE: If your problem looks to stem from the archive parameter, trying changing the order of the JAR files in a similar way:


…if the problem persists, then you may need to look at applying one of the patches mentioned in the second MOS note below.

Form Hangs When Acknowledging Security Warning – The application’s digital signature cannot be verified [ID 1328039.1]
Windows Java Client Hangs On Accepting Not Verified Signature Of jar Files When SeparateFrame=True [ID 1173365.1]


One thought on “Forms 11g – Java client hangs at security warning with “The application’s digital signature cannot be verified”

  1. The main problem is a race condition in the JRE between the security warnings and the start of the main entry procedure, which is contained in frmall.jar. So the determinig JAR-file is not Jacob.jar, but frmall.jar.
    This race condition can be avoided by placing frmall.jar last in the archive / WebUtilArchive path (which determines the order in which the JAR-files are loaded). To be absolutely safe, use only one of Archive or WebUtilArchive.

Leave a comment

Your email address will not be published. Required fields are marked *