Kafka startup failure with FIPS compliant openssl

[achawki]

We are running Strimzi (0.42.0) + components and building our own images based on a debian base image where openssl is installed with the fips provider:

openssl list -providers
Providers:
  default
    name: OpenSSL Default Provider
    version: 3.4.1
    status: active
  fips
    name: OpenSSL FIPS Provider
    version: 3.4.1
    status: active

Multiple components will fail on startup, e.g. Zookeeper:

[...]
Preparing keystore for client and quorum listeners
Error creating PKCS12 MAC; no PKCS12KDF support?
Use -nomac or -pbmac1_pbkdf2 if PKCS12KDF support not available
402772F6827F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:355:Global default library context, Algorithm (PKCS12KDF : 235), Properties (<null>)
402772F6827F0000:error:1180006B:PKCS12 routines:pkcs12_gen_mac:key gen error:../crypto/pkcs12/p12_mutl.c:267:
402772F6827F0000:error:1180006D:PKCS12 routines:PKCS12_set_mac:mac generation error:../crypto/pkcs12/p12_mutl.c:365:

This also affects other components.
The reason for this is the shared script tls_utils.sh#L33 which is used to create the keystore:

openssl pkcs12 -export ...

The command above from the script will fail on a FIPS compliant openssl installation since pkcs12 will by default use PKCS12KDF as MAC generation.
PKCS12KDF is not FIPS approved.
Alternatives would be -pbmac1_pbkdf2 or -nomac to skip the MAC generation (https://docs.openssl.org/3.5/man1/openssl-pkcs12/#pkcs12-output-export-options):

Do not attempt to provide the MAC integrity. This can be useful with the FIPS provider as the PKCS12 MAC requires PKCS12KDF which is not an approved FIPS algorithm and cannot be supported by the FIPS provider.

There is RFC#9579 to integrate PBMAC1 into PKCS12 and make it default when using the FIPS provider, but this is not reflected in openssl as of now.

This can reproduced also without the Strimzi operator, just by calling the corresponding line:

openssl req -x509 -nodes -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -subj "/CN=localhost"
openssl pkcs12   -export -in cert.pem -inkey key.pem -out test.p12 -passout pass:test
# => will fail on openssl with fips provider

So my question would be, is that an expected behaviour and FIPS for Strimzi applies only to runtime and not the keystore creation itself? Or am I missing potentially something?

Thanks in advance!

[scholzj]

I'm not sure I follow what exactly is the question TBH. Strimzi is developed, tested, and released with Red Hat UBI base images. If you create a fork that is based on Debian, it would be expected that you would need to do some things differently as that is pretty major change.

Also - as a sidenote - your reproducer commands do not seem to be what Strimzi is using as we have there bunch of additional parameters that were added there exactly for the purpose of making the command work in FIPS environments.

[achawki]

Thanks for the prompt reply!

Basically our goal is not just to run Strimzi in FIPS_MODE but also to have the underlying base image fips compliant.

If you create a fork that is based on Debian, it would be expected that you would need to do some things differently as that is pretty major change.

That is indeed true.

your reproducer commands do not seem to be what Strimzi is using as we have there bunch of additional parameters that were added there exactly for the purpose of making the command work in FIPS environments.

I indeed omitted the additional flags. According to my understanding the call with all flags would use PKCS12KDF for the MAC in openssl 3.x.x version (which is not fips approved).
-macalg would change the digest algorithm for the MAC but not the MAC derivation itself.

openssl pkcs12 -export -in "$3" -inkey "$4" -chain -CAfile "$5" -name "$6" -password pass:"$2" -out "$1" -certpbe aes-128-cbc -keypbe aes-128-cbc -macalg sha256

Some more context on openssl side: openssl/openssl#24546 and openssl/openssl#19997