3/20/25, 12:33 PM Document 3002237.

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

EBS Signing of JAR files with a Private CA with Examples (Doc ID 3002237.1)

In this Document

Goal
Solution
Section 1: Introduction
Section 2: Generate Keypair and Certificate Signing Request
Section 3: Import your Certificates
Section 4: Regenerate Jar Files
Section 5. Import the RootCA into the Java on the Client
Section 6. Expected Results and Verifcation

Appendix A: Creating a Minimally Viable Private CA using openssl

Appendix B: Private CA Operations
Appendix C: Multiple Instances/Sharing a Digital Certificate
History
References

APPLIES TO:

Oracle E-Business Suite Technology Stack - Version 11.5.10.0 to 12.2 [Release 11.5 to 12.2]
Information in this document applies to any platform.
This is a supplement for Note 1591073.1 - Signing JAR Files for Oracle E-Business Suite to include steps and sample
Internal CA

GOAL

To provide detailed example of signing and trusting EBS Jar files using a private CA with examples

This is a supplement document to Note 1591073.1 Please review that document for further details

SOLUTION

Section 1: Introduction

Historically, customers have relied on commerical Certificate Authorities (CAs) because their root certificates were
preloaded into Java. This convenience meant no changes were required on the desktop. However, as of June 1st, 2023,
all new commercial CAs for code signing must utilize Hardware Security Modules (HSMs). The adoption of HSMs
significantly alters how JAR files are signed and managed. Interestingly, managing root certificates on clients now
becomes easier than handling JAR files via HSM.

This note outlines an alternative approach involving the use of a Private CA, complete with practical examples. Opting
for a Private CA enables seamless signing of JAR files through adadmin and facilitates error-free launches of forms,
eliminating warnings. However, it's important to note that this method requires the Root certificate to be imported into
the Java environment on the PC to establish the necessary chain of trust. This step is necessary as opposed to
commercial CAs, whose root certificates are already included in the JRE's default truststore.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 1/13
3/20/25, 12:33 PM Document 3002237.1

Benefits
---------
Consistency: EBS Jar signing remains unchanged, unlike the dynamic nature of HSM-based signing.
Cost-Effective: Generating the certificate in-house, using private CA eliminates costs associated with commerical
certificates.
Certificate Management: The Private CA provides a long-living certificate, unlike commercial options.

Caveats
----------
Desktop Managment: Ensure the Root certificate is imported into the Java environment on the PC.
Certificate Revocation List (CRL): If using the CA mentioned in Appendix A, maintaining the CRL file is essential,
see CRL Managment

Section 2: Generate Keypair and Certificate Signing Request

After generating your Keypair and CSR you will need to submit the CSR to your private CA, if you do not have one
follow Appendix A to create one

Oracle E-Business Suite 12.2.x Users

<JRI_DATA_LOC> = $APPL_TOP_NE/ad/admin

Oracle E-Business Suite 11i, 12.0.x and 12.1.x Users

<JRI_DATA_LOC> = $APPL_TOP/admin

2.1 Generate Keypair

$ cd <JRI_DATA_LOC>

$ adjkey -initialize -keysize 2048 -alias <Example>

Use the alias option and take note of what was used, as it will be needed for CSR creation and importing the
certificate into the keystore

Example

admin]$ adjkey -initialize -keysize 2048 -alias ATG

Copyright (c) 2002, 2012 Oracle Corporation
Redwood Shores, California, USA

AD Java Key Generation

Version 12.2.0

NOTE: You may not use this utility for custom development
unless you have written permission from Oracle Corporation.

Reading product information from file...

Reading language and territory information from file...

Reading language information from applUS.txt ...

Enter the APPS username: apps

Enter the APPS password:

Successfully created javaVersionFile.

adjkey will now create a signing entity for you.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 2/13
3/20/25, 12:33 PM Document 3002237.1
Enter the COMMON NAME [ ] : Oracle Support

Enter the ORGANIZATION NAME [Oracle Support] :

Enter the ORGANIZATION UNIT [ ] : ATG

Enter the LOCALITY (or City) [ ] : LA

Enter the STATE (or Province or County) [ ] : CA

Enter the COUNTRY (two-letter ISO abbreviation) [ ] : US

Enter keystore password: Re-enter new password: Enter key password for <ATG>
(RETURN if same as keystore password): Re-enter new password:
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using
"keytool -importkeystore -srckeystore /u02/apps/fs_ne/EBSapps/appl/ad/admin/adkeystore.dat -destkeystore
/u02/apps/fs_ne/EBSapps/appl/ad/admin/adkeystore.dat -deststoretype pkcs12".

/u02/apps/fs1/EBSapps/comn/util/jdk32/jre/bin/java -Djava.security.egd=file:/dev/urandom sun.security.tools.KeyTool -genkey -

alias ATG -keyalg RSA -keysize 2048 -keystore /u02/apps/fs_ne/EBSapps/appl/ad/admin/adkeystore.dat -validity 14600 -dname "
CN=Oracle Support, O=Oracle Support, OU=ATG, L=LA, S=CA, C=US"

The above Java program completed successfully.

Your digital signature has been created successfully and
imported into the keystore database. This signature
will now be used to sign Applications JAR files whenever
they are patched.

IMPORTANT: If you have multiple web servers, you must copy

files to each of the remaining web servers on your site.
See the documentation reference for more information.

adjkey is complete.

2.2 Create a Certificate Signing Request

cd <JRI_DATA_LOC>
$ adjkey -certreq -sigalg SHA256withRSA -file adkeystore.csr

Example

cd <JRI_DATA_LOC>
$ adjkey -certreq -sigalg SHA256withRSA -file adkeystore.csr
Copyright (c) 2002, 2012 Oracle Corporation
Redwood Shores, California, USA

AD Java Key Generation

Version 12.2.0

NOTE: You may not use this utility for custom development
unless you have written permission from Oracle Corporation.

Reading product information from file...

Reading language and territory information from file...

Reading language information from applUS.txt ...

Enter the APPS username: apps

Enter the APPS password:

Successfully created javaVersionFile.

alias name used is tim3
Enter keystore password: Enter key password for <tim3>
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an
industry standard format using "keytool -importkeystore -srckeystore
/u01/install/APPS/fs_ne/EBSapps/appl/ad/admin/adkeystore.dat -destkeystore
/u01/install/APPS/fs_ne/EBSapps/appl/ad/admin/adkeystore.dat -deststoretype pkcs12".

keytool -certreq -sigalg SHA256withRSA -file adkeystore.csr -keystore

/u01/install/APPS/fs_ne/EBSapps/appl/ad/admin/adkeystore.dat -alias ATG

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 3/13
3/20/25, 12:33 PM Document 3002237.1
The above Java program completed successfully.

adjkey is complete.

The above command should have generated a new file adkeystore.csr

2.3 Submit your Certificate Signing Request

Submit your certificate signing request 'adkeystore.csr' to your Internal (Private CA) for signing

Note: Be sure to request a Java Code Signing Certificate in PEM format. This certificate can be used to sign your jar
content across one or multiple Oracle E-Business Suite environments.

- If you are using the private CA from this note follow B.1 Sign a Code Signing Certificate Signing Request (CSR) to
sign it

Section 3: Import your Certificates

3.1 Create pem file

Create a PEM file by combing the root, intermediate(s), and code-siging certificates

cat privateCAroot.crt privateCAintermediates.crt adkeystore.crt > adkeystore.pems

If you have any intermediate certificates in your chain of trust, ensure that they are included in the command above. If
you have more than one intermediate certificate you must import them in chain of trust order starting with the one that
directly follows the root certificate.

Note not all CAs will have an intermeidate certificate, and if you are using a CA from this note there will not be one.

3.2 Import the PEM certificate into the keystore

cd <JRI_DATA_LOC>
$ adjkey -import -file adkeystore.pems -noprompt

Example

cd <JRI_DATA_LOC>
admin]$ adjkey -import -file adkeystore.pems -noprompt
Copyright (c) 2002, 2012 Oracle Corporation
Redwood Shores, California, USA

AD Java Key Generation

Version 12.2.0

NOTE: You may not use this utility for custom development
unless you have written permission from Oracle Corporation.

Reading product information from file...

Reading language and territory information from file...

Reading language information from applUS.txt ...

Enter the APPS username: apps

Enter the APPS password:

Successfully created javaVersionFile.

alias name used is ATG
Enter keystore password: Enter key password for <tim3>
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 4/13
3/20/25, 12:33 PM Document 3002237.1
industry standard format using "keytool -importkeystore -srckeystore
/u01/install/APPS/fs_ne/EBSapps/appl/ad/admin/adkeystore.dat -destkeystore
/u01/install/APPS/fs_ne/EBSapps/appl/ad/admin/adkeystore.dat -deststoretype pkcs12".

keytool -certreq -sigalg SHA256withRSA -file tim3.csr -keystore

/u01/install/APPS/fs_ne/EBSapps/appl/ad/admin/adkeystore.dat -alias atg

The above Java program completed successfully.

adjkey is complete.

Section 4: Regenerate Jar Files

4.1 Stop the Application Tier

Source your APPS env file and shutdown your application tier services.
Shut down the application tier services:

$ adstpall.sh

4.2 Regenerate the jar files through adadmin using Force

$ adadmin

Choose Generate Applications Files menu

From this menu choose Generate product jar files

Enter yes when prompted with: Do you wish to force regeneration of all jar files? [No] ? yes

Once your jar files have been successfully generated, restart the application tier.

4.3 Start the Application Tier

$ adstrtal.sh

Section 5. Import the RootCA into the Java on the Client

Download your CA root certificate for example, <root>.crt to the desktop and then follow the instructions for your
desktop operating system.

1. Open the 'Java Control Panel' on your desktop and select the 'Security' (tab).

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 5/13
3/20/25, 12:33 PM Document 3002237.1
2. Click Manage Certificates to open the 'Certificates' Window

3. Choose Certificate type: Signer CA

4. Click Import and upload the <root>.crt from your desktop

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 6/13
3/20/25, 12:33 PM Document 3002237.1

5. Close the 'Certificates' window and the 'Java Control Panel'. The certificate should now be installed in the Java 'Signer
CA' store.

4.4 Mac users

1. Go to System Settings

2. Click on the Java menu item to access the Java Control Panel.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 7/13
3/20/25, 12:33 PM Document 3002237.1
3. Import Root certificate using same steps from Windows instructions above

Section 6. Expected Results and Verifcation

Running an Environment for the First Time

After installing a new certificate authority in an Oracle E-Business Suite environment the jar signing certificate will need
to be installed in the Java certificate store on the desktop client before you can successfully access any Java content.
You will be asked to trust the publisher when accessing the Oracle E-Business Suite environment for the first time from
a desktop client.

When attempting to launch Java content the following message window should pop:

When asked "Do you want to run this application?"

Check "Do not show this again for apps from the publisher and location above"
(This will install the certificate into Java's 'Trusted Certificates' store and stop this message appearing
when accessing this environment in future)
Click the "Run" button

Appendix A: Creating a Minimally Viable Private CA using openssl

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

NOTE: While these Steps have been tested and vetted, they are NOT supported by Oracle Support,
and have been provided as an example only!

CRL Management

By default, Java validates the certificates' validity and checks for revocation status using CRL (Certificate Revocation
List). The CRL is a web file accessible via HTTP. The CRL file location is specified within the certificates generated by
the Private CA. Without access to this file, forms will launch with warnings, or may not launch at all with an errror.
Therefore, it's crucial to determine its hosting location, making it accessible to all end-users.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 8/13
3/20/25, 12:33 PM Document 3002237.1
Here are three options:

Option 1: Host the CRL on a standalone web server, where the Private CA may also be installed.

Option 2: Host the CRL on your Production EBS application server since it is likely to be accessible most of the
time. Note that to host it on EBS, you must ensure HTTP accessibility. To validate, attempt to access the robots.txt
file via HTTP at http://<webentryhost>.<webentrydomain>:80 for LBR or <web_port>/robots.txt. For example,
http://ebs.oracle.com:80/robots.txt.

Option 3: Disable CRL check on the client's Java console. Here's how:

Open the Java control panel.

Navigate to the Advanced tab.
Scroll to the bottom and locate "Perform signed code certificate revocation checks."
Select "Do not check" (not recommended).

Note: Although it's not recommended, it's considered safe assuming Java is solely used for forms on the PC (as
licensed).
Additionally, disabling the check can result in faster form launches as it skips the revocation check process when the
forms launch.

A.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

Note for your use you must choose values that reflect your host and domain where you are going to host the CLR in the
[default] section and your organization information in the [ca_dn] section. Change values < > and Bold to the required
values. if you are going to host the CRL on EBS make sure to use the PRODUCTION URL as that server will be up most
of the time
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 9/13
3/20/25, 12:33 PM Document 3002237.1

# Replace the values in BOLD for your own environment

cat > ebsca.conf <<-'EOF'

[default]
name = ebsca
host = <Host for the CRL file>
domain_suffix = <Domain for the CRL file >
port = <HTTP PORT>
aia_url = http://$host.$domain_suffix:$port/$name.crt
crl_url = http://$host.$domain_suffix:$port/$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 = 3653
default_crl_days = 3653
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
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 private key

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 10/13
3/20/25, 12:33 PM Document 3002237.1

openssl req -new \

-config ebsca.conf \
-out ebsca.csr \
-keyout private/ebsca.key

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

The generated (ebsca.key) is the private key and needs to be securely kept.

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 Forms clients must trust.

openssl's 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

so far this CA has only signed its own certificate.

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, without this file there were
will be an error launching forms, this file will also be used for EACH EBS instance that shares the code signing
certificate, if you are going to host this file on EBS it is best to put on your PRODUCTION node

Copy ebsca.crl to each application server on the EBS application tier for production to $INST_TOP/portal (for EBS 12.2
also copy to PATCH FS)
(However, if you are going to host the CRL in another URL, that you have specified in config file then copy it to that
location)

cp ebsca.crl $INST_TOP/portal

Hint - You can also copy the root certificate (ebsca.crt) to the same location for easy download by end users to
install on their PCs if required

Create Configuration File for Leaf Certificates (Code Signing)

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

cat >> leaf.conf <<EOF
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 11/13
3/20/25, 12:33 PM Document 3002237.1
[code_ext]
authorityInfoAccess = @issuer_info
authorityKeyIdentifier = keyid:always
basicConstraints = critical,CA:false
crlDistributionPoints = @crl_info
extendedKeyUsage = codeSigning
keyUsage = critical,digitalSignature
subjectKeyIdentifier = hash

EOF

Appendix B: Private CA Operations

At this point, you should have a fully functional CA that can be used to perform the following operations:

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 when revocation happens

B.1 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 (adkeystore.csr)
file. Sign it to produce a signed code signing certificate using the following command

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

adkeystore.crt

The newly generated code.crt and existing root (ebsca.crt) will have to be returned to the requestor for import into EBS
JAR signing keystore file (adkeystore.dat)

openssl's ca command keeps track of issued certificates in the text file db/index

[ebsCA]# 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

B.2 Revoke a Certificate

In the unlikely situation that you need to revoke a certificate (invalidate a not yet expired leaf certificate) the following
command is used.

$ openssl ca -config ebsca.conf \

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

(The -crl_reason can be one of the following unspecified, keyCompromise, CACompromise,

affiliationChanged, superseded, cessationOfOperation, certificateHold, and
removeFromCRL)

B.3 Regenerate Certificate Revocation List File

If a certificate is revoked, the CRL file must be regenerated, and copied to the server

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

Appendix C: Multiple Instances/Sharing a Digital Certificate

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 12/13
3/20/25, 12:33 PM Document 3002237.1
Back up and Copy Files

Step 1.1. Back up Files on 'Target' Environment

Back up the files listed below on the target instance substituting, for example:

EBS 12.2.x Users

$ cp -p $APPL_TOP_NE/ad/admin/adsign.txt
$NE_BASE/EBSapps/appl/ad/admin/adsign.txt.presign
$ cp -p $APPL_TOP_NE/ad/admin/adkeystore.dat
$NE_BASE/EBSapps/appl/ad/admin/adkeystore.presign

EBS 12.1.x, 12.0.x and 11i Users

$ cp -p $APPL_TOP/admin/adsign.txt $APPL_TOP/admin/adsign.txt.presign.
$ cp -p $APPL_TOP/admin/adkeystore.dat $APPL_TOP/admin/adkeystore.dat.presign

Step 1.2. Copy Files to the 'Target' Environment

Copy the files taken from your source environment to the directory listed above on your target environment as
appropriate to your Oracle E-Business Suite release.

Step 2. Regenerate the jar Files

Regenerate the jar files on the Target instance using the 'force' option through adadmin, see Section 4: Regenerate the
jar Files.

History
Initial Publication

REFERENCES

NOTE:1591073.1 - Signing JAR Files for Oracle E-Business Suite

Didn't find what you are looking for?

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=bc3lk9kaa_109&id=3002237.1 13/13