https://issues.apache.org/bugzilla/show_bug.cgi?id=56027
--- Comment #4 from Rob Sanders <rsand...@trustedcs.com> --- Looking at the openssl source for my box a double call to FIPS_mode_set to *enable* FIPS triggers an error - including setting the internal fips_selftest_fail flag to 1 indicating a failure. Understood on the severity change - somewhat surprised that I can't find any real reports of this failure in general web searches or on RH's pages. Some additional comments... Looking for a boot entry does appear to be a RHEL 'addition', but the source also indicates you can set an environment variable to accomplish the same thing (OPENSSL_FORCE_FIPS_MODE). This is in the source code of crypto/o_init.c (after applying RH patches). The /proc/sys/crypto/fips_enabled trigger file is checked in this file also. Looking deeper at the AprLifecycleListener initializeSSL code it does call the TCN SSL.initialize code, which drops down into some of the openssl calls that look like bounce through the various init routines including the code in o_init.c that does the FIPS startup. So *if* the underlying platform has the fs/env check a call to FIPS_Mode() prior to calling FIPS_mode_set() in TCN fipsModeSet() should detect this. Proposed fix - in TCN src/ssl.c fipsModeSet() routine, call FIPS_mode() before calling FIPS_mode_set() to see if we're already in fips mode. If so, just return 1, otherwise attempt to set to FIPS mode. There is no way that I know of to get an intelligent message back through the JNI without other changes, so if a status messages of "Already in FIPS mode" would be desirable the FIPS_mode() routine will need to be exposed through JNI and checked from the AprLifecycleListener code before calling fipsModeSet. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
