PART 1: Introduction

What is Code Signing Certificate for Java?

Oracle is tightening up security around Java. Java is one of the most wildly exploited pieces of software by viruses and malware bots.

Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed by use of a cryptographic hash.

A code signing certificate from a Trusted CA is required to sign your Java content securely.

It allows you to deliver signed code from your server (e.g. jar files) to users desktops and verifying you as the publisher and trusted provider of that code and also verifies that the code has not been altered. A single code signing certificate allows you to verify any amount of code across multiple EBS environments. This is a different type of certificate to the commonly used SSL certificate which is used to authorize a server on a per environment basis. You cannot use an SSL certificate for the purpose of signing jar files.

Remember that code signing certificates are different from the SSL certificates which are used for web URLs.  Code signing certificates are used for sign files like Java JAR files, Windows kernel drivers, Windows program installation EXEs and ActiveX files. SSL certificates try to verify and establish a secure connection to a web host,  whereas code signing certs help users identify any piece of program.

What is Self-Signed Certificate?

This has been used historically and is the default method used within EBS as a simplistic way to sign Java content. There is no root certificate and it cannot be properly trusted.

Along with unsigned code this is NOW regarded as an insecure way of delivering Java content. When running the latest JRE 7 releases this will now cause extra security prompts and in certain cases will not allow Java content to run.

What is Trusted CA?

Either an Official CA (such as Verisign, Thawte etc.) or your own in-house PKI/Certificate AuthorityCA solution (in-house CA).

From EBS perspective, what will happen if you use JRE 7u40 and above AND self signed certificate AND medium Java security settings?

The security Warning: “Running unsigned applications like this will be blocked in a future release because it is potentially unsafe and a security risk” will pop.

The user can click through this message to launch the Java content. Unlike earlier JRE releases there is no longer the option to remember this decision for future logins. When running JRE 7u40 and later this message will therefore appear every time you start a new session, it can no longer be suppressed.

PART 2: Prerequisite Steps

2.1) Run ADGRANTS.SQL

For R12.1

Download below Application Patches but not apply yet.

1) Patch 17191279: CONSOLIDATED JRI FIXES

Size: 388.9 KB

Type: ADPATCH

2) Patch 17066340: JRECASIGN: THE ALIAS PARAM SHOULD ALLOW CUSTOMIZATION AND NOT USE $CONTEXT_NAME

Size: 18.1 KB

Type: ADPATCH

For R12.2

1) Patch 17545215 CONSOLIDATED JRI FIXES FOR 12.2

–NO NEED TO APPLY THIS PATCH IF YOU HAVE latest AD RUP 4

Type: ADOP

2) Patch 17766337: R12.AD.C.delta.4 or higher

Type: ADOP

Before we apply above  ‘Consoldated JRI Patch’, we need to  run the adgrants.sql script as a user that can connect as SYSDBA to grant privileges to selected SYS objects and create PL/SQL profiler objects.

1) Stop the EBS application services.

2) Create the directory $ORACLE_HOME/appsutil/admin on the database server if it does not already exist.

3) Set the environment to point to ORACLE_HOME on the database server.

4) If you already have a version of adgrants.sql under your ORACLE_HOME that is a later version than the one supplied in the patch, go to step 4.

If not, copy <patch_dir>/admin/adgrants.sql (UNIX) from this patch directory to $ORACLE_HOME/appsutil/admin.

You will find it here for R12.1 > 17191279/admin/adgrants.sql , For R12.2 > 17545215/admin/adgrants.sql

5) Use SQL*Plus to run the script:

$ sqlplus /nolog

SQL> @$ORACLE_HOME/appsutil/admin/adgrants.sql <APPS schema name>

2.2 Apply Application Patches

Below are the patches that we already downloaded in previous steps. Apply them one by one.

Application services were already stopped in previous steps. Put application instance in maintenance mode and apply patches using adpatch.

For R12.1

1) Patch 17191279: CONSOLIDATED JRI FIXES

NO PRE REQ STEPS EXCEPT ABOVE adgrants.sql which we already run

2) Patch 17066340: JRECASIGN: THE ALIAS PARAM SHOULD ALLOW CUSTOMIZATION AND NOT USE $CONTEXT_NAME

NO PRE REQ STEPS

For R12.2

1) Patch 17545215 CONSOLIDATED JRI FIXES FOR 12.2

–NO NEED TO APPLY THIS PATCH IF YOU HAVE latest AD RUP 4

2) Patch 17766337: R12.AD.C.delta.4 or higher

PART 3: Generate Keypair and Certificate Signing Request

3.1) Generate a new keypair (private key and public key)

In ORACLE E-Business Suite 12.1.x,  jar signing files are located under the $APPL_TOP/admin.

For R12..2, path is $NE_BASE/EBSapps/appl/ad/admin

Like > adconfig.txt, adsign.txt, appltop.cer, javaVersionfile, adkeystore.dat

Where:

JavaVersionFile – The Java version used in compilation (The JDK version on your server)

adsign.txt – Used to pass arguments to the JRI during file signing. The first value within this file is your alias.

adkeystore.dat – The keystore file that is used to sign jar files on the server.

If you wish to create a new keypair (private key and public key) with the RSA algorithm and your selected bit key size and load it into the keystore (adkeystore.dat) run the following command.

$ adjkey -initialize -keysize 2048

Enter the APPS username: apps
Enter the APPS password: <GIVE_APPS_PASSWORD>
Enter the Name of your Company (used for both CN and ORGANIZATION NAME) [CN/ORGANIZATION NAME]: <PUT CORPORATION NAME>
Enter the department or group that will use the certificate [ORGANIZATION UNIT] : <PUT ORGANIZATION UNIT>
Enter the full name of the city where your organization's head office is located [LOCALITY] : <PUT CITY>
Enter the full name of the State, Province or County where your organization's head office is located [STATE] : <PUT STATE>
Enter the two-letter ISO abbreviation for your country (for example, US for the United States) [COUNTRY] : <PUT COUNTRY>

This will back up your existing keystore (adkeystore.dat to adkeystore.bak) and also create the following files under the $APPL_TOP/admin directory):

– adkeystore.bak

– JavaVersionFile

– adsign.txt

– adkeystore.dat

3.2) Create a Certificate Signing Request

Create a “Certificate Signing Request” named adkeystore.csr which can then be sent to your CA provider for signing.

Below is for R12.1 ( For R12.2 use path as $NE_BASE/EBSapps/appl/ad/admin)

$ adjkey -certreq -file $APPL_TOP/admin/adkeystore.csr

Enter the APPS username: apps
Enter the APPS password: <GIVE_APPS_PASSWORD>

3.3) Submit your Certificate Signing Request

Submit your certificate signing request (adkeystore.csr) to your official certificate authority, for example, Verisign or Thawte or to your own in-house certificate authority as applicable.

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

PART 4:  Import the Signed Certificate

4.1) Add the Root Certificate to cacerts

Remember > You can use same java code signing certificate in Multiple EBS instance.

Copy your Root Certificate to above directory and Rename to say javarootca.crt

Note: The default Java <cacerts_password> for the cacerts keystore certificates file is usually changeit.

$ cd $OA_JRE_TOP/lib/security/
$ keytool -import -alias javarootca -file javarootca.crt -trustcacerts -v -keystore cacerts

Enter keystore password: <cacerts_password>
Trust this certificate? [no]: y
Certificate was added to Keystore
[Storing cacerts]

$ chmod a-w cacerts

4.2) Changing the Keystore Certificate File Password (if required)

<< This is not mandatory. You may skip this step >>

The keystore certificate file (cacerts) password can be changed using the following command, replacing the values in bold as applicable to your organization:

$ cd $OA_JRE_TOP/lib/security/

$ keytool -storepasswd -keystore cacerts

Enter keystore password: <cacerts_password>

New keystore password: <new_cacerts_password>

Re-enter new keystore password: <new_cacerts_password>

To verify, list Java Keystore Certificate Files>>

$ keytool -list -keystore cacerts

4.3) Import the Code Signing Certificate into the Keystore

You may rename the ‘Code Signing Certificate’ signed by your trusted CA to adkeystore.crt or some other name.

For R12.2, use path $NE_BASE/EBSapps/appl/ad/admin instead of $APPL_TOP/admin

$ cp  adkeystore.crt  $APPL_TOP/admin
$ cd $APPL_TOP/admin
$ adjkey -import -file adkeystore.crt –trustcacerts

Enter the APPS username: apps
Enter the APPS password: <input_apps_password>

Your keystore (adkeystore.dat) should now contain your private key and a corresponding CA-signed code-signing certificate. AD tools can now sign the JARs served to clients using this information.

PART 5:  Regenerate the Jar Files

5.1) Shutdown the Application Tier

Shut down the application tier services:

$ cd $ADMIN_SCRIPTS_HOME
$ adstpall.sh apps_user/apps_pwd

 5.2) Regenerate the jar files through adadmin

Regenerate all JAR Files using the force option through adadmin:

Run adadmin, and select the following from the AD Administration Main Menu:

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

5.3) Restart the Application Tier

Restart the application tier services:

$ cd $ADMIN_SCRIPTS_HOME
$ adstrtal.sh apps_user/apps_pwd

PART 6:  Verify the Forms JAR Files are signed with the new certificate”

If you wish to verify that your Jar files are now signed correctly with the new certificate, run the following steps from your desktop client:

Navigate to ‘Control Panel’ -> ‘Java’ -> ‘Security’ (tab) -> ‘Manage Certificates’ (button) -> ‘Certificate Type: Trusted Certificates’

Select your new certificate from the list and click the ‘Export’ button, save the file as <hostname>.crt, e.g. myhost.crt

Double click on the <hostname>.crt file to display the certificate.

Click the ‘Details’ tab and verify the following values correspond to the values you gave earlier:

‘Valid from’ displays the date and time that you created the certificate

‘Subject’ contains values for CN, OU, O, L, S, C
namely [CN], [ORGANIZATION UNIT], [ORGANIZATION NAME], [LOCALITY], [STATE], [COUNTRY]

‘Public Key’ displays ‘RSA (XXXX Bits)’ e.g. ‘RSA (2048 Bits)

PART 7: References

• Enhanced Jar Signing for Oracle E-Business Suite (Doc ID 1591073.1)
• Document 1467892.1 titled, ‘Using JDK 7.0 Latest Update with Oracle E-Business Suite Release 12.0 and 12.1′
• https://blogs.oracle.com/stevenChan/entry/sign_e_business_suite_jar
• https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias

• Author
• Recent Posts

Brijesh Gogia

I’m an experienced Cloud/Oracle Applications/DBA Architect with more than 15 years of full-time DBA/Architect experience. I have gained wide knowledge on Oracle and Non-Oracle software stack running on-prem and on Cloud and have worked on several big projects for multi-national companies. I enjoy working with leading-edge technology and have a passion for Cloud architecture, automation, database performance, and stability. Thankfully my work allows me time for researching new technologies (and to write about them).

Latest posts by Brijesh Gogia (see all)

• Oracle Multitenant DB 4 : Parameters/SGA/PGA management in CDB-PDB - July 18, 2021
• Oracle Multitenant DB 3 : Data Dictionary Architecture in CDB-PDB - March 20, 2021
• Oracle Multitenant DB 2 : Benefits of the Multitenant Architecture - March 19, 2021