NeXtMidas User's Guide: RHEL 8+ FIPS Security

RHEL 8+ FIPS Security

NeXtMidas SSL/TLS communication is FIPS compliant, as NeXtMidas defaults to TLS 1.2

NeXtMidas uses the underlying Java tools libraries for JAR signing and validation. OpenJDK 8 libraries are not FIPS compliant. JDK 17+ libraries are FIPS compliant. In order to allow users to continue to build with JDK 8, NeXtMidas now offers the following options when a JDK 8 build is detected:

Default operation: When built with lower JDKs, NeXtMidas will work around an OS with FIPS enabled by disabling FIPS only at the JVM level. The OS setting remains and TLS communication is still FIPS compliant. The JAR signing and PKI certificate validation operations will not be FIPS compliant
User's can set a JAVATOOLSHOME system environmental variable that is distinct from their JAVAHOME

The NeXtMidas code will build with the JDK specified in JAVAHOME, so users can continue to build NXM and their option trees with lower JDKs
With this option, the JAVATOOLSHOME should be set to JDK 17+, so that the JAR sigining that occurs during the NXM build is successful

User's can also choose to force NeXtMidas to remain fully FIPS compliant, even with lower JDKs, by setting NM_USER_JVM_FLAGS to include -Dcom.redhat.fips=true and -Dredhat.crypto-policies=true. This option will cause the NXM jar signing part of the build to fail, but the build is still operational with the exception of it TLS/SSL libraries and jar signing capability.

A few notes when building NeXtMidas with Gradle:

JVM args can be passed into the Gradle command directly
If NeXtMidas is built with Gradle using SSL/PKI certificates, the Gradle build will fail since the PKI certificate validations will not be FIPS compliant. This is regardless of -Dcom.redhat.fips, -Dredhat.crypto-policies and JAVATOOLSHOME. To work around this, either switch to using JDK > 21 or switch to using local dependencies (instead of pulling dependencies from maven).
If the NeXtMidas unit tests are run as part of a Gradle build, there is a separate JVM that gets "forked" off of the current process and the unit tests run in this "forked" test JVM. The JVM args in the main Gradle process will not all be passed into this "forked" test JVM by default. This is regardless of building with SSL/PKI certificates or local dependencies. To work around this, the gradle property testProps needs to be set. This will contain a list of names of JVM properties to be passed into the "forked" test JVM (i.e. gradle -PtestProps="com.redhat.fips" or testProps="com.redhat.fips" in gradle.properties).

Current Page: NeXtMidas User's Guide Security and Secure Communication RHEL 8+ FIPS Security
- FAQs - Release Information - Getting Help + Basic Concepts + Result Parameters - JSON Support - XML Support + Files + System Operation + Macros + Java WebStart + Graphics + X-Midas Interoperability + Third-Party Compatibility + Build/Installation Options and Customization - Running NeXtMidas Independently - WebVNC to deploy NeXtMidas as a Web App - Security and Secure Communication - Secure Communication Using TLS and PKI - RHEL 8+ FIPS Security - Timelines - Keywords, Updating, Known Issues + Installing and Using Docker + Glossary	RHEL 8+ FIPS Security NeXtMidas SSL/TLS communication is FIPS compliant, as NeXtMidas defaults to TLS 1.2 NeXtMidas uses the underlying Java tools libraries for JAR signing and validation. OpenJDK 8 libraries are not FIPS compliant. JDK 17+ libraries are FIPS compliant. In order to allow users to continue to build with JDK 8, NeXtMidas now offers the following options when a JDK 8 build is detected: Default operation: When built with lower JDKs, NeXtMidas will work around an OS with FIPS enabled by disabling FIPS only at the JVM level. The OS setting remains and TLS communication is still FIPS compliant. The JAR signing and PKI certificate validation operations will not be FIPS compliant User's can set a JAVATOOLSHOME system environmental variable that is distinct from their JAVAHOME The NeXtMidas code will build with the JDK specified in JAVAHOME, so users can continue to build NXM and their option trees with lower JDKs With this option, the JAVATOOLSHOME should be set to JDK 17+, so that the JAR sigining that occurs during the NXM build is successful User's can also choose to force NeXtMidas to remain fully FIPS compliant, even with lower JDKs, by setting NM_USER_JVM_FLAGS to include -Dcom.redhat.fips=true and -Dredhat.crypto-policies=true. This option will cause the NXM jar signing part of the build to fail, but the build is still operational with the exception of it TLS/SSL libraries and jar signing capability. A few notes when building NeXtMidas with Gradle: JVM args can be passed into the Gradle command directly If NeXtMidas is built with Gradle using SSL/PKI certificates, the Gradle build will fail since the PKI certificate validations will not be FIPS compliant. This is regardless of -Dcom.redhat.fips, -Dredhat.crypto-policies and JAVATOOLSHOME. To work around this, either switch to using JDK > 21 or switch to using local dependencies (instead of pulling dependencies from maven). If the NeXtMidas unit tests are run as part of a Gradle build, there is a separate JVM that gets "forked" off of the current process and the unit tests run in this "forked" test JVM. The JVM args in the main Gradle process will not all be passed into this "forked" test JVM by default. This is regardless of building with SSL/PKI certificates or local dependencies. To work around this, the gradle property testProps needs to be set. This will contain a list of names of JVM properties to be passed into the "forked" test JVM (i.e. gradle -PtestProps="com.redhat.fips" or testProps="com.redhat.fips" in gradle.properties).