Automating Code Signing with multiple E-Business Suite instances - Part 3

Automating Code Signing with multiple E-Business Suite instances - Part 3

Johannes Michler PROMATIS Horus Oracle

Executive Vice President – Head of Platforms & Development

As you are probably aware by now, since June 1st 2023 all well-known / public Certificate Authorities (CA) no longer provide Code Signing Certificates using pure software based private keys (see

Since I prefer using such a trusted / public CA to sign Java Applets (that are still crucial for Oracle E-Business Suite or Oracle Forms) I've recently had a look into how we can now sign those Java JAR files. Part 1 of this blog series introduced the topic and an available "Cloud Based" Code Signing Certificate provider: Signing EBS/Forms - Part 1

In a second part I covered how the code signing can be done on an E-Business Suite Application Server running on Oracle Linux 7 on Oracle Cloud Infrastructure (OCI).

This third post will look how we can further automate this by installing the Certum tools onto the E-Business Suite Cloud Manager VM. First, we'll cover the latest changes from Certum, then we'll look into some scripts that can be used on multiple E-Business Suite Application servers to send the .jar files for signing to that central signing instance.

Certum Tool updates (April 2024)

Back in the previous post, I've complained about the incomplete translation of the Certum tools still revealing a lot of polish error messages. While it seems this is fixed at least partially, I realized that the 2.9.9 versions available over there leads to fatal crashes (segmentation fault). That is why for now I stuck with the 2.9.8 release.

Installing Certum SimplySignDesktop as a non-root user

When installing the SimplySignDesktop tool according to the official documentation it is necessary to do so globally/as the root user. Since I didn't like the tool to modify my cloud manager VM in that massive way, I've investigated what the installer actually does. With that I was able to get the tool running with a way less privileged user (that I call certum). Run the following as root:

yum install
yum install libxslt.x86_64 pulseaudio-libs-glib2.x86_64 libwebp.x86_64 xkeyboard-config
useradd certum
sudo su – certum
mkdir .ssh
vi .ssh/authorized_keys
# add the SSH public key(s) of your oracle@ebs-appserver
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Then connect a SSH Session with X-Forwarding as certum:

sh SimplySignDesktop-2.9.8- --target /home/certum/
cp /home/certum/SSD-2.9.8-dist/SimplySignDesktop.xml /home/certum/

Create a /home/certum/provider_simplysign.cfg file as follows:


Furthermore, create a script as follows:

export LD_LIBRARY_PATH=/home/certum/SSD-2.9.8-dist/
export QT_QPA_PLATFORM_PLUGIN_PATH=/home/certum/SSD-2.9.8-dist/plugins
export OPENSSL_CONF=/etc/ssl/
stalonetray &

Finally start the Script and sign in with a one-time-token.

Do a test as follows (in new SSH Session):

/home/certum/SS- -list -keystore NONE -storetype PKCS11 -providerclass -providerArg /home/certum/provider_simplysign.cfg -v

This will provide an alias, in our case: 4F4F410D1234A9110B16DA9C83BD6F59

Furthermore, create a /home/certum/mychain.pem file as described in the previous episode.

Passing the jars

On the E-Business Apps-Server first create a ~/ script as follows:

folderstamp=$(date +%Y-%m-%d-%H:%M)
mkdir -p /home/oracle/sign_bkp/${folderstamp}
# Remove Signature from jar files created through ADADMIN in EBS
echo " ** Removing EBS signature from: ${jar} "
cp -i ${jar} /home/oracle/sign_bkp/${folderstamp}/
zip -d ${jar} 'META-INF/*.SF' 'META-INF/*.RSA'
scp ${jar} certum@

ssh certum@ "/home/certum/SS- -keystore NONE -tsa \"\" -certchain /home/certum/mychain.pem -storetype PKCS11 -providerClass -providerArg /home/certum/provider_simplysign.cfg -storepass 12345 /tmp/signing-dummy.jar 4F4F410D1234A9110B16DA9C83BD6F59"

scp certum@ ${jar}

The script first creates a backup of the jar, then un-signs the .jar files and copies it to the cloud-manager VM (in my case with IP There the jar is signed and finally the signed .jar is copied back to the E-Business Suite Apps Tier.

This allows signing a single .jar file; the script may be helpful when applying a patch with "options=nojarsigning". Then in there should be a file such as /u01/install/APPS/fs_ne/EBSapps/log/adop/176/20240327_132920/apply/mastebsapp01/36177213/log/jarlist.txt containing all the .jar files that require re-signing.

For the initial signing the procedure in the previous episode can be combined with the copying of the .jar to the Cloud Manager VM.

Verifying and patching

As an alternative to signing "just" the files in $NE_BASE/EBSapps/log/adadmin/log/jarlist.txt I found it useful to just sign all .jar files under $JAVA_TOP. For this the following script proved helpful:

folderstamp=$(date +%Y-%m-%d-%H:%M)
mkdir -p /home/oracle/sign_bkp/${folderstamp}
# Select the jar files from jarlist.txt
for jar in $(find $JAVA_TOP/oracle/apps -name \*.jar)
# Remove Signature from jar files created through ADADMIN in EBS
echo " ** Removing EBS signature from: ${jar} "
cp -i ${jar} /home/oracle/sign_bkp/${folderstamp}/
zip -d ${jar} 'META-INF/*.SF' 'META-INF/*.RSA'
scp ${jar} certum@
ssh certum@ "/home/certum/SS- -keystore NONE -tsa \"\" -certchain /home/certum/mychain.pem -storetype PKCS11 -providerClass -providerArg /home/certum/provider_simplysign.cfg -storepass 12345 /tmp/signing-dummy.jar 4F4F410D1234A9110B16DA9C83BD6F59"
scp certum@ ${jar}

It is helpful to first to a check if the $jar is already signed as follows:

result=`jarsigner -verify -certs ${jar}| tr -d '[:space:]'`
if [[ "jarverified." != "$result" ]]
echo ${jar} needs re-sign; $result
# put the signing here


Using above scripts, it is amazingly easy to sign all .jar files both initially as well as after applying a patch. The version using a "find" on $JAVA_TOP may sign "a bit more than needed", but in my experience that does not do any harm.

I am still hoping that Oracle will provide a way to "Hook" a script such as into the signing process called during patching or through adadmin. This would probably be announced in "Signing EBS Jar Files With HSM (Hardware Security Module) - (Doc ID 2806640.1)".

Automating Code Signing with multiple E-Business Suite instances - Part 3

Accessing E-Business Suite Cloud Manager APIs - IDCS Token Management

Johannes Michler PROMATIS Horus Oracle

Executive Vice President – Head of Platforms & Development

Previously (, I described how you can use (unofficial) APIs to fully automate E-Business Suite environments hosted with Cloud Manager on Oracle Cloud Infrastructure (OCI). As you can see there, the actual call to trigger a clone or also the termination of an environment is rather simple. I've recently used that a lot when I worked on my clone scripts. In that process, I had to create ~10 clones, and doing so with a simple REST call saved me a lot of time.

In said post, we got hold of a "OAuth Bearer Token" that is needed to call those APIs in a very manual way "through the browser". In real life, this does not really come in handy. This blog post will describe how a bearer token (including a refresh token) can be received through the command line.


In preparation for using the scripts shown below, we have to enable the usage of "Device Codes" for the Cloud Manager application in IDCS:

Definition of Cloud Manager application in IDCS

Furthermore you should take note of the client_id, the client_secret and the IDCS url. All 3 have also been used during Cloud Manager setup.

A piece of Code

First of all, the following shell script does all the magic needed. You have to replace XXXXX, YYYYY and ZZZZZ with values from your environment:


PASS_ENC=`echo -n "$CLIENT_ID:$CLIENT_SECRET" | base64 -w 0`


if [ -f "mytoken" ]; then
REFRESH_TOKEN=`cat mytoken | jq '.refresh_token'| tr -d '"'`
echo refresh token: $REFRESH_TOKEN
BEARER_TOKEN=`curl -K -i -H 'Authorization: Basic '"$PASS_ENC"'' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST $IDCS_TOKEN_URL -d 'grant_type=refresh_token&refresh_token='"$REFRESH_TOKEN"`
cp mytoken mytoken.old
DEVICE_INFO=`curl -K -i -H 'Authorization: Basic '"$PASS_ENC"'' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST $IDCS_DEVICE_URL -d 'response_type=device_code&'"$CLIENT_ID"`
DEVICE_CODE=`echo $DEVICE_INFO | jq '.device_code'|tr -d '"'`
echo identified DEVICE_CODE $DEVICE_CODE press enter when done
BEARER_TOKEN=`curl -K -i -H 'Authorization: Basic '"$PASS_ENC"'' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' --request POST $IDCS_TOKEN_URL -d 'grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code='"$DEVICE_CODE"`

echo $BEARER_TOKEN > mytoken
ACCESS_TOKEN=`echo $BEARER_TOKEN| jq '.access_token'| tr -d '"'`

# call the rest api to get shapes

curl -k -X GET $CLOUDMGR_URL/ebs/shapes/networkProfile/MY_AD2 -H 'Authorization: Bearer '"$ACCESS_TOKEN"''

First running the script

When you call this script for the first time, it gives an output as follows:


identified DEVICE_CODE 483150ce7704487da495593d1c97c2a4 press enter when done

Just open the verification URI provided in a browser, sign in to IDCS and pass the user_code CTHJNLAM.

Then, return to the shell script and press return. This will allow the script to get a Bearer Token including a Refresh token.

Subsequent runs

On every subsequent run, the "previous" refresh token (stored in the file mytoken) is exchanged for an access token and a new refresh token. That new refresh token is saved (each refresh token is a one-time-use token) and can then be used for the next run.

Using the access token we received through that way, we can conveniently access the Cloud Manager APIs.


With the above way, you can get a token that is valid for at least a week. For most operations this should be sufficient; if not, these timings can be extended in IDCS. See for more details on that (OAuth Refresh Token Expiry).

The combination of the procedure described in this and the previous blog post allow a simple and complete end-to-end automation of clones - e.g. on a nightly basis.

21.-24.11.2023 | DOAG 2023 Konferenz + Ausstellung

21.-24.11.2023 | DOAG 2023 Konferenz + Ausstellung

4-fach geballte PROMATIS Power

Die DOAG 2023 Konferenz + Ausstellung findet vom 21. bis 24. November im Nürnberg Convention Center (NCC) statt und präsentiert erneut ein breitgefächertes Konferenzprogramm zu den neuesten Trends im Oracle-Umfeld. Rund 400 Vorträge sorgen für neue Impulse und Wissen pur – hochkarätige Keynotes, wertvolle Tipps & Tricks, Demos, Best Practices und moderne Networking-Elemente runden das Konferenz-Highlight der deutschsprachigen Oracle Community optimal ab.


21. bis 24.11.2023
Nürnberg Convention Center (NCC)

Den Auftakt der viertägigen Anwenderkonferenz markiert am Dienstag ein Thementag, um tief in nur ein Thema einzutauchen. Am Mittwoch und Donnerstag können Sie sich auf zwei klassische Konferenztage mit Sessions in den vier Streams Datenbank & Infrastruktur, Development & Middleware, Strategie & Softskills und Data Analytics & KI freuen.

PROMATIS ist mit folgenden Beiträgen am Start:

  • OCI für Anfänger Teil 1 – Grundlagen (Thementag der DOAG Infrastructure & Middleware Community)
    Dienstag 21.11.2023 | 09:00 - 09:45 | Raum: Neu-Delhi
  • Oracle Database Service for Azure (Teil 2 Thementag)
    Dienstag, 21.11.2023 | 15:00 – 15:45 | Raum Neu-Delhi
  • PROMATIS goes digital – mit Oracle APEX im Gepäck
    Donnerstag 23.11.2023 | 11:00 - 11:45 | Raum: Istanbul
  • Von Druckerpresse zur Cloud – Hyperion Essbase Ablösung bei Saarbrücker Zeitung
    Donnerstag 23.11.2023 | 09:00 - 09:45 | Raum: Helsinki

Weitere Informationen zur DOAG 2023 Konferenz + Ausstellung finden Sie hier.

PROMATIS erhält Zertifikat: Expertise in Oracle E-Business Suite Applications to Oracle Cloud in Western Europe

PROMATIS erhält Zertifikat: Expertise in Oracle E-Business Suite Applications to Oracle Cloud in Western Europe

Wir freuen uns, Ihnen mitteilen zu können, dass wir die Service-Expertise für Oracle E-Business Suite Applications to Oracle Cloud in Westeuropa erhalten haben. Dies ist ein weiterer Beweis für unser Engagement, ganzheitliche und nahtlose Oracle Cloud-Implementierungen anzubieten.

Diese Auszeichnung zeugt nicht nur von unserem hohen Kompetenzniveau in Bezug auf Oracle E-Business Suite, sondern sie bestätigt auch die Zufriedenheit unserer Kundschaft.

Die Expertise Initiative wurde von Oracle ins Leben gerufen, um die speziellen Fähigkeiten von Oracle-Partnerunternehmen transparenter zu gestalten. Um die Zertifizierung zu erhalten, muss ein Oracle-Partnerunternehmen strenge Kriterien erfüllen: Die Anforderungen umfassen zum einen, dass genügend zertifizierte Consultants im Unternehmen zur Verfügung stehen, zum anderen müssen auch entsprechende Kundenreferenzen vorgelegt werden, welche die eigenen Projekterfolge für das jeweilige Fokusfeld bestätigen.

Unia entscheidet sich für Oracle Fusion Cloud-Anwendungen & Partner PROMATIS!

Unia, die grösste Gewerkschaft der Schweiz, hat sich für die Oracle Fusion Cloud Applications Suite entschieden, um ihre Betriebsabläufe effizienter zu gestalten. Wir freuen uns sehr, die komplexen Herausforderungen im einjährigen Auswahlprozess gemeistert zu haben, unterstützend durch unsere vertrauensvolle Zusammenarbeit. Denn für die Umsetzung wünschte sich Unia einen kompetenten und zuverlässigen Partner, der die Prozesse kennt und weiß, wie man mit der notwendigen Technologie umgeht. Gerade die Ansprüche im Mitgliederbereich der Unia waren besonders hoch und konnten durch unsere Vorgehensweise und Lösung erfüllt werden.

Lesen Sie hier den kompletten Artikel.