Workaround unknown SecureRandom strong algorithm with OpenJDK17 & RHEL & BCFIPS provider when run in FIPS-enabled environment

[michalvavrik]

fixes: #40659

When run on RHEL8 with Open JDK 17 with BCFIPS provider the SecureRandom strong algorithm is NativePRNGBlocking:SUN,DRBG:SUN, algorithms that are not available.
Keycloak works around that by just initializing default SecureRandom with known strong algorithms (PKCS11:SunPKCS11-NSS-FIPS) and removing them, but that means that when Vert.x loads keystores during the HTTP Server startup (when users can't provide their fixes, before app starts) and org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider#getCoreSecureRandom is invoked while getInstanceStrong throws exception, it leads to initializing org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.CoreSecureRandom#CoreSecureRandom with sun.security.provider.SecureRandom() and following exception is thrown BouncyCastleFipsProvider$CoreSecureRandom (in unnamed module @0x621a387f) cannot access class sun.security.provider.SecureRandom.

I've tried both using reflection to invoke org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider#getDefaultSecureRandom and initialize initialize SecureRandom instance via Java API, but BCFIPS require this strong algorithm later as well. I think we need to keep it in place.

My thinking (AKA selected code lines from KC) is that if NoSuchAlgorithmException is thrown, that won't change until user code is run on app startup (extensions could do something sooner). Which is too late, and if they want to change the strong algorithm, they can change what we set as well.

Tested only in JVM as native mode is not working #37500.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit da0a2cd.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[sberyozkin]

I've read the description of the problem in the BC project, this fix/workaround LGTM, same as in Keycloak, thanks @michalvavrik