After deploying or restarting the CA-NIM-SM (Normalization Integration Management) application on the Spectrum Tomcat server, the NIM web page fails to load. Deleting the $SPECROOT/tomcat/webapps/ca-nim-sm directory and restarting the Tomcat service does not resolve the issue.
Reviewing the application logs (e.g., Nim.log or Tomcat's catalina.out) reveals the following fatal crash during the application startup sequence:
ERROR common.NIMServletContextListener: Not able to Decrypt : Sealing violation loading org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider : Package org.bouncycastle.jcajce.provider is sealed. java.lang.SecurityException: Sealing violation loading org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider : Package org.bouncycastle.jcajce.provider is sealed.
DX NetOps Spectrum: 24.3.12
Application: CA-NIM-SM Version 3.3.x (and similar)
Web Server: Apache Tomcat (Embedded in Spectrum)
The issue is caused by a Java classloading conflict involving the Bouncy Castle cryptography libraries.
For security compliance (such as FIPS), Bouncy Castle distribution files utilize Java's "Package Sealing" feature. This feature mandates that all classes within the Bouncy Castle security package must be loaded from a single .jar file.
If Tomcat discovers multiple Bouncy Castle JAR files across its global and local application classpaths, it attempts to load the same sealed package twice. This triggers Java's core security engine to throw a java.lang.SecurityException: Sealing violation and halt the application deployment.
This typically occurs when the following two files co-exist:
Global Tomcat Library: $SPECROOT/tomcat/lib/bcFIPS.jar
Local NIM Library: $SPECROOT/tomcat/webapps/ca-nim-sm/WEB-INF/lib/bc-fips-2.0.0.jar
(Note: Depending on server environment variables, startup load order, or OS-level inode reading order, this conflict might not manifest consistently across all servers, even with identical file structures. However, having duplicate sealed libraries is an unsupported configuration).
To resolve the sealing violation, you must ensure that Tomcat only loads a single instance of the Bouncy Castle provider. Since other Spectrum applications may rely on the global library, the safest approach is to remove the duplicate library from the specific NIM web application folder.
Step-by-Step Fix:
Stop the Tomcat Service: Ensure the Tomcat process is fully shut down so no .jar files are locked by the system.
Locate the Conflicting File: Verify the presence of the duplicate .jar in the NIM deployment directory.
ls -l /opt/spectrum/tomcat/webapps/ca-nim-sm/WEB-INF/lib/bc*.jar
Move/Backup the Conflicting File: Move the duplicate Bouncy Castle file out of the Tomcat directory entirely (e.g., to a temporary backup folder).
mv /opt/spectrum/tomcat/webapps/ca-nim-sm/WEB-INF/lib/bc-fips-2.0.0.jar /opt/spectrum/install/tmp/
Restart the Tomcat Service: Boot the Tomcat service back up. NIM will now seamlessly fall back to using the global bcFIPS.jar located in tomcat/lib/, satisfying the dependency without causing a package sealing violation.
Verify: Access the NIM web page to confirm normal operation.