KeyStoreKeyManager doesn't expose alternative KeyStore loading mechanisms.

[trixpan]

The SDK seems to have an inconsistency where although a external provider may be added to FIPS mode via

"com.unboundid.crypto.ALLOWED_FIPS_MODE_PROVIDER"

(or equivalent call)

There's no way of making use of it via KeyStoreKeyManager

The issue seems to be that KeyStoreKeyManager doesn't expose a method to invoke

  public static KeyStore getKeyStore(@NotNull final String keyStoreType,
                                     @Nullable final Provider provider,
                                     final boolean allowNonFIPSInFIPSMode)

as implemented here:

ldapsdk/src/com/unboundid/util/CryptoHelper.java

Line 1493 in 47164c5

public static KeyStore getKeyStore(@NotNull final String keyStoreType,

Instead it seems to invoke

  public static KeyStore getKeyStore(@NotNull final String keyStoreType)

as seen here:

ldapsdk/src/com/unboundid/util/ssl/KeyStoreKeyManager.java

Line 351 in 47164c5

final KeyStore ks = CryptoHelper.getKeyStore(type);

[trixpan]

@dirmgr the context here is:

We currently use Ping in FIPS environments using a custom JCE implementation. Using SSLUtil seems the cleaner way of linking that with the JDK, however, when running in FIPS we hit hiccups due to the format of the keystore being denied use (despite already being loaded and added to the allowed FIPS providers)

[dirmgr]

I've just committed a set of changes that should make this possible. I've added new KeyStoreKeyManagerProperties and TrustStoreTrustManagerProperties classes that you can use to specify a variety of properties to use when creating the associated key or trust manager, and these new properties files include the ability to set a Provider and the allowNonFIPSInFIPSMode property.

Could you please test this to see if it works for you?

[trixpan]

@dirmgr I will test. Is the code published or should I compile the JDK locally?

I had managed to unblock myself by creating a local reimplementation of the relevant class and that lead me to another issue that seems a bit more obscure.

Running code with the RHEL9 OpenJDK in FIPS mode seems to cause mTLS connections to fail while a similar connection, made with pure JNDI (gosh, that framework is horrendous), seems to work.

I will open another bug with the relevant information and sample code.

[dirmgr]

You will need to check out and build the LDAP SDK for yourself to test the changes I've made for this issue. To do that, just use:

git clone https://github.com/pingidentity/ldapsdk.git

And then run build.sh (if you're on a UNIX-based system) or build.bat (if you're on Windows) with the JAVA_HOME environment variable set to the path of a Java 8 installation. The resulting build/package/unboundid-ldapsdk-7.0.1/unboundid-ldapsdk.jar will contain the entirety of the LDAP SDK content that you need to include in your application.

I don't know why mTLS attempts would fail when using the LDAP SDK but not with JNDI. If you can provide the exception that you're getting, that would probably help, but it might also help to have debugging output from the attempt with the "javax.net.debug" system property set to "all" (you'll need to set that very early in the life of your application, before any attempt to perform network communication).

We've tested the ability to use mTLS and SASL EXTERNAL authentication when running in FIPS-compliant mode, albeit only with the Bouncy Castle BCFIPS library. If you're using a different provider, then it's possible that the LDAP SDK's current FIPS-compliant mode isn't suitable for use with that provider, and in that case, it might be more appropriate to not attempt to use the LDAP SDK in FIPS-compliant mode. When using the Bouncy Castle BCFIPS library, running in FIPS-compliant mode ensures that the necessary providers are loaded, that other providers are unloaded, and that the BCFIPS provider is used when performing nearly all cryptographic operations (with certain exceptions for things that it doesn't handle, like interacting with a PKCS11 token). If you're using a different provider, and if you've prioritized it appropriately in the JVM configuration and unloaded other undesirable providers, then it may be better to not attempt to use the LDAP SDK in FIPS-compliant mode and rely on the JVM configuration to ensure that your provider is used for all appropriate cryptographic processing. The use of FIPS-compliant mode in the LDAP SDK does not directly influence the selection of cryptographic algorithms that the LDAP SDK attempts to use; we rely on the provider to only expose the algorithms that are appropriate for use.