Unless one changes default configuration, starting catalina in a fips-enabled machine with jdk-17 print 2 SEVERE errors in catalina.out per context initialized. The messages are generated in SessionIdGeneratorBase.java, and are caused by the fact that SHA1PRNG is missing in jdk-17. The messages are confusing, but harmless. The class will use the default SecureRandom (PKCS11) when SHA1PRNG is not found. Workaround: * For webapps that don't define a '<Context><Manager>', one can add '<Manager secureRandomAlgorithm=""/>' to conf/context.xml. This works for ROOT and examples in a default install * For webapps that define a '<Context><Manager>', set 'secureRandomAlgorithm=""' in META-INF/context.xml This works for manager and host-manager in a default install. The log spam could be managed by checking on initialization of the class if the initial value works, and special-casing it from SHA1PRNG to "" (maybe printing a warning) in case it doesn't. Also, I think the messages should be scaled down from SEVERE to INFO when the secureRandomAlgorithm value is SHA1PRNG, FIPS is enabled and the java version is jdk-17.
If Tomcat could determine that FIPS is enabled then it could switch to "" without even trying SHA1PRNG first. Unfortunately, I don't see a way to do that as FIPS support isn't part of the standard JRE (that also makes testing any solution tricky). I think testing SHA1PRNG on class init is the way to go. Logging at SEVERE seemed reasonable originally as SHA1PRNG should always be supported but if FIPS changes that then a single WARNING does seem more appropriate.
Fixed in: - 10.1.x for 10.1.0-M11 onwards - 10.0.x for 10.0.17 onwards - 9.0.x for 9.0.59 onwards - 8.5.x for 8.5.76 onwards Tomcat now falls back to the platform default with a single log message at WARNING level if the default (SHA1PRNG) is not available. Explicit configuration of SHA1PRNG when it is not available will now trigger one SEVERE log message per web application.