3/20/25, 12:36 PM Document 1591073.

1
Copyright (c) 2025, Oracle. All rights reserved. Oracle Confidential.

Signing JAR Files for Oracle E-Business Suite Release 12 (Doc ID 1591073.1)

This document describes how to sign Oracle E-Business Suite (EBS) desktop client Java Archive (JAR) files, using code
signing certificates from either a Commercial CA or a Private CA.

Note: As of August 2024, this document has been completely rewritten to describe the configurable options that are
now available for JAR signing. For the previous content, refer to My Oracle Support Knowledge Document 3015098.1.

The instructions provided are supported for use with Oracle E-Business Suite Release 12.

This Document 1591073.1 is updated as required. All updates are noted in the change log.

Note: To receive automatic notifications of updates, subscribe to the Hot Topics Notification feature in My Oracle
Support, as described in Document 793436.2, Subscribing to Hot Topic E-Mails.

In This Document

Section 1: Introduction
Section 2: Required Java Versions
Section 3: Required EBS Patches
Section 4: New Features
Section 5: Signing the Desktop JARs
5.1 Using a Private CA for Code Signing
5.1.1. Create Your Code Signing Keystore
5.1.2. Register Your Code Signing Keystore with AD
5.1.3. Configure JRE Client Trust
5.2 Using a Commercial CA for Code Signing
5.2.1 AD_SIGN_MODE is CUSTOM
5.2.2 AD_SIGN_MODE is NONE
Section 6: Setting up a Custom Signing Process to Use with an HSM
Section 7: Setting up a Custom Signing Process to be Called from AD Tools
7.1 Testing Your Own Signing Script
Section 8: References
Appendix A: Creating a Minimally Viable Private CA for JAR Signing
A1. Create a Private CA Using keytool
A1.1. One-Time CA Initialization
A1.2. CA Operations
A2. Create a Private CA Using openssl
A2.1. One-Time CA Initialization
A2.2. CA Operations
A3. Create a Private CA Using OCI Certificates service
Appendix B: Desktop JRE Configuration
B1. Making the Desktop JRE Trust Your Private CA - User Level
B2. Allowlisting EBS JARs via Exception Site List - User Level
B3. Allowlisting EBS JARs via Deployment Rule Set - System Level
B4. Example Desktop JRE Configuration
Appendix C: Using the adjss Utility for Configurable JAR Signing
Appendix D: Identifying JARs That Need Signing

Section 1: Introduction
The Java code that runs on the desktop (EBS client tier) is downloaded from EBS as JAR files (often just called JARs).
These files need to be signed by a certificate from a Certificate Authority (CA) that is trusted by the Java code on the
desktop.

The granular patching approach used by EBS means that the JARs used on the desktop may change when EBS is patched.
This requires the changed or updated JARs to be signed on your EBS application tier after patching, and prior to the
updated environment being released to users.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 1/29
3/20/25, 12:36 PM Document 1591073.1

Section 2: Required Java Versions

Oracle E-Business Suite utilizes the following Java components:

The Java Runtime Environment (JRE) is the Java component that runs on the EBS desktop tier.
JRE 8 is recommended and required for Java Web Start (See Document 2188898.1, Using Java Web Start
with Oracle E-Business Suite.)
The Java Development Kit (JDK) is the Java component that runs on the EBS application tier.
JDK 7 is recommended for the application tier.

Java 7 and Java 8 updates are released on the quarterly Critical Patch Update (CPU) schedule, and the most recent update
of each is supported for use with EBS. To be able to use the JAR signing configuration described in this document, you
must at a minimum install JRE 1.8.0_411 (April 2024) on all desktops, and JDK 1.7.0_421 (April 2024) on your application
tier. For more information, refer to My Oracle Support Knowledge Document 3007752.1, Oracle E-Business Suite Release
12.2 Critical Patch Update Availability Document (April 2024).

Oracle recommends that you apply the latest JRE and JDK updates at the earliest opportunity. To find the latest updates,
refer to My Oracle Support Knowledge Document 2484000.1, Identifying the Latest Critical Patch Update for Oracle E-
Business Suite Release 12 and identify the latest quarterly CPU knowledge document. In that document, navigate to "Table
3: Security Patches for Technology Stack Components With a New Patch in This CPU" to see the latest JRE and JDK
updates available.

Section 3: Required EBS Patches

To be able to start using the JAR signing strategy described in this document, you must first apply the appropriate
prerequisite patches:

EBS Release Patches to Apply

12.2
General prerequisite patches:

R12.AD.C.Delta.15 (Patch 34695811) or later

R12.TXK.C.Delta.15 (Patch 34785677) or later

Required patch for configurable JAR signing:

Patch 36492441:R12.AD.C - CONFIGURABLE JAR SIGNING FOR ORACLE E-BUSINESS SUITE

Note: You must apply this patch and complete the patching cycle before applying the rest of the
patches listed below.

Additional required patches for configurable JAR signing:

Patch 36407980:12.2.0 CONSOLIDATED PATCH FOR ORACLE E-BUSINESS SUITE JARS

If you are a customer who has implemented any of the Add-on Localizations products
on top of EBS, you must also apply Patch 36505923:R12.CLJ.G as well as Patch
36407980.
Patch 36505379 REMOVE ASGMTRAN.JAR FROM ADLDJAVA.DRV
Patch 36555711 REMOVE BOMJAR.JAR FROM FORMS_*_1012_CFG.TMP"
Patch 36499096 TAGGING SERVER JAR FILE IN ADXJAR.DEP

12.1
General prerequisite patches:

R12.AD.B.delta.9 (Patch 26247424)

R12.ATG_PF.B.delta.3 (Patch 8919491)

Required patch for configurable JAR signing:

Patch 36492441:R12.AD.B - CONFIGURABLE JAR SIGNING FOR ORACLE E-BUSINESS SUITE

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 2/29
3/20/25, 12:36 PM Document 1591073.1

Section 4: New Features

Installation of the above patches introduces the following significant changes:

The adjkey utility is replaced with the new adjss utility.

For EBS Release 12.2, the number of JAR files that are signed is reduced from over 300 files to 87.
If a customall.jar exists, it will be written to a separate customjarlist.txt rather than replacing jarlist.txt.
Java's keytool command is used to create the keystore with the code signing certificate when using a private CA.

With the new adjss utility, the signing mode can be set to one of the following three values:

KEYSTORE - Sign using local disk based keystore file, use the keytool command to create the keystore file.
NONE - AD will not sign JARs. AD will produce jarlist.txt and optionally customjarlist.txt.
CUSTOM - Same as NONE, but AD will call a new customjarsign.sh script that has your own signing
implementation.

The KEYSTORE mode can only be used with a private certificate authority. If you are using a new commercial certificate
authority, either NONE or CUSTOM mode must be specified. If you are currently using a Hardware Security Module (HSM)
for signing, you can run adjss to set the signing mode to NONE. See Section 5 for details.

Section 5: Signing the Desktop JARs

EBS has traditionally signed desktop JARs with a private key for which a code signing certificate has been acquired. The
private key, plus the signed certificate and its chain, were stored in a Java Keystore file (JKS) on the application tier (where
patching takes place). With this method, you could choose to use a Code Signing Certificate either from a commercial CA
or from a in-house, private CA.

The benefit of using a certificate from Commercial CA is that the Java 8 JRE on the desktop by default will trust the
commercial CA's root certificate. If using a certificate from private CA, the root certificate of that private CA must be added
as a trusted certificate in the truststore of the desktop JRE.

Irrespective of the chosen CA, the signing of updated JARs was automatically done by the EBS patch tool and when using
adadmin to regenerate the JARs. The EBS server does not look at the code signing certificate. Only the desktop JRE will
validate the signature of the downloaded client JARs.

Starting in the summer of 2023, the commercial CAs changed their policy and ceased to issue code signing certificates
where your private key was kept in a disk file such as the Java KeyStore (JKS) file used by EBS JAR signing tools. In
essence, the private key used for code signing now needs to be kept in a Hardware Security Module. For details, refer to
applicable communications from the relevant commercial CAs.

As an Oracle E-Business Suite customer, your choices for JAR signing are now either (a) or (b) below:

a. Use a private CA issued code signing certificate and keep using existing AD tools.
b. Use a commercial CA issued code signing certificate, and implement a custom signing process that satisfies the
commercial CA's requirements.

Be aware that is not necessary for others outside your organization to trust your EBS JARs. These JARs only need to be
trusted by your internal users, and specifically the subset of internal users that need to run Oracle Forms.

Similarly, the JRE on Forms users' desktops probably only needs to run JARs from EBS. Allowing the JRE to run Java from
anywhere else does not improve security (and there may be licensing issues with doing so).

5.1 Using a Private CA for Code Signing

To use Private CA for Code Signing, you will need to set up a Private CA if you do not already have one. See Appendix A for
some basic examples.

5.1.1. Create Your Code Signing Keystore

You will create the AD code signing keystore by following these steps:

1. Generate keystore file with keypair and certificate distinguished name.

2. Generate a certificate signing request (CSR).
3. Submit the CSR to the CA for signing.
4. Receive signed certificate and chain certificate(s).
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 3/29
3/20/25, 12:36 PM Document 1591073.1
5. Import the received certificates into the keystore file.

The keystore will be created using Java's keytool command. The keytool documentation is available at
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html.

Decide on the location of your code signing keystore file, and set that as your current directory.

Traditionally, AD has stored the keystore file (adkeystore.dat) in a release-specific location as follows:

EBS Release Directory

12.2 $APPL_TOP_NE/ad/admin

12.1 $APPL_TOP/admin

However, you can chose any directory available to the AD tools when patching or running adadmin.

Note: We recommend that you copy the following commands to a file in the current directory and adjust the variables
for your organization, and run the commands from your own file. That way you will have documentation of what you
actually did which will be handy when you have to redo any of the steps, either for complete keystore replacement or
for certificate renewal.

First, source the application tier runtime environment.

Then set the following variables to define the keystore file:

KS=ebsjarsign.p12 # name of the keystore file

AL=ebsjarsign # name ("alias") of the keystore PrivateKeyEntry
ST=pkcs12 # keystore type (pksc12 avoids annoying keytool warnings)

export SP="secret123" # keystore password

export KP="${SP}" # key password
# The recommended PKCS12 (.p12) format does not allow or require a separate key password

 

Note: The variables above contain keystore passwords in environment variables. If you would rather be prompted to
type the passwords, do not set those variables, and omit the -storepass and -keypass arguments in the commands
below. For reference, a brief description is shown at the end of each command.

You now need to set variables describing the code signing certificate's distinguished name.

$O="Example" # your company name

CN="O Private JAR Signing J1" # your certificate name
C="US" # your ISO country code

Note: Do not include commas in the values, unless you are prepared to escape them when using keytool.

Then create the keystore with the private/public key pair, choosing 'pkcs12' to avoid warnings:

$ keytool -genkeypair -keystore "$KS" -alias "$AL" \

-storetype $ST -keyalg RSA -keysize 2048 \
-dname "CN=$CN, O=$O, C=$C" \
-storepass:env SP

Now export the CSR:

$ keytool -certreq -keystore "$KS" \

-alias "$AL" -file $AL.csr \
-storepass:env SP

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 4/29
3/20/25, 12:36 PM Document 1591073.1
Next, provide the CSR file to the private CA and wait to receive the code signing certificate and any required chain
certificates.

Once you have received the certificate(s) in PEM format, import them into the $KS keystore file.

The number of files and names of the received certificate files are determined by your private CA.

The example below assumes you received the following aptly named certificate files: privateCAroot.crt,
privateCAchain.crt, and ebsjarsign.crt.

First, add the root CA certificate as a trustedCertEntry in the keystore:

$ keytool -importcert -keystore "$KS" -alias privateca \

-file privateCAroot.crt -storepass:env SP

Combine the code signing certificate and its intermediate chain certificates (the identity) into a single file:

$ cat privateCAchain.crt ebsjarsign.crt > ebsjarsign.pems

Now add this file as the trusted identity for your PrivateKeyEntry:

$ keytool -importcert -keystore "$KS" -alias "$AL" \

-file ebsjarsign.pems -storepass:env SP

If you want to use the jarsigner command to verify a signed JAR, you can tell jarsigner -verify to use this keystore
during verification.

List the completed code signing keystore by running the following command:

$ keytool -list -keystore "$KS" -storepass:env SP

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

ebsjarsign, Feb 20, 2024, PrivateKeyEntry,

Certificate fingerprint (SHA-256): 1E:56:EF:DA:84:73:38:91:6F:D4:88:4E:31:...A5:82:29:B4
privateca, Feb 20, 2024, trustedCertEntry,
Certificate fingerprint (SHA-256): 8F:E2:EB:CC:23:78:48:4F:62:87:08:75:C3:...E2:4B:1B:A9

Check the certificate chain for the PrivateKeyEntry:

$ keytool -list -keystore "$KS" -alias "$AL" \

-storepass:env SP -v | egrep 'Owner|Issuer:' | sed 's/^O/ O/'
Owner: CN=Example Private JAR Signing J1, O=Example, C=US
Issuer: CN=Example Private CA J1, O=Example, C=US
Owner: CN=Example Private CA J1, O=Example, C=US
Issuer: CN=Example Private CA J1, O=Example, C=US

With the code signing keystore holding the private key and the signed code signing certificate, it is ready to be used for
signing your EBS client JARs.

5.1.2. Register Your Code Signing Keystore with AD

For the signing to work, you must register the information about your keystore so the AD signing code can access it. You
do that by running the adjss utility:

$ echo $SP $KP # remind yourself of the chosen keystore password(s); adjss wants to know.

$ adjss -mode KEYSTORE -keystore "$PWD/$KS" -alias "$AL" -sigfile CUST

adjss will prompt for the storepass ($SP) and keypass ($KP) and store them in the database. To do that, it will also
prompt for the APPS password.

The server side of the JAR signing setup is now complete, with the default signing mode of KEYSTORE.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 5/29
3/20/25, 12:36 PM Document 1591073.1

Note: Once you have configured the signing mode to be KEYSTORE, one of the cloning steps will be different. Refer
to Step 1, Copy JAR signing files from source instance, in Section 4 of My Oracle Support Knowledge Document
1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone.

You can view and verify setup of the signing mode by using the -list and -verify options of adjss.

For example:

$ adjss -verify
SIGNING MODE : KEYSTORE
Enter APPS password:
keystore file : /home/oracle/tst/ebsjarsign.jks
keystore alias : ebsjarsign
keystore password : stored in database
keystore key password : stored in database
jarsigner sigfile : CUST

Before you use adadmin to force regeneration of EBS JARs and signing of client JARs, you must ensure that the client JREs
on the end-user desktops trust the CA that signed the client JARs.

Note:

If you have multiple EBS environments, you can reuse the same code signing keystore file across them all by
copying the keystore file in place and registering it using adjss.

If you have multiple EBS application tiers without a shared file system, you can copy the keystore files
(adsignmode.txt, adsignparameters.txt, and adkeystore.dat) to the same full path location on the new
node.

5.1.3. Configure JRE Client Trust

The privateCAroot.crt certificate received from the private CA must be trusted by the desktop JREs on each desktop
that must run Oracle Forms. This is required for the JRE to successfully verify the JAR signature.

Adding the trust of the private root CA can be done in one of the following ways:

Each Oracle Forms user downloads the rootCA certificate and installs it using the Java Control Panel.
A centrally prepared trust file file can be downloaded to each desktop.
Centralized desktop device management software can be used to push the root certificate - and JRE updates as
well.

If you want to have individual users interactively trust the private CA, you can provide a page with instructions on the EBS
web server.

$ mkdir $INST_TOP/portal/jre8/
$ cp privateCAroot.crt $INST_TOP/portal/jre8/rootca.crt
$ cp html-page-with-instructions.html $INST_TOP/portal/jre8/

An example of the instructions can be found in Appendix B, Section B4, "Example Desktop JRE Configuration". The
instructions there assume that a Deployment Rule Set (Appendix B, Section B3) is also deployed.

5.2 Using a Commercial CA for Code Signing

If you choose to use a commercial CA for the code signing certificate, you must:

1. Configure EBS AD JAR signing in mode NONE or CUSTOM.

2. Implement a code signing service using your chosen commercial CA's solution:
a. CUSTOM mode
b. NONE mode

5.2.1 AD_SIGN_MODE is CUSTOM

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 6/29
3/20/25, 12:36 PM Document 1591073.1
You will implement your custom signing in the customjarsign.sh script, and place it in $APPL_TOP_NE/ad/admin/.

AD will call the custom script in the places where it would normally have signed the JARs using the KEYSTORE mode.

EBS ships sample scripts called customjarsign.sh (for UNIX) and customjarsign.cmd (for Windows) that contain
example code you can use as the basis of your chosen signing solution. The script will be called from AD with the name of
a file, jarlist.txt, that contains JAR files identified by their full pathname. The script must sign each JAR file, and the
result must overwrite the unsigned JAR.

Note: Once you have configured the signing mode to be CUSTOM, one of the cloning steps will be different. Refer to
Step 1, Copy JAR signing files from source instance, in Section 4 of My Oracle Support Knowledge Document
1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone.

The patch places the shipped sample script in the following location:

EBS
Full UNIX Pathname Full Windows Pathname
Release

12.2 $APPL_TOP_NE/ad/admin/customjarsign.sh %APPL_TOP_NE%\ad\admin\customjarsign.cmd

12.1 $APPL_TOP/admin/customjarsign.sh %APPL_TOP%\admin\customjarsign.cmd

See 7. Setting up a Custom Signing Process to be Called from AD Tools.

Once you have developed and tested your customjarsign.sh script. set AD Jar signing into CUSTOM mode by calling
adjss:

$ adjss -mode CUSTOM

adjss will verify the existence of $APPL_TOP_NE/ad/admin/customjarsign.sh before setting CUSTOM mode.

5.2.2 AD_SIGN_MODE is NONE

Set AD Jar signing into NONE mode by calling adjss:

$ adjss -mode NONE

EBS tools will display a message to remind you to sign any updated JARs when the automatic JAR signing has been
disabled.

The AD tools will regenerate the JARs as part of patching, and will also generate a file jarlist.txt that lists the JARs in
need of signing. If you have added custom code that is being signed, AD tools will optionally generate
customjarlist.txt, listing the custom JAR named $OA_JAVA/customall.jar by default.

You will use the jarlist file(s) to identify the JARs that must be signed by your custom commercial CA solution.

You can use the following command to merge the jarlist.txt generated during multiple patching cycles:

$ cd $NE_BASE/EBSapps/log/adadmin/log/ $find . -name jarlist.txt | xargs cat

Your signing tool will have to sign each of the JARs indicated in jarlist.txt, and the signed JARs must overwrite the
unsigned JARs at the same location.

See 6. Setting up a Custom Signing Process to Use with an HSM.

The EBS Release 12.2 adop phase=finalize command will display warning messages if the JARs have not been signed,
but the cutover phase will still be allowed to run.

Note: If you do not sign the required JAR files, users will not be able to run Oracle Forms applications.

When adadmin generates jarlist.txt, and optionally customjarlist.txt, they are created in the following location:

EBS Release Full Pathname

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 7/29
3/20/25, 12:36 PM Document 1591073.1

12.2 $NE_BASE/EBSapps/log/adadmin/log/jarlist.txt

12.1 $APPL_TOP/admin/$TWO_TASK/log/jarlist.txt

When the patch tool generates jarlist.txt, it will be created in the log directory for that patching cycle:

EBS Release Full Pathname

12.2 $NE_BASE/EBSapps/log/adop/*/*/*/*/<patch#>/log/jarlist.txt

12.1 $APPL_TOP/admin/$TWO_TASK/log/jarlist.txt

You can use the following commands to merge the jarlist.txt generated during multiple patching cycles:

$ cd $NE_BASE/EBSapps/log/adop/*/*/*/*/
$ find . -name jarlist.txt | xargs cat | sort -u

For more information about your Java customizations and and customjarlist.txt, refer to My Oracle Support Knowledge
Document 1577661.1, Developing and Deploying Customizations in Oracle E-Business Suite Release 12.2.

Section 6: Setting up a Custom Signing Process to Use with an HSM

Using a Commercial CA code signing certificate requires you, the EBS customer, to provide a signing process. The private
key must reside in a Hardware Security Module (HSM).

The commercial CA may accept some forms of existing HSM devices in your possession, or will sell you an HSM that could
be a USB-stick like device. You will need to check the offerings from your chosen commercial CA.

If acquiring a HSM you will most likely be implementing a single, central signing service on a host that can reach the HSM-
based private key. Once the HSM and supporting software has been installed, you will have to decide how the EBS client
JARs will be sent to the signing server and then back to EBS. A directory holding the JARs could be made accessible to the
signing server (NFS mount), or the signing server could have a REST service that accepts a unsigned JAR and returns a
signed JAR.

Some commercial CAs also offer a cloud-based signing service, where the JARs never leave the EBS application tier. A
cloud-enhanced JAR signer runs on the application tier, and the META-INF file with the hashes of the included files is sent
to the cloud service for signing by an acceptably stored key. The application tier local JAR signer program then puts the
signed META-INF file in the JAR. The cloud service keeps a record of who signed what and when.

Section 7: Setting up a Custom Signing Process to be Called from AD Tools

When the signing mode is set to CUSTOM, AD patch tools and the adadmin tool's Regenerate JAR Files option will generate
a jarlist.txt file with the pathnames of all the JARs that need signing, and then call your customjarsign.sh script
with the jarlist.txt file as a parameter.

EBS ships a sample script called customjarsign.sh.sample. You will need to create your own customjarsign.sh script,
which you can base on this script. An example is shown below.

Notes on the example:

The script ships with a signjar_custom function that does nothing except print the name of the JAR it should sign.
There is a sample signjar_keystore function that builds on the old-style adkeystore.dat + adsign.txt files and
adds a timestamp.
There is a signjar_pkcs11 function that resembles what it might take to sign with a DigiCert commercial code
signing certificate. This has not been tested, but is based on publicly available information at https://digicert.com.

customjarsign.sh.sample

#! /bin/bash
# Code signing script to sign client jars using custom process.
# This script will be called from AD patch tools and from adadmin when AD_SIGN_MODE is CUSTOM.
# This script will be called by AD with the full pathname of the jarlist.txt file.
# The jarlist.txt file contains full pathnames of JARs that must be signed, one per line.
# this script must exit 0 upon success and something else in case of error.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 8/29
3/20/25, 12:36 PM Document 1591073.1
# This script should do its own logging (transcript error and debug).
# This sample script simply writes to stdout and stderr.

# print usage and exit

#-------------------------------------------------------------------------------
usage ()
{
echo > &2 "usage: $pgm /path/to/jarlist.txt"
exit 1
}

# print error message and exit

#-------------------------------------------------------------------------------
errexit ()
{
echo > &2 "ERROR: $1"
exit 1
}

# validate the jarlist.txt file

#-------------------------------------------------------------------------------
validatejarlist () # $1 name of file listing JARs
{
jarlist="$1"
if [ ! -f "$jarlist" ] ;then
errexit "jarlist file '$jarlist' does not exist"
fi

if [ ! -r "$jarlist" ] ;then
errexit "Cannot read jarlist file '$jarlist'"
fi

jars=$( grep '^/.*\.jar' "$jarlist" )

njars=$( echo "$jars" | wc -l )

if [ "$njars" -eq 0 ] ;then
errexit "No JARs in jarlist file '$jarlist'"
fi

for jar in $jars ;do

if [ ! -f "$jar" ] ;then
errexit "JAR '$jar' does not exist"
fi
if [ ! -r "$jar" ] ;then
errexit "Cannot read JAR '$jar'"
fi
if [ ! -w "$jar" ] ;then
errexit "Cannot write JAR '$jar'"
fi
done

echo "INFO: Validated read/write-ability of $njars JAR files from '$jarlist'"

}

# This test function relies on an already configured native JAR signing setup.
# Adjust keystore passwords if not default.

# Sign one JAR using KEYSTORE file

#-------------------------------------------------------------------------------
signjar_keystore () # $1 name of 1 JAR file
{
if [ -d "$APPL_TOP_NE" ] ;then # EBS R12.2
JRIDIR="$APPL_TOP_NE/ad/admin"
else
JRIDIR="$APPL_TOP/admin"
fi
AD_KEYSTORE="$JRIDIR/adkeystore.dat"
AD_KEYSTORE_ALIAS=$( awk '{print $1}' "$JRIDIR/adsign.txt" )
AD_SIGFILE=$( awk '{print $3}' "$JRIDIR/adsign.txt" )

export AD_KEYSTORE_SPASS="puneet"
export AD_KEYSTORE_KPASS="myxuan"

ztsaurl="http://timestamp.digicert.com"
zproxyhost="www-proxy"
zproxyport=80
timestamp="-tsa ${ztsaurl} -J-Dhttp.proxyHost=${zproxyhost} -J-Dhttp.proxyPort=${zproxyport}"

echo "INFO: KEYSTORE Signing JAR '$1' ..."

jarsigner -keystore "${AD_KEYSTORE}" -storepass:env AD_KEYSTORE_SPASS -keypass:env AD_KEYSTORE_KPASS \

$timestamp -sigfile "${AD_SIGFILE}" "$1" "${AD_KEYSTORE_ALIAS}"

return $?
}

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 9/29
3/20/25, 12:36 PM Document 1591073.1
# This test function assumes Digicert PKCS11 signing cloud service
# You will have to install the code and set parameters provided by Digicert
# Other commercial CAs have similar PKCS11 solutions

# Sign one JAR using PKCS11 provider for Java jarsigner

#-------------------------------------------------------------------------------
signjar_pkcs11 () # $1 name of 1 JAR file
{
AD_PKCS11_providerArg="pkcs11properties.cfg" # config file to load DLL or SO //
AD_PKCS11_ALIAS="032452-9823742-987234" # from HSM or CloudKey //
AD_PKCS11_TIMESTAMP="http://timestamp.digicert.com" # URL to your commercial CA's timestamp service
AD_SIGFILE="CUST"
# JARSIGNER="/opt/java8/bin/jarsigner" # If the CA solution require a different java version
JARSIGNER="jarsigner"

zproxyhost="www-proxy"
zproxyport=80
timestamp="-tsa $AD_PKCS11_TIMESTAMP -J-Dhttp.proxyHost=${zproxyhost} -J-Dhttp.proxyPort=${zproxyport}"

# set variables required by the the DLL or SO that implements the PKCS11 provider
export SM_HOST=https://clientauth.one.digicert.com
export SM_API_KEY=""
export SM_CLIENT_CERT_FILE=idkeystore.p12
export SM_CLIENT_CERT_PASSWORD=""

echo "INFO: PKCS11 Signing JAR '$1' ..."

$JARSIGNER -keystore NONE -storetype PKCS11 -storepass NONE \

-providerClass sun.security.pkcs11.SunPKCS11 -providerArg "${AD_PKCS11_providerArg}" \
$timestamp -sigfile "${AD_SIGFILE}" "$1" "${AD_PKCS11_ALIAS}"

return $?
}

# Sign one one JAR file using YOUR custom scripting

#-------------------------------------------------------------------------------
signjar_custom () # $1 name of 1 JAR file
{
echo "INFO: DUMMY Signing JAR '$1' ..."
return 0
}

# Sign one JAR file - pick the sample function to try/test

#-------------------------------------------------------------------------------
signjar () # $1 name of 1 JAR file
{
# Switch between signing options
# signjar_keystore "$1" # this option simply piggybacks on an existing KEYSTORE setup, for testing of C
# signjar_pkcs11 "$1" # if a Cloudy HSM is installed and the PKCS#11 provider has been configured
signjar_custom "$1" # anything you want...
}

# Sign all JARs in the jarlist.txt file - one by one

#-------------------------------------------------------------------------------
signjars () # $1 name of file listing JARs
{
jars=$( cat "$1" | grep '^/.*\.jar' )
for jar in $jars ;do
if ! signjar "$jar" ; then
errexit "Error signing JAR '$jar'"
fi
done
}

# MAIN processing
#-------------------------------------------------------------------------------

pgm=$(basename "$0")
pgm=$0

case $# in
1 ) : ;; # one and only parameter is the pathname of jarlist.txt
* ) usage ;;
esac

validatejarlist "$1" # validate input file, exits in case of error

signjars "$1" # sign all JARs in input file, exits in case of error

exit $?

# END of customjarsign.sh

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 10/29
3/20/25, 12:36 PM Document 1591073.1
Testing Your Own Signing Script

Once you have used this sample as the basis for your own customjarsign.sh script, you can test your efforts as follows.

1. Create a simple test JAR:

$ mkdir jars && cd jars

$ echo sample > sample.txt
$ jar cvf test.jar sample.txt

2. View the JAR content:

$ jar tvf test.jar

0 Wed Mar 06 14:30:20 EST 2024 META-INF/
69 Wed Mar 06 14:30:20 EST 2024 META-INF/MANIFEST.MF
7 Wed Mar 06 14:30:12 EST 2024 sample.txt

3. Prepare jarlist.txt:

$ echo $PWD/test.jar > jarlist.txt

$ cd ..

4. Run your customjarsign.sh script. Here, it is an unmodified copy of the customjarsign.sh.sample that uses the
DUMMY signjar_custom function:

$ ./customjarsign.sh $PWD/jars/jarlist.txt
INFO: Validated read/write-ability of 1 JAR files from
'/u01/install/APPS/fs_ne/EBSapps/appl/ad/admin/jars/jarlist.txt'
INFO: DUMMY Signing JAR '/u01/install/APPS/fs_ne/EBSapps/appl/ad/admin/jars/test.jar' ...

Be aware that if you change the signjar function in the script to call the sample signjar_keystore function
(which depends on an existing, pre-patch jar signing setup) and then run the script again, you will see the following
output as jarsigner is called:

$ ./customjarsign.sh $PWD/jars/jarlist.txt
INFO: Validated read/write-ability of 1 JAR files from
'/u01/install/APPS/fs_ne/EBSapps/appl/ad/admin/jars/jarlist.txt'
INFO: KEYSTORE Signing JAR '/u01/install/APPS/fs_ne/EBSapps/appl/ad/admin/jars/test.jar' ... jar
signed.

The signer certificate will expire on 2025-12-27.

The timestamp will expire on 2031-11-09.

In this second case, jarsigner was called both to sign the JAR and add a timestamp.

5. To verify that the JAR has been signed:

$ jar tvf jars/test.jar

151 Wed Mar 06 14:41:14 EST 2024 META-INF/MANIFEST.MF
313 Wed Mar 06 14:41:14 EST 2024 META-INF/CUST.SF
11752 Wed Mar 06 14:41:14 EST 2024 META-INF/CUST.RSA
0 Wed Mar 06 14:30:20 EST 2024 META-INF/
7 Wed Mar 06 14:30:12 EST 2024 sample.txt

You will see that two new files were added:

META-INF/CUST.SF
META-INF/CUST.RSA

To verify that the signing information is valid, use the jarsigner -verify command in either simple or verbose
mode.

Simple verification:

$ jarsigner -verify jars/test.jar

jar verified.

Verbose verification:

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 11/29
3/20/25, 12:36 PM Document 1591073.1

$ jarsigner -verify -verbose jars/test.jar

s k 151 Wed Mar 06 14:41:14 EST 2024 META-INF/MANIFEST.MF

313 Wed Mar 06 14:41:14 EST 2024 META-INF/CUST.SF
11752 Wed Mar 06 14:41:14 EST 2024 META-INF/CUST.RSA
0 Wed Mar 06 14:30:20 EST 2024 META-INF/
smk 7 Wed Mar 06 14:30:12 EST 2024 sample.txt

s = signature was verified

m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

- Signed by "CN=EBS Customer, OU=JAR Sign, O=EBS Customer, L=Redwood Shores, ST=California, C=US"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
Timestamped by "CN=DigiCert Timestamp 2023, O="DigiCert, Inc.", C=US" on Wed Mar 06 19:43:13 UTC 2024
Timestamp digest algorithm: SHA256
Timestamp signature algorithm: SHA256withRSA, 4096-bit key

jar verified.

The signer certificate will expire on 2025-12-27.

The timestamp will expire on 2031-11-09

Verbose verification, plus full certificate and chain information:

$ jarsigner -verify -verbose -certs -keystore adkeystore.dat jars/test.jar

s k 151 Wed Mar 06 14:41:14 EST 2024 META-INF/MANIFEST.MF

>>> Signer
X.509, CN=EBS Customer, OU=JAR Sign, O=EBS Customer, L=Redwood Shores, ST=California, C=US (ebsjars
[
Signature algorithm: SHA256withRSA, 2048-bit key
[certificate is valid from 10/27/23 2:29 AM to 12/27/25 5:00 AM]
X.509, CN=Example EBS JAR Private CA Root R1, O=ATG, C=US (privateca)
[
Signature algorithm: SHA256withRSA, 4096-bit key
[trusted certificate]
>>> TSA
X.509, CN=DigiCert Timestamp 2023, O="DigiCert, Inc.", C=US
[
Signature algorithm: SHA256withRSA, 4096-bit key
[certificate is valid from 7/13/23 8:00 PM to 10/13/34 7:59 PM]
X.509, CN=DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA, O="DigiCert, Inc.", C=US
[
Signature algorithm: SHA256withRSA, 4096-bit key
[certificate is valid from 3/22/22 8:00 PM to 3/22/37 7:59 PM]
X.509, CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
[
Signature algorithm: SHA384withRSA, 4096-bit key
[certificate is valid from 7/31/22 8:00 PM to 11/9/31 6:59 PM]

313 Wed Mar 06 14:41:14 EST 2024 META-INF/CUST.SF

11752 Wed Mar 06 14:41:14 EST 2024 META-INF/CUST.RSA
0 Wed Mar 06 14:30:20 EST 2024 META-INF/
smk 7 Wed Mar 06 14:30:12 EST 2024 sample.txt

[entry was signed on 3/6/24 2:43 PM]

>>> Signer
X.509, CN=EBS Customer, OU=JAR Sign, O=EBS Customer, L=Redwood Shores, ST=California, C=US (ebsjars
[
Signature algorithm: SHA256withRSA, 2048-bit key
[certificate is valid from 10/27/23 2:29 AM to 12/27/25 5:00 AM]
X.509, CN=Example EBS JAR Private Root CA R1, O=ATG, C=US (privateca)
[
Signature algorithm: SHA256withRSA, 4096-bit key
[trusted certificate]
>>> TSA
X.509, CN=DigiCert Timestamp 2023, O="DigiCert, Inc.", C=US
[
Signature algorithm: SHA256withRSA, 4096-bit key
[certificate is valid from 7/13/23 8:00 PM to 10/13/34 7:59 PM]
X.509, CN=DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA, O="DigiCert, Inc.", C=US
[
Signature algorithm: SHA256withRSA, 4096-bit key
[certificate is valid from 3/22/22 8:00 PM to 3/22/37 7:59 PM]
X.509, CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
[
Signature algorithm: SHA384withRSA, 4096-bit key
[certificate is valid from 7/31/22 8:00 PM to 11/9/31 6:59 PM]

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 12/29
3/20/25, 12:36 PM Document 1591073.1

s = signature was verified

m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope

- Signed by "CN=EBS Customer, OU=JAR Sign, O=EBS Customer, L=Redwood Shores, ST=California, C=US"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
Timestamped by "CN=DigiCert Timestamp 2023, O="DigiCert, Inc.", C=US" on Wed Mar 06 19:43:13 UTC 2024
Timestamp digest algorithm: SHA256
Timestamp signature algorithm: SHA256withRSA, 4096-bit key

jar verified.

The signer certificate will expire on 2025-12-27.

The timestamp will expire on 2031-11-09.

References
The following resources support the contents of this document and should be consulted as appropriate.

My Oracle Support Knowledge Documents

Document 2510500.1, FAQ: Essentials of Java Usage in Oracle E-Business Suite

Document 2188898.1, Using Java Web Start with Oracle E-Business Suite
Document 389422.1, Recommended Browsers for Oracle E-Business Suite Release 12
Document 1577661.1, Developing and Deploying Customizations in Oracle E-Business Suite Release 12.2

Oracle E-Business Suite Documentation Web Library Book

Oracle E-Business Suite Maintenance Guide

Appendix A: Creating a Minimally Viable Private CA for JAR Signing

A minimally viable private CA requires a root CA key/certificate and zero or more intermediate (subordinate) CA
keys/certificates.

If the JRE on the desktops is configured to check for certificate revocation (CRL or OCSP) you must also provide these as
always running services (CRL http download, or OCSP service) or the verification will fail. If your private CA does not
provide revocation service you can turn off revocation check for code signing certificates.

You can implement a private CA in many ways, there are open source and commercial solutions available for on-premises
installation or cloud services for certificate management.

Sections A1 to A3 below provide examples of creating a private CA for issuing (also known as signing) code signing
certificates for EBS client JAR files in three different scenarios:

1. Create a Private CA Using keytool - no revocation service

2. Create a Private CA Using openssl - optional revocation service
3. Create a Private CA Using OCI Certificates service - optional revocation service

These examples can be used as the basis for your efforts for deployment on development, test, or even production
systems. The private JAR CA may only have to issue (sign) one single certificate in its lifetime: your organization's EBS JAR
Signing certificate.

A1. Create a Private CA Using keytool

 to set up a minimal Private CA for JAR signing using only the Java keytool command.
It is possible 

This private CA will not support certificate revocation and will not generate a certificate revocation list (CRL). The CA will
consist of a root CA certificate, and will sign the code signing certificate signing requests (CSR) using the proper keyUsage
(KU) and extendedKeyUsage (EKU) extensions.

The keytool documentation is at https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 13/29
3/20/25, 12:36 PM Document 1591073.1
To make the commands shorter and avoid excessive typing, a few shell variables are used. Adjust for your organization
before running the keytool commands.

We recommend that you copy the following commands to a file in the current directory, adjust the variables for your
organization, and run the commands from your own file. That way you will have documentation of what you did, which will
be useful if you have to create a new private CA.

This example uses keytool from Java 7 on the EBS application tier. You can also run your keytool CA in a very small (1×1)
VM that is shut down after signing the code signing certificate.

A1.1. One-Time CA Initialization

Create CA Directory:

$ mkdir ~/ebsJarCA
$ cd ~/ebsJarCA

Set key variables, with values to suit your organization:

$O="Example" # your organization name

RCN="O Private CA J1" # name of your Private CA
C="US" # your ISO country code

RVAL=7305 # root valid for 20 years (20*365 + 5 leap days)

CVAL=1098 # cert valid for 3 years (3*365 + 3 leap days)

export RPASS="secret123" # password for rootca.jks

Generate self-signed root CA certificate

$ keytool -genkeypair -keystore rootca.p12 -alias rootca -ext bc:c:0 \

-validity $RVAL -keyalg RSA -keysize 4096 \
-dname "CN=$RCN, O=$O, C=$C" \
-storetype pkcs12 -storepass:env RPASS

Export rootCA Certificate

$ keytool -exportcert -keystore rootca.p12 -alias rootca -rfc -file rootca.crt \

-storepass:env RPASS

Now that the private CA has been created, clients must trust rootca.crt.

A1.2. CA Operations

There is only one CA operation for this simple CA, as it does not deal with revocation.

Sign a code signing Certificate Signing Request (CSR)

To sign a certificate signing request (CSR) for a JAR signing certificate, run the following command to sign the received
CSR (jarsign.csr) and generate the requested code signing certificate (jarsign.crt).

The signing command adds the required keyUsage (KU) and extendedKeyUsage (EKU) extensions to the signed code
signing certificate.

$ cat ebsjarsign.csr |
keytool -gencert -keystore rootca.p12 -alias rootca -rfc -outfile ebsjarsign.crt \
-validity $CVAL -ext ku:c=dig,keyEncipherment -ext eku:c=codeSigning \
-storepass:env RPASS

Return the signed certificate and the root CA certificate to the requestor.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 14/29
3/20/25, 12:36 PM Document 1591073.1
With the chosen validity period of three years (CVAL) for the code signing certificate, the (re-)signing must be repeated
every three years.

You could also set the CVAL=$RVAL and have the code signing certificate live as long as the CA, 20 years. However, if you
do that you risk that the JRE8 in a future version will reject long-lived code signing certificates.

A2. Create a Private CA Using openssl

Here is an example of using openssl 3.0 on Oracle Linux 9.

A2.1. One-Time CA Initialization

Create CA Directory

$ mkdir ~/ebsJarCA
$ cd ~/ebsJarCA

Create CA Directory Structure

$ mkdir certs db private

$ chmod 700 private
$ touch db/index
$ openssl rand -hex 16 > db/serial
$ echo 1001 > db/crlnumber

Create CA Configuration File

For your own organization's use you must chose values that reflect your domain name in the [default] section and your
organization information in the [ca_dn] section.

$ cat > ebsca.conf <<-'EOF'

[default]
name = ebsca
domain_suffix = example.com
aia_url = http://$name.$domain_suffix/$name.crt
crl_url = http://$name.$domain_suffix/$name.crl
default_ca = ca_default
name_opt = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
countryName = "US"
organizationName = "Example"
commonName = "Example EBS JAR Private Root CA R1"

[ca_default]
home = .
database = $home/db/index
serial = $home/db/serial
crlnumber = $home/db/crlnumber
certificate = $home/$name.crt
private_key = $home/private/$name.key
RANDFILE = $home/private/random
new_certs_dir = $home/certs
unique_subject = no
copy_extensions = none
default_days = 7305
default_crl_days = 7305
default_md = sha256
policy = policy_c_o_match

[policy_c_o_match]
countryName = supplied
stateOrProvinceName = optional
organizationName = supplied
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[req]
default_bits = 4096
encrypt_key = yes
default_md = sha256
utf8 = yes
string_mask = utf8only
prompt = no
distinguished_name = ca_dn

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 15/29
3/20/25, 12:36 PM Document 1591073.1
req_extensions = ca_ext

[ca_ext]
basicConstraints = critical,CA:true,pathlen:0
keyUsage = critical,keyCertSign,cRLSign
subjectKeyIdentifier = hash

[crl_info]
URI.0 = $crl_url

[issuer_info]
caIssuers;URI.0 = $aia_url
EOF

Generate Root CA Private Key and Self-Signed Root CA Certificate

Generate private key:

$ openssl req -new \

-config ebsca.conf \
-out ebsca.csr \
-keyout private/ebsca.key
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

You must keep the generated private/ebsca.key securely.

Self-sign the root CA certificate:

$ openssl ca -selfsign \
-config ebsca.conf \
-in ebsca.csr \
-out ebsca.crt \
-extensions ca_ext
Enter pass phrase for ./private/ebsca.key:

The generated ebsca.crt is the root CA certificate that the Oracle Forms clients must trust. The openssl ca command
keeps track of issued certificates in the text file db/index.

This example shows that so far this CA has only signed its own certificate:

$ cat db/index | tr '\t' ' '

V 340105050154Z 66F314E24AC4FDB09BD9912E7108EA8D unknown /C=US/O=Example/CN=Example EBS JAR Private Root CA
R2

Generate (empty) CRL

$ openssl ca -gencrl \
-config ebsca.conf \
-out ebsca.crl

The generated ebsca.crl is used by clients to check the revocation status of a certificate.

The CRL must be regenerated and redeployed if certificate revocation takes place.

Create Configuration File for Leaf Certificates (Code Signing)

$ cat ebsca.conf | sed 's/^copy_extensions.*$/copy_extensions = copy/' > leaf.conf

$ cat >> leaf.conf << EOF
[code_ext]
authorityInfoAccess = @issuer_info
authorityKeyIdentifier = keyid:always
basicConstraints = critical,CA:false
crlDistributionPoints = @crl_info
extendedKeyUsage = codeSigning
keyUsage = critical,digitalSignature

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 16/29
3/20/25, 12:36 PM Document 1591073.1
subjectKeyIdentifier = hash
EOF

If you are not going to make the CRL and the Root CA certificate available at http://ebsca.example.com/ebsca.{crl,crt} you
must comment out the following lines in leaf.conf before signing any code signing CSRs.

authorityInfoAccess = @issuer_info
crlDistributionPoints = @crl_info

If you do not, the clients will report an error when they cannot use the CRL specified in the certificate for revocation check.

If you want to support certificate revocation check via CRL for an Oracle Forms client, you must make the ebsca.crl and
ebsca.crt files from this directory available for download at :

http://ebsca.example.com/ebsca.crt
http://ebsca.example.com/ebsca.crl

A2.2. CA Operations

Available CA operations are:

1. Sign a code signing certificate signing request (CSR).

2. Revoke an issued certificate.
3. Regenerate the Certificate Revocation List (CRL) once a year, or whenever revocation takes place.

Sign a code signing Certificate Signing Request (CSR)

As the operator of the private CA, you will receive a Certificate Signing Request in the form of a *.csr file. Sign it to
produce a signed code signing certificate by running the following command:

$ openssl ca -config leaf.conf -extensions code_ext -in code.csr -out code.crt

The generated code.crt file must be provided to the requestor, along with the root CA certificate.

$ cat code.crt ebsca.crt > code.certs

The requestor can then import the code.certs file into the EBS code signing keystore file ebsjarsign.p12.

The openssl ca command keeps track of issued certificates in the text file db/index.

$ cat db/index | tr '\t' ' '

V 340105050154Z 66F314E24AC4FDB09BD9912E7108EA8D unknown /C=US/O=Example/CN=Example EBS JAR Private Root CA
R2
V 340105050336Z 66F314E24AC4FDB09BD9912E7108EA8E unknown /C=US/ST=California/O=EBS Customer/OU=JAR
Sign/CN=EBS Customer

The just-signed code signing certificate is the second line.

View the content of a signed Code Signing Certificate

If the CSR has a Subject of:

C = US, ST = California, O = EBS Customer, OU = JAR Sign, CN = EBS Customer

Then the signed certificate will contain the following information:

$ openssl x509 -noout -text -in code.crt

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
66:f3:14:e2:4a:c4:fd:b0:9b:d9:91:2e:71:08:ea:8e
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Example, CN = Example EBS JAR Private Root CA R1
Validity
Not Before: Jan 5 05:03:36 2024 GMT
Not After : Jan 5 05:03:36 2034 GMT
Subject: C = US, ST = California, O = EBS Customer, OU = JAR Sign, CN = EBS Customer

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 17/29
3/20/25, 12:36 PM Document 1591073.1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...(hex)...
3e:01
Exponent: 65537 (0x10001)
X509v3 extensions:
Authority Information Access:
CA Issuers - URI:http://ebsca.example.com/ebsca.crt
X509v3 Authority Key Identifier:
8F:68:1C:D8:91:13:32:21:DC:30:B7:61:C2:D6:89:05:2C:20:AB:F5
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 CRL Distribution Points:
Full Name:
URI:http://ebsca.example.com/ebsca.crl
X509v3 Extended Key Usage:
Code Signing
X509v3 Key Usage: critical
Digital Signature
X509v3 Subject Key Identifier:
C1:BA:56:F5:CD:A0:32:21:50:EA:9C:9E:67:41:88:01:AE:4E:74:2F
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
...(hex)...
f9:5a:48:08:25:9d:21:06

Revoke a Certificate

In the uncommon situation that you need to revoke a certificate (that is, invalidate a not yet expired leaf certificate), use a
command like the following:

$ openssl ca -config ebsca.conf \

-revoke certs/<serial>.pem \
-crl_reason keyCompromise

The value of -crl_reason can be one of the following: unspecified, keyCompromise, CACompromise,
affiliationChanged, superseded, cessationOfOperation, certificateHold, and removeFromCRL.

You can locate the correct certificate serial number via the db/index file:

$ cat db/index | tr '\t' ' '

V 340105050154Z 66F314E24AC4FDB09BD9912E7108EA8D unknown /C=US/O=Example/CN=Example EBS JAR Private Root CA
R2
V 340105050336Z 66F314E24AC4FDB09BD9912E7108EA8E unknown /C=US/ST=California/O=EBS Customer/OU=JAR
Sign/CN=EBS Customer

Regenerate Certificate Revocation List File

If you revoke a certificate, or once a year when the CRL will expire according to the config parameter default_crl_days
= 400, you must generate a new CRL file.

$ openssl ca -gencrl -config ebsca.conf -out ebsca.crl

You must then make the regenerated CRL available for download from the URL specified in the crl_url config parameter.

A3. Create a Private CA Using the OCI Certificates service

The OCI Certificates service can be used to set up a simple private CA, with revocation support via CRL.

The OCI Certificates service has online documentation here:

https://docs.oracle.com/en-us/iaas/Content/certificates/

You will need to perform the following high-level steps:

1. Create a HSM key in the OCI Vault service (Asymmetric RSA4096).

2. Optionally create a bucket in the Object Storage service - for the optional CRL.
3. Set up permissions for OCI Certificates service to access the key.
4. Create a CA in OCI Certificates, referencing the key in the vault - and optionally the CRL bucket.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 18/29
3/20/25, 12:36 PM Document 1591073.1
5. Create an externally-managed certificate where you will upload your code signing CSR, and have it signed by the
CA.

A known issue with the OCI Certificates service is that when creating a certificate as Issued by internal CA, managed
externally the BUI does not prompt you to select and apply a Certificate Profile Type that sets the appropriate keyUsage
and extendedKeyUsage certificate extensions.

To make an OCI Certificates signed certificate work as a code signing certificate, you must add the required TLS extensions
in the CSR. This means that when generating the CSR for the EBS code signing keystore file you must specify the key
usage extensions.

The keytool command to generate the CSR, with keyUsage and extendedKeyUsage extensions, becomes:

$ keytool -certreq -keystore $KS -alias $AL -file $AL.csr \

-ext ku:c=dig,keyEncipherment -ext eku:c=codeSigning

After the certificate has been created based on your CSR, you can download the code signing certificate and its certificate
chain from the BUI by selecting the certificate from the list and choosing View Details from the vertical '?' menu to the
right.

Figure 1 - Code Signing Certificate

Appendix B: Desktop JRE Configuration

The JRE8 deployment configuration on individual desktops that must run EBS forms can be tweaked in various ways.

The Java 8 SE Deployment Guide is available at:

https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/

and the Deployment Configuration File and Properties section is available at:

https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/properties.html

The deployment model supports system-level and user-level deployment properties.

These properties are stored outside the JRE installation folder, and will not be affected by the quarterly security updates to
the JRE.

A default installation of the JRE does not have any system-level properties: each user gets a default set of properties, and
can modify the user-level properties via the Java Control Panel application.

A set of system-level properties can either provide default values that can be overridden by user-level properties, or set the
required values and be locked to prevent the user setting possibly conflicting user-level properties.

The default location for property files on the desktop depends on the desktop OS:

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 19/29
3/20/25, 12:36 PM Document 1591073.1

Client
User-Level Location System-Level Location
OS

Windows %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\ %windir%\Sun\Java\Deployment\

macOS ~/Library/Application Support/Oracle/Java/Deployment/ /Library/Application

Support/Oracle/Java/Deployment/

Depending on your chosen mode of operation for desktop management, you can either make a web page available listing
the steps that each user must perform to set user-level properties (trust a CA, create exception list, turn off revocation
checking for code signing certificates), or you can implement system-level settings for deployment on the users' desktops
(Window or macOS).

This appendix includes the following sections:

B1. Making the Desktop JRE Trust Your Private CA - User Level
B2. Allowlisting EBS JARs via Exception Site List - User Level
B3. Allowlisting EBS JARs via Deployment Rule Set - System Level
B4. Example Desktop JRE Configuration

B1. Making the Desktop JRE Trust Your Private CA - User Level

If you are using a code signing certificate from a private CA to sign your EBS JARs, you must make the desktop JRE trust
that private CA as a signer of code.

The folllowing steps describe how to install the private CA root certificate in the JRE manually using the Java Control Panel.

1. Download the root CA certificate to your desktop where the JRE8 is installed.
2. Open the Java Control Panel on your desktop and select the Security tab.

To locate the Java Control Panel, see the instructions for Windows and macOS as applicable.

The full documentation of the Java Control Panel for Java 8 is available at:
https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/jcp.html.

Figure 2 - Java Control Panel

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 20/29
3/20/25, 12:36 PM Document 1591073.1

Note: If your private CA does not provide server(s) for certificate revocation checking (CRL or OCSP), do not select
Very High as your Security Level.

3. Select Manage Certificates to open the Certificates window.

4. Choose Certificate type: Signer CA, User tab (The System tab list certificates from cacerts in read-only mode.).

Figure 3 - Java Control Panel Main Certificates Window

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 21/29
3/20/25, 12:36 PM Document 1591073.1

Figure 4 - Java Control Panel Import Certificates Window

5. Click Import to import the <root>.crt file you downloaded to your desktop

The above image shows the window after the private root has been imported.

6. Click Close to close the Certificates Window and the Java Control Panel.

Your desktop JRE will now trust JARs signed by your private CA.

The Signer CA - User certificate has been imported into a Java keystore file that serves as an additional truststore for the
JRE.

The additional truststore file is located at

%USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security\trusted.cacerts and the contents look like this
(listed by keytool -list -keystore trusted.cacerts):

usercacert-2972104843581866457, Jan 10, 2024, trustedCertEntry,

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 22/29
3/20/25, 12:36 PM Document 1591073.1
Extracts from the verbose (-v) listing show:

Alias name: usercacert-2972104843581866457

Owner: CN=Example EBS JAR Private Root CA R2, O=Example, C=US
Issuer: CN=Example EBS JAR Private Root CA R2, O=Example, C=US

If your chosen Private CA does not support revocation checking, turn it off using the JCP 'Advanced' tab.

B2. Allowlisting EBS JARs via Exception Site List - User Level

The JRE has a feature whereby you can declare JARs from a particular site as allowed-to-run. This allow code to run if it is
downloaded from specific sites identified by the webentry URL. Warning popups will be shown, but the user will be allowed
to acknowledge and ignore the warning.

The documentation for this is in the Java 8 Deployment Guide - specifically in Chapter 29 Exception Site List.

You can add one or more EBS webentries, such as for production and test environments:

Figure 5 - Exception Sites

Note: If an active Deployment Rule Set is installed on the system, the deployment rules take precedence over the
Exception Site List. The exception site list is considered only when the default rule applies. Since the Exception List
only allows you to run applications with “issues”, the Exception List is not required if you have correctly configured EBS
JARs and the desktop JRE.

B3. Allowlisting EBS JARs via Deployment Rule Set - System Level

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 23/29
3/20/25, 12:36 PM Document 1591073.1
The JRE has a feature whereby you can declare JARs either from a particular site, or signed by a particular code signing
certificate, as being trusted. This will typically result in fewer security warnings. You can also enforce the Java version of
the JRE. For further information, see Java 8 Deployment Guide - specifically, Chapter 28: Deployment Rule Set.

The high-level steps involved in setting up a Deployment Rule Set are as follows:

1. Create an XML file with appropriate rules.

2. Create a JAR file containing the XML file from Step 1.
3. Sign the JAR file.
4. Deploy the JAR file to client desktops.

Each of these steps will be discussed in turn below.

1. Create an XML file with appropriate rules.

The following XML will make JARs signed with your organization's code signing certificate trusted, where the SHA-
256 hash value is the hash of your code signing certificate.

<ruleset version="1.0+">
<rule>
<id>
<certificate algorithm="SHA-256" hash="66C99395E35525F84...18A2497A51C85E" />
</id>
<action permission="run" version="SECURE-1.8" />
</rule>
<rule>
<id></id>
<action permission="block">
<message>Blocked by corporate.</message>
</action>
</rule>
</ruleset>

You can retrieve the hash of your code signing certificate from:
The certificate PEM file that you received from the CA.
The ebsjarsign.p12 keystore file (where you imported it).
A JAR file signed by your code signing certificate (where jarsigner embedded it).

You have to use Java's keytool command to do the listing of the certificate and capture the SHA2 hash.

If you have the certificate in a PEM file, the following command will provide the value:

$ keytool -printcert -file ebsjarsign.crt | awk '/SHA256:/ {print $2; exit 0}' | tr -d :

If you already imported the code signing certificate into ebsjarsign.p12, you can run the following command:

$ keytool -printcert -keystore ebsjarsign.p12 -alias ebsjarsign | awk '/SHA256:/ {print $2; exit 0}' |
tr -d :

If you have already used your code signing certificate to sign EBS JARs, run this command:

$ keytool -printcert -jarfile fndforms.jar | awk '/SHA256:/ {print $2; exit 0}' | tr -d :

2. Create a JAR file containing the XML file.

$ jar -cvf DeploymentRuleSet.jar ruleset.xml

3. Sign the JAR file.

$ jarsigner -keystore ebsjarsign.p12 DeploymentRuleSet.jar ebsjarsign

You can get the alias in your ebsjarsign.p12 by having keytool list it as follows:

$ true | keytool -list -keystore ebsjarsign.p12 | grep PrivateKeyEntry

4. Deploy the JAR file to client desktops.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 24/29
3/20/25, 12:36 PM Document 1591073.1
The signed DeploymentRuleSet.jar file will have to be deployed to each desktop than must run Forms.

The default location for DeploymentRuleSet.jar on the desktop depends on the desktop operating system:

Client OS Location

Windows %windir%\Sun\Java\Deployment\

macOS /Library/Application Support/Oracle/Java/Deployment/

You will need to create the directory if it does not already exist.

You can make the signed DeploymentRuleSet.jar file available for download by client from any internal
webserver. If you are using a private CA, it makes sense to make the private CA's root certificate available from the
same location.

Once the DeploymentRuleSet.jar file is correctly installed, the Security tab in the Java Control Panel on your
desktop will display a link to View the active Deployment Rule Set.

B4. Example Desktop JRE Configuration

If you have decided to use a Private CA for signing the EBS client JAR files, and you want a Deployment Rule Set (DRS) file
to ensure that the JRE only runs JARs signed by your organization's EBS JAR signing certificate, you can have your end
users configure their own desktop JRE for that.

The below example for Windows require your end users to have administrative privileges on their desktops to be able to
write in the JRE's SYSTEM Level directory to install the Deployment Rule Set (DRS).

B4.1 Create distribution directory on your EBS application tier

If you create $INST_TOP/portal/jre8/, that directory will be available as <ebs-web-entry>/jre8/ in the user's browser.
For example, https://ebs122.example.com/jre8/: as shown in the following example:

$ mkdir $INST_TOP/portal/jre8/

Copy the files needed on the desktop:

$ cp jarca.crt $INST_TOP/portal/jre8/
$ cp DeploymentRuleSet.jar $INST_TOP/portal/jre8/

Copy the instructions, including two image files referenced from the instructions:

$ cp index.html $INST_TOP/portal/jre8/
$ cp JCP-Import.png $INST_TOP/portal/jre8/
$ cp JCP-no-revocation.png $INST_TOP/portal/jre8/

B4.2 Inform users of JRE configuration tasks

You could send an email to your EBS Forms users pointing them to <ebs-web-entry>/jre8/.

Below is an example of index.html. You can adjust it for your situation, in particular by:

Updating the webentry in the curl download commands.

Creating screenshots to show your distinguished names for certificate.

<!doctype html>
<html>
<head>
<meta charset="UTF-8">
<title>Untitled Document</title>
</head>
<!DOCTYPE html>
<html>
<head>
<title>ii Private CA - JAR Signing</title>
<style>
body { font-family: ariel, sans-serif; font-size:11pt; }
h1, h2, h3 { font-family: ariel, sans-serif; color:#66F; }
kbd {color:blue; }
</style>
</head>
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 25/29
3/20/25, 12:36 PM Document 1591073.1
<body>
<h1>Adapt Your Desktop JRE to Our Private CA </h1>
<p>
If you are a user of our Oracle e-Business Suite system and use Oracle Forms, read on, if not, you can skip
these instructions!.
<p>
We have changed to use a Private Certificate Authority to sign the EBS client JARs, so now your desktop JRE
must trust our Private CA.<br/>
This is done by importing the Private CA's root certificate into your desktop JRE's truststore.

<h2>Download to Windows Desktop with JRE8</h2>

<p>
The following files must be present on your desktop to trust our Private CA and to make Java on your desktop
trust the EBS Client JARs signed with our code signing certificate.
<ol>
<li> <a href=rootca.crt>rootca.crt</a> Root certificate for Private CA that signed the code signing
certificate
<li> <a href=DeploymentRuleSet.jar>DeploymentRuleSet.jar</a> - Deployment Rule Set file that trusts code
signed with our code signing certificate
</ol>
Follow the instructions below to install them.
<h3>1. Install <kbd>rootca.crt</kbd> as a trusted 'Signer CA' certificate in the 'User' tab of the 'Security'
tab of the Java Control Panel.</h3>
You can download <kbd>rootca.crt</kbd> using your browser and save it to disk and start the Java Control
Panel from the Start menu, <p>or you can use the command line to download <kbd>rootca.crt</kbd> and start
Java Control Panel.
<pre>
C:\Users\User> <kbd>md %USERPROFILE%\Desktop\DL </kbd>
C:\Users\User> <kbd>cd %USERPROFILE%\Desktop\DL </kbd>
C:\Users\User\Desktop\DL> <kbd>curl https://ebs122.example.com/jre8/rootca.crt -o rootca.crt </kbd>
C:\Users\User\Desktop\DL> <kbd>"C:\Program Files\Java\jre-1.8\bin\javacpl.exe" </kbd>
</pre>
either way, perform the certificate import using the Java Control Panel as shown in the screen shot below.
</p>
<details>
<summary><b>Screenshot of Import of Private CA Root Certificate...</b> </summary>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <img align=center alt="Java Control Panel - Import 'Signer CA'
certificate" src="JCP-Import.png">
</details>
<p>
As our Private CA does not offer revocation service, disable revocation checks for the code signing
certificate
<details>
<summary><b>Screenshot of Turning Off Revocation Check...</b></summary>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<img align=center alt="Java Control Panel - Turn off revocation check"
src="JCP-no-revocation.png">
</details>

<h3>2. Install DeploymentRuleSet.jar in %windir%\Sun\Java\Deployment\ </h3>

<p>
This DeploymentRuleSet allows all JARs signed by our code signing certificate to run and blocks all other
JARs.
<p>
Run <kbd>cmd.exe</kbd> as <i>Administrator</i> to be able to write under <kbd>%windir%</kbd>
<pre>
C:\Users\User> <kbd>md %windir%\Sun\Java\Deployment\ </kbd>
C:\Users\User> <kbd>cd %windir%\Sun\Java\Deployment\ </kbd>
C:\Windows\Sun\Java\Deployment> <kbd> curl https://ebs122.example.com/jre8/DeploymentRuleSet.jar -o
DeploymentRuleSet.jar</kbd>
</pre>
<p>
Once installed you can inspect the Deployment Rule Set from the link in the 'Security' tab of the Java
Control Panel.
</body>
</html>

Appendix C: Using the adjss Utility for Configurable JAR Signing

The new adjss utility is a program that is used to configure the JAR signing mode and any required parameters for JAR
signing. It replaces the previous adkey utility that was used to generate a keystore file with code signing private key and
certificate(s), and in addition sets up the additional parameters required to sign using jarsigner and the keystore file.

The adjss utility does not create any keystore files. If a keystore file is required, it is created using Java's standard
keytool command. The adjss utility can register the name of a keystore file and additional parameters required to sign
using jarsigner and the keystore file.

Using adjss, three modes can be configured:

KEYSTORE – Uses private key in keystore file to sign JARs.

NONE – Does not sign any JARs.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 26/29
3/20/25, 12:36 PM Document 1591073.1
CUSTOM – Calls customjarsign.sh to sign JARs.

Only KEYSTORE mode require additional parameters. CUSTOM mode require you to create a custom JAR signing script
with a fixed name placed at a fixed location. NONE requires nothing, as it simply turns off AD signing and leaves signing to
the user.

The online help for adjss looks like this:

$ adjss -help

Show this brief syntax help

adjss -mode KEYSTORE -keystore $PWD/$KS -alias $AL -sigfile CUST

Set mode to KEYSTORE and store parameters (after validating them)

Keystore passwords prompted for and stored in DB (which require APPS password)

adjss -mode CUSTOM

Set mode to CUSTOM and verify customjarsign.sh is installed.

adjss -mode NONE

Set mode to NONE.

adjss -migrate

Use existing, working adkeystore.dat + adsign.txt to create new style KEYSTORE mode in adsignmode.txt
and adsignparameters.txt

keystore password remains unchanged in the database

adjss -list

List the current mode and any parameters.

adjss -verify

List the current mode and any parameters, using

For KEYSTORE mode parameters are verified (keystore file, alias in keystore, passwords).

For CUSTOM mode customjarsign.sh is verified for existence and executability.

adjss -sign /full/path/to/test.jar

Sign the passed JAR file using the configured mode and show successfully signed JAR, using:

For KEYSTORE mode the JAR is signed using jarsigner and the configured keystore parameters
jarsigner -keystore <keystore> -sigfile <sigfile> /full/path/to/test.jar <alias> + passwords

For CUSTOM mode the JAR file is added to a jarlist.txt file and the signing is attempted as
customjarsign.sh $PATH_TO/jarlist.txt

KEYSTORE mode

The KEYSTORE mode is very similar to the older mode that used a fixed name keystore file adkeystore.dat and a small
parameter file adsign.txt. In fact they are so similar that an existing and working setup can be migrated to the new
format using just one command: adjss -migrate. When you apply AD Patch 36492441, your existing setup will be
automatically migrated to KEYSTORE mode.

The old code had adjkey create adkeystore.dat, and a small parameter file, adsign.txt. adsign.txt held the following
parameters:

adsign.txt

<keystore key alias> 1 <sigfile>

The AD JAR signing code knew where to find adkeystore.dat and adsign.txt, then used that information to call the
jarsigner utility.

The adjss utility stores the same information in two new files, adsignmode.txt and adsignparameters.txt. The
contents for KEYSTORE mode is as follows:

adsignmode.txt

KEYSTORE

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 27/29
3/20/25, 12:36 PM Document 1591073.1
adsignparameters.txt

<keystore-file-name> <keystore key alias> <sigfile>

In both old and new scenarios, the passwords for the keystore file are stored in the database to enable the hands-off,
automated signing.

CUSTOM mode

In CUSTOM mode, AD will call <AD_JRI_LOC>/customjarsign.sh <path-to>/jarsign.txt to sign the JARs.

As the user, you are responsible for developing customjarsign.sh and copying it to <AD_JRI_LOC>/.

NONE mode

AD will not sign any JARs. It will, however, generate a jarlist.txt file that contains the full path of each JAR file it would
have signed.

As the user, you are responsible for signing the necessary JAR files, either using the AD generated jarlist.txt or a site-
specific, shorter list of client JARs that are actually in use at your site.

See Appendix D. Identifying JARs That Need Signing.

Appendix D: Identifying JARs That Need Signing

Only client JAR files (JARs that get downloaded and run in the desktop JRE) need to be signed.

AD relies on flags (<NOSIGN> <NOLIST>) in the DEP files (a type of makefile) to determine if a JAR regenerated on site
needs to be signed.

This will include any JARs identified by Oracle as client JARs. As a customer running a subset of EBS, you will not need all
these JARs, but can instead generate a shorter list of JARs that are actually used on your site.

This shorter list can be used in CUSTOM mode or NONE mode to avoid signing JARs that do not need signing: to do this,
ignore the AD generated jarlist.txt file and use your own shorter list.

The usedjarlist.txt can be generated on site from the OHS access_log files. To reduce the chance of missing
infrequently used applets, we recommend examining one year (or 400 days) of logs as an optimal solution. If end users
report issues that indicate you have missed any, you can easily add the missing JARs to your list.

The following awk script looks for requests starting with "/OA_JAVA/" followed by ".jar", plus a success response code of
< 400 (typically, 200 OK and 304 Not Modified).

$ cat 400-days-of-access_log | awk ' $7 ~ /^\/OA_JAVA\/.*.jar/ && $(NF-1) < 400 {print $7}' |
sort -u | tee -a ~/usedjarlist.web
/OA_JAVA/oracle/apps/fnd/jar/fndaol.jar
/OA_JAVA/oracle/apps/fnd/jar/fndaolj.jar
/OA_JAVA/oracle/apps/fnd/jar/fndbalishare.jar
/OA_JAVA/oracle/apps/fnd/jar/fndctx.jar
/OA_JAVA/oracle/apps/fnd/jar/fndewt.jar
/OA_JAVA/oracle/apps/fnd/jar/fndformsi18n.jar
/OA_JAVA/oracle/apps/fnd/jar/fndforms.jar
/OA_JAVA/oracle/apps/fnd/jar/fndlist.jar
/OA_JAVA/oracle/apps/fnd/jar/fndswing.jar
/OA_JAVA/oracle/apps/fnd/jar/fndutil.jar

Then convert the web path to a local file path:

$ cat ~/usedjarlist.web | sed "s:^/OA_JAVA:$JAVA_TOP:" | tee -a ~/usedjarlist.txt

/u01/install/APPS/fs1/EBSapps/comn/java/classes/oracle/apps/fnd/jar/fndaol.jar
/u01/install/APPS/fs1/EBSapps/comn/java/classes/oracle/apps/fnd/jar/fndaolj.jar
/u01/install/APPS/fs1/EBSapps/comn/java/classes/oracle/apps/fnd/jar/fndbalishare.jar
/u01/install/APPS/fs1/EBSapps/comn/java/classes/oracle/apps/fnd/jar/fndctx.jar
/u01/install/APPS/fs1/EBSapps/comn/java/classes/oracle/apps/fnd/jar/fndewt.jar
/u01/install/APPS/fs1/EBSapps/comn/java/classes/oracle/apps/fnd/jar/fndformsi18n.jar
/u01/install/APPS/fs1/EBSapps/comn/java/classes/oracle/apps/fnd/jar/fndforms.jar
/u01/install/APPS/fs1/EBSapps/comn/java/classes/oracle/apps/fnd/jar/fndlist.jar

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 28/29
3/20/25, 12:36 PM Document 1591073.1
/u01/install/APPS/fs1/EBSapps/comn/java/classes/oracle/apps/fnd/jar/fndswing.jar
/u01/install/APPS/fs1/EBSapps/comn/java/classes/oracle/apps/fnd/jar/fndutil.jar

You now have your own site-specific list of JARs that need signing, listed in the file ~/usedjarlist.txt.

This list can be used either in NONE mode, or in CUSTOM mode if your customjarsign.sh script ignores the filename
passed by AD tools and just uses your own list.

Note: For guidance about how to locate the OHS access_log files and identify the files that make up 400 days of logs,
see references to webusage.out in the Allowed Resources section of Oracle E-Business Security Guide.

Change Log

Date Description

2024-
12-17 Updated Sections 5.1.2 and 5.2.1 to reflect cloning action changes associated with new JAR signing
model.

2024-
08-06 Made minor tweaks to formatting.

2024-
08-05 Initial publication (under same Doc ID) of this completely rewritten document, which now describes the
new (as of August 2024) configurable options for JAR signing. For the previous content, refer to
Document 3015098.1.

My Oracle Support Knowledge Document 1591073.1 by Oracle E-Business Suite Development.

Copyright © 2024, Oracle and/or its affiliates.

Didn't find what you are looking for?

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_158&id=1591073.1 29/29