Let's say the following is in the HPEL or SystemOut log when attempting to start your WebSphere network deployment manager (dmgr), node, or application server.

[2/23/22 6:42:55:669 CST] 00000001 ContainerHelp E   WSVR0501E: Error creating component null [class com.ibm.ws.runtime.component.ORBImpl]
Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers!

This can occur when Java includes the local_policy.jar and US_export_policy.jar files. If you are not familiar with how WebSphere integrates with Java, refer to Getting Started with Java on WebSphere.

The imcl (Installation Manager command line tool) command with the listInstalledPackages -long option can be used to list the packages that have been installed. In this example, the imcl command is located at /opt/IBM/InstallationManager/eclipse/tools/imcl on a Linux system, but you may have the imcl command located at some other directory. In this example, Java version 8.0.6.25 is installed.

IMPORTANT

With versions 9 of WebSphere, Java is installed as it's own package.

With version 8 of WebSphere, Java is included in the BASE or ND (network deploy) package, thus with version 8 of WebSphere, you typically will not see a Java package.

~]# /opt/IBM/InstallationManager/eclipse/tools/imcl listInstalledPackages -long
/opt/WebSphere/AppServer : com.ibm.java.jdk.v8_8.0.6025.20210115_1050 : IBM SDK, Java Technology Edition, Version 8 : 8.0.6.25
/opt/WebSphere/AppServer : com.ibm.websphere.ND.v90_9.0.5007.20210301_1241 : IBM WebSphere Application Server Network Deployment  : 9.0.5.7

And the managesdk -listAvailable command can be used to see that the base Java directory is ${WAS_INSTALL_ROOT}/java, which is /opt/WebSphere/AppServer/java in this example.

~]# ${WAS_INSTALL_ROOT}/bin/managesdk.sh -listAvailable -verbose
CWSDK1003I: Available SDKs :
CWSDK1005I: SDK name: 1.8_64
 - com.ibm.websphere.sdk.location.1.8_64=${WAS_INSTALL_ROOT}/java

The find command (on a Linux system) can be used to determine if the local_policy.jar and US_export_policy.jar files exist below the ${WAS_INSTALL_ROOT}/java directory.

~]$ find /opt/WebSphere/AppServer/java | egrep -i 'local_policy.jar|US_export_policy.jar'
/opt/WebSphere/AppServer/java/jre/lib/security/local_policy.jar
/opt/WebSphere/AppServer/java/jre/lib/security/US_export_policy.jar

if the local_policy.jar and US_export_policy.jar files exist below the ${WAS_INSTALL_ROOT}/java directory, the mv command (on a Linux system) can be used to rename the files.

cd /opt/WebSphere/AppServer/java/jre/lib/security
mv local_policy.jar local_policy.jar.disabled
mv US_export_policy.jar US_export_policy.jar.disabled

You can now try to start your WebSphere network deployment manager (dmgr), node, or application server to see if renaming local_policy.jar and US_export_policy.jar files resolves the startup issue.