java.lang.SecurityException: cannot verify signature block file META-INF/CUST

Anand called me at 1:30 AM tonight. After applying Jan 2009 CPU, they were getting weird errors. Java console gave these errors:

Oracle JInitiator: Version 1.3.1.29
Using JRE version 1.3.1.29-internal Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings

Proxy Configuration: Browser Proxy Configuration

JAR cache enabled
Location: C:\Documents and Settings\Oracle Jar Cache
Maximum size: 50 MB
Compression level: 0
----------------------------------------------------
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
l: dump classloader list
m: print memory usage
q: hide console
s: dump system properties
t: dump thread list
x: clear classloader cache
0-5: set trace level to
----------------------------------------------------

Downloading http://apps11i.justanexample.com/OA_JAVA/oracle/apps/fnd/jar/fndforms.jar to JAR cache

java.lang.SecurityException: cannot verify signature block file META-INF/CUST
at sun.security.util.SignatureFileVerifier.process(Unknown Source)
at java.util.jar.JarVerifier.processEntry(Unknown Source)
at java.util.jar.JarVerifier.update(Unknown Source)
at java.util.jar.JarFile.initializeVerifier(Unknown Source)
at java.util.jar.JarFile.getInputStream(Unknown Source)
at oracle.jre.protocol.jar.JarCache$CachedJarLoader.authenticate(Unknown Source)
at oracle.jre.protocol.jar.JarCache$CachedJarLoader.access$4100(Unknown Source)
at oracle.jre.protocol.jar.JarCache$10.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.jre.protocol.jar.JarCache.privileged(Unknown Source)
at oracle.jre.protocol.jar.JarCache.access$2800(Unknown Source)
at oracle.jre.protocol.jar.JarCache$CachedJarLoader.download(Unknown Source)
at oracle.jre.protocol.jar.JarCache$CachedJarLoader.load(Unknown Source)
at oracle.jre.protocol.jar.JarCache.get(Unknown Source)
at oracle.jre.protocol.jar.CachedJarURLConnection.connect(Unknown Source)
at oracle.jre.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
at sun.misc.URLClassPath$JarLoader.getJarFile(Unknown Source)
at sun.misc.URLClassPath$JarLoader.(Unknown Source)
at sun.misc.URLClassPath$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.URLClassPath.getLoader(Unknown Source)
at sun.misc.URLClassPath.getLoader(Unknown Source)
at sun.misc.URLClassPath.getResource(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadCode(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)


This error appeared in apache log:

[Fri Mar 27 01:53:10 2009] [error] [client 192.168.4.70] client denied by server configuration: $OA_JAVA/oracle/apps/fnd/util/ParameterList.class

Most probably the certificate was corrupt.

So I created a new certificate by giving the command:

adjkey -initialize

After that we ran adadmin and force regenerated all jar files.

Problem was resolved after this.

Here's something I found by googling:

The Signed JAR File

When jarsigner is used to sign a JAR file, the output signed JAR file is exactly the same as the input JAR file, except that it has two additional files placed in the META-INF directory:
a signature file, with a .SF extension, and
a signature block file, with a .DSA extension.

The base file names for these two files come from the value of the -sigFile option. For example, if the option appears as
-sigFile MKSIGN
the files are named "MKSIGN.SF" and "MKSIGN.DSA".

If no -sigfile option appears on the command line, the base file name for the .SF and .DSA files will be the first 8 characters of the alias name specified on the command line, all converted to upper case. If the alias name has fewer than 8 characters, the full alias name is used. If the alias name contains any characters that are not legal in a signature file name, each such character is converted to an underscore ("_") character in forming the file name.

The Signature (.SF) File
A signature file (the .SF file) looks similar to the manifest file that is always included in a JAR file when jarsigner is used to sign the file. That is, for each source file included in the JAR file, the .SF file has three lines, just as in the manifest file, listing the following:
the file name,
the name of the digest algorithm used (SHA), and
a SHA digest value.
In the manifest file, the SHA digest value for each source file is the digest (hash) of the binary data in the source file. In the .SF file, on the other hand, the digest value for a given source file is the hash of the three lines in the manifest file for the source file.
The signature file also, by default, includes a header containing a hash of the whole manifest file. The presence of the header enables verification optimization, as described in

JAR File Verification.
The Signature Block (.DSA) File
The .SF file is signed and the signature is placed in the .DSA file. The .DSA file also contains, encoded inside it, the certificate or certificate chain from the keystore which authenticates the public key corresponding to the private key used for signing.

JAR File Verification
A successful JAR file verification occurs if the signature(s) are valid, and none of the files that were in the JAR file when the signatures were generated have been changed since then. JAR file verification involves the following steps:
Verify the signature of the .SF file itself.
That is, the verification ensures that the signature stored in each signature block (.DSA) file was in fact generated using the private key corresponding to the public key whose certificate (or certificate chain) also appears in the .DSA file. It also ensures that the signature is a valid signature of the corresponding signature (.SF) file, and thus the .SF file has not been tampered with.
Verify the digest listed in each entry in the .SF file with each corresponding section in the manifest.

The .SF file by default includes a header containing a hash of the entire manifest file. When the header is present, then the verification can check to see whether or not the hash in the header indeed matches the hash of the manifest file. If that is the case, verification proceeds to the next step.
If that is not the case, a less optimized verification is required to ensure that the hash in each source file information section in the .SF file equals the hash of its corresponding section in the manifest file (seeThe Signature (.SF) File).
One reason the hash of the manifest file that is stored in the .SF file header may not equal the hash of the current manifest file would be because one or more files were added to the JAR file (using the jar tool) after the signature (and thus the .SF file) was generated. When the jar tool is used to add files, the manifest file is changed (sections are added to it for the new files), but the .SF file is not. A verification is still considered successful if none of the files that were in the JAR file when the signature was generated have been changed since then, which is the case if the hashes in the non-header sections of the .SF file equal the hashes of the corresponding sections in the manifest file.
Read each file in the JAR file that has an entry in the .SF file. While reading, compute the file's digest, and then compare the result with the digest for this file in the manifest section. The digests should be the same, or verification fails.
If any serious verification failures occur during the verification process, the process is stopped and a security exception is thrown. It is caught and displayed by jarsigner.

So its possible that we had an issue with the certificate which caused this problem.