When the current Java Code Signing file will expire in days, a big question is: if we do not renew it, will the EBS Forms still work as usual? From my experience, even the Java Signing cert expired, EBS Forms will continue functioning.
But, if a expired adkeystore.dat file is used to re-sign JAR files by adadmin (as a patching step, etc), the newly signed forms may be blocked by pop-up message in a "Java Application Blocked" box: Your security settings have blocked an application signed with an expired or not-yet-valid certificate from running.
In this case, you can go to Java console on local machine, Java >> Security >> Exception Site List >> add the EBS site URL. Then, you can open EBS GUI forms as a workaround.
When a wrong adkeystore.dat is used by adadmin to generate JAR files, EBS Forms will not open up by popup message:
JAR resources in JNLP file are not signed by same certificate
Also see Oracle Doc ID 2605947.1 (Forms Jar File Certificate Expiration and Timestamp Functionality).
Warning on JAR file when it closes to expiration:
$ jarsigner -verify -verbose -certs $AD_TOP/java/jar/adxlib.jar
... ...
Warning:
This jar contains entries whose signer certificate will expire within six months.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2022-01-12) or after any future revocation date.
Warning after expired:
$ jarsigner -verify -verbose -certs $AD_TOP/java/jar/adxlib.jar
... ...
Warning:
This jar contains entries whose signer certificate has expired.
Steps to renew Java Signing cert, if you have to:
1. I emailed the old adkeystore.dat file to a colleague in Security team. He emailed back the renewed file. He said he downloaded it from Venafi (Venafi Trust Protection Platform) site as JKS (.jks) file with the same old password, and then he renamed it to adkeystore.dat.
There is no need to create separate cert for each server. Code signing is the same for all servers but has a different alias. Key command to change the alias for another instance (e.g. from EBSDEV instance to EBSQA):
$ keytool -changealias -alias ebsdev_devNode1d -destalias EBSQA_qaNode1q -keystore adkeystore.dat
SQL> set serveroutput on -- pull out passwords
SQL> declare
spass varchar2(30);
kpass varchar2(30);
begin
ad_jar.get_jripasswords(spass, kpass);
dbms_output.put_line(spass);
dbms_output.put_line(kpass);
end;
/
puneet
myxuan
2. Copy the new cert file to $NE_BASE/EBSapps/appl/ad/admin (in R12.2)
$ cd $NE_BASE/EBSapps/appl/ad/admin
$ mv adkeystore.dat adkeystore.dat_OLD
$ keytool -list -keystore adkeystore.dat_OLD
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
ebsdev_devNode1d, Apr 5, 2019, PrivateKeyEntry, <== that is the file creation/modification date
Certificate fingerprint (SHA1): A7:01:6E:76:D7:2D:F5:69:8B:93:2B:C0:CA:E5:41:7C:DB:51:45:AA
$ keytool -list -keystore adkeystore.dat <== new file from renewal
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 3 entries <== new file could still say "1 entry". Not sure why
cn=digicert assured id root ca, ou=www.digicert.com, o=digicert inc, c=us, Jan 3, 2022, trustedCertEntry,
Certificate fingerprint (SHA1): 05:63:B8:63:0D:62:D7:5A:BB:C8:AB:1E:4B:DF:B5:A8:99:B2:4D:43
cn=digicert sha2 assured id code signing ca, ou=www.digicert.com, o=digicert inc, c=us, Jan 3, 2022, trustedCertEntry,
Certificate fingerprint (SHA1): 92:C1:58:8E:85:AF:22:01:CE:79:15:E8:53:8B:49:2F:60:5B:80:C6
ebsdev_devNode1d, Jan 3, 2022, PrivateKeyEntry,
Certificate fingerprint (SHA1): AF:78:49:69:75:3D:D8:6E:70:F9:74:69:42:BB:A9:19:6B:03:9D:E
Use "keytool -list -v -keystore adkeystore.dat" to see the keystore's validation period and other details.
3. Run command to change the alias for QA server:
$ keytool -changealias -alias ebsdev_devNode1d -destalias EBSQA_qaNode1q -keystore adkeystore.dat
Enter keystore password:
Enter key password for <ebsdev_devNode1d>
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 adkeystore.dat -destkeystore adkeystore.dat -deststoretype pkcs12".
$ keytool -list -keystore adkeystore.dat
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 3 entries
cn=digicert assured id root ca, ou=www.digicert.com, o=digicert inc, c=us, Jan 3, 2022, trustedCertEntry,
Certificate fingerprint (SHA1): 05:63:B8:63:0D:62:D7:5A:BB:C8:AB:1E:4B:DF:B5:A8:99:B2:4D:43
cn=digicert sha2 assured id code signing ca, ou=www.digicert.com, o=digicert inc, c=us, Jan 3, 2022, trustedCertEntry,
Certificate fingerprint (SHA1): 92:C1:58:8E:85:AF:22:01:CE:79:15:E8:53:8B:49:2F:60:5B:80:C6
ebsqa_qaNode1q, Jan 3, 2022, PrivateKeyEntry,
Certificate fingerprint (SHA1): AF:78:49:69:75:3D:D8:6E:70:F9:74:69:42:BB:A9:19:6B:03:9D:E
Extra steps (that may not be necessary):
$ cp -p adkeystore.dat adkeystore.dat_BK
$ keytool -importkeystore -srckeystore adkeystore.dat -destkeystore adkeystore.dat -deststoretype pkcs12
Enter source keystore password:
Entry for alias cn=digicert assured id root ca, ou=www.digicert.com, o=digicert inc, c=us successfully imported.
Enter key password for <ebsqa_qaNode1q>
Entry for alias ebsqa_qaNode1q successfully imported.
Entry for alias cn=digicert sha2 assured id code signing ca, ou=www.digicert.com, o=digicert inc, c=us successfully imported.
Import command completed: 3 entries successfully imported, 0 entries failed or cancelled
Warning:
<cn=digicert assured id root ca, ou=www.digicert.com, o=digicert inc, c=us> uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
Migrated "adkeystore.dat" to Non JKS/JCEKS. The JKS keystore is backed up as "adkeystore.dat.old".
$ ls -altr adkeystore.dat*
-rw-r----- 1 user users 4992 Apr 2 2019 adkeystore.dat_OLD
-rw-r--r-- 1 user users 7498 Mar 1 11:39 adkeystore.dat_BK
-rw-r--r-- 1 user users 7498 Mar 1 11:41 adkeystore.dat.old
-rw-r--r-- 1 user users 8721 Mar 1 11:41 adkeystore.dat
4. Make sure file adsign.txt is correct
$ more adsign.txt
EBSQA_qanode1q 1 CUST
5. Run adadmin to generate JAR files
$ adamin
==> 1 ==> 4
Do you wish to force regeneration of all jar files? [No] ? Yes
Forcing generation of all product jar files.
Creating and signing every jar file can take about thirty minutes depending on the hardware being used.
... ...
Generating customall.jar ...
Not creating customall.jar as no custom java directories found under JAVA_TOP.
customall.jar generated successfully.
** Updating appsborg.zip ...
Reading adjborg.txt...
adearea();
No files listed in $RUN_BASE/EBSapps/appl/admin/adjborg.txt
Ignoring ...
adjborg.txt file seems to be empty.
Done reading adjborg.txt.
As adjborg.txt file is empty, skipping the generation of appsborg.zip
** Updating appsborg2.zip ...
Reading adjborg2.txt...
adearea();
No files listed in $RUN_BASE/EBSapps/appl/admin/adjborg2.txt
Ignoring ...
adjborg.txt file seems to be empty.
Done reading adjborg2.txt.
As adjborg2.txt file is empty, skipping the generation of appsborg2.zip
6. Confirm the new expiration date
jarsigner -verify -verbose -certs $AD_TOP/java/jar/adxlib.jar
... ...
- Signed by "CN=Company_name, O=Company_name, L=City, ST=State_, C=US"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 4096-bit key
jar verified.
Warning:
This jar contains signatures that do not include a timestamp. Without a timestamp, users may not be able to validate this jar after any of the signer certificates expire (as early as 2024-04-05).
The signer certificate will expire on 2024-04-05.
7. Test the result by opening a few GUI forms.
It is not necessary to test the whole site.
No comments:
Post a Comment