Skip to content

Importing Java Code Signing Certificate into Oracle EBS R12.1/R12.2

Oracle is tightening up security around Java. Java is one of the most wildly exploited piece 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.

 If you are using JRE 7u40 and above AND self signed certificate (which are historically used) AND also have ‘medium’ Java security settings, the security Warning: “Running  applications by UNKNOWN publishers will be blocked in a future release because it is potentially unsafe and a security risk” will pop.

 

code_signing_error

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.

The solution to correct above security warning message when you are running your EBS instance with Client JRE7 is to import a Java code signing certificate into the EBS server so that all the JAR/code files which are getting transferred should be securely signed .

CONTENTS

PART 1: Introduction

PART 2: Prerequisite Steps

2.1) Run ADGRANTS.SQL

2.2) Apply Application Patches

PART 3: Generate Keypair and Certificate Signing Request

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

3.2) Create a Certificate Signing Request

3.3) Submit your Certificate Signing Request

PART 4:  Import the Signed Certificate

4.1) Add the Root Certificate to cacerts

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

4.3) Import the Code Signing Certificate into the Keystore

PART 5:  Regenerate the Jar Files

5.1) Shutdown the Application Tier

5.2) Regenerate the jar files through adadmin

5.3) Restart the Application Tier

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

PART 7: References

 


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.

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.

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)

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.

The caerts file is system wide keystore used by Java which needs to store the ‘Public Root Certificate’ of your CA provider. Add your root certificate to cacerts so that the jarsigner program trusts it.

Note for future consideration: Whenever you upgrade your jdk version on the server any additional certificates you have added to your cacerts file will be lost. You will need to re-import the root certificate or keep a copy of your original cacerts file which you can copy back in.

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.

 

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

 

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:

 

 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:

 

 

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

 

[Post Views: 22728]

Brijesh Gogia

I’m an experienced Oracle Applications DBA with more than a decade of full-time DBA experience. I have gained a wide knowledge of the Oracle software stack and have worked on several big projects for multi-national companies. I enjoy working with the leading-edge technology and have passion for database performance and stability. Thankfully my work allows me time for researching new technologies (and to write about them).
  
You can connect with me on LinkedIn.

One Comment

  1. sam sam

    Hi

    How do you use same java code signing certificate in Multiple EBS instance? When i tried it was giving error.

    adjkey -import -file adkeystore.crt

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

    AD Java Key Generation

    Version 12.0.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 PRODORA_ebsapp
    Enter keystore password: keytool error: java.lang.Exception: Input not an X.509 certificate

    adjkey error:

    keytool -import -file adkeystore.crt -trustcacerts -keystore /u01/r12stg/apps/apps_st/appl/admin/adkeystore.dat -alias PRODORA_ebsapp

    The above Java program failed with error code 1.

Leave a Reply

Required fields are marked *

error: Alert: Content is protected !!