Cxf-soap tests fail in FIPS environment (fix for JVM)

[JiriOndrusek]

fixes https://github.com/apache/camel-quarkus/issues/5482

[JiriOndrusek]

Native failure has to be investigated further, reported as https://github.com/apache/camel-quarkus/issues/5486

[JiriOndrusek]

All certficates and keystores have to be generated via openssl to work correctly in the FIPS, therefore I removed the keytool-plugin and added a description, how to generate certificates.

I found several bad passwords in the callbacks and fixed them (I'm not sure why it was working in non-FIPS environment - probably the passwords were not required by the cxf in non-FIPS) .

For the FIPS-enabled environment, the profile fips has to be used. The reason is that the BC-FIPS is used instead of the BC

[jamesnetherton]

For the FIPS-enabled environment, the profile fips has to be used. The reason is that the BC-FIPS is used instead of the BC

The fips Maven profile has:

<properties>
    <security.procide>quarkus.security.security-providers=BCFIPS</security.procide>
</properties>

What does that do?

[JiriOndrusek]

Sorry I forgot to remove it on all places. It shouldn'tbe there

[JiriOndrusek]

For the FIPS-enabled environment, the profile fips has to be used. The reason is that the BC-FIPS is used instead of the BC

The fips Maven profile has:

<properties>
    <security.procide>quarkus.security.security-providers=BCFIPS</security.procide>
</properties>

What does that do?

Removed. Thanks for noticing!

[aldettinger]

It looks good.

So we configure openssl with the .cnf configuration file. Is it need for fips purpose ? Or something else please ?

[ppalaga]

Great work, thanks for taking care, @JiriOndrusek!

All certficates and keystores have to be generated via openssl

Do you happen to know what aspect of the generated keystore is not FIPS-compliant with keytool-maven-plugin? At the first sight, the plugin mojos seem to support all we need: keysize, keyalgorithm, storetype...

[JiriOndrusek]

Great work, thanks for taking care, @JiriOndrusek!

All certficates and keystores have to be generated via openssl

Do you happen to know what aspect of the generated keystore is not FIPS-compliant with keytool-maven-plugin? At the first sight, the plugin mojos seem to support all we need: keysize, keyalgorithm, storetype...

I probably mislead a little bit with my comment. It is possible to run successfully the keytool-maven-plugin, but I haven't found a way of generating such strong certificates to satisfy runtime in FIPS.

I remember seeing some not-supported algorithms for signing or similar, when I was trying to use keystore only. I don't remember the detail but will save them during investigation of other FIPS issues.

[JiriOndrusek]

It looks good.

So we configure openssl with the .cnf configuration file. Is it need for fips purpose ? Or something else please ?

TBH I'm using *.cnf mainly because the default values functionality (so user is not forced to fill all - e.g. CN which is "referenced" from the tests.) I'll look into an option with no *.cnf files in the future to be sure whether it is mandatory.

[JiriOndrusek]

There are 2 open issues:

• problem in the native (reported as https://github.com/apache/camel-quarkus/issues/5486) I'll investigate it .
• the option of not using BCFIPS in FIPS and use only SunPKCS11-NSS-FIPS provider. I think that it won't be possible, because quarkus-cxf-rt-ws-security brings BC as a transitive dependency, therefore requires BC. But I think that I'll discover the answer during investigation of the native failure. The native issue seems like a BC class is needed, when BC is replaced with BC-FIPS

[ppalaga]

Do you happen to know what aspect of the generated keystore is not FIPS-compliant with keytool-maven-plugin? At the first sight, the plugin mojos seem to support all we need: keysize, keyalgorithm, storetype...

I probably mislead a little bit with my comment. It is possible to run successfully the keytool-maven-plugin, but I haven't found a way of generating such strong certificates to satisfy runtime in FIPS.

I remember seeing some not-supported algorithms for signing or similar, when I was trying to use keystore only. I don't remember the detail but will save them during investigation of other FIPS issues.

This sounds like an answer: https://stackoverflow.com/a/50398011

PKCS#12 stores the private key encrypted with a password derived key. It looks like keytool uses pbeWithSHAAnd128BitRC2-CBC (pkcs-12PbeIds 5), an PBES1 algorithm for doing so. Even the keytool.exe of Oracle Java 9 does use this algorithm as you can verify by uploading a .p12 file to the online ASN.1 decoder decoding a sample PKCS#12 file.

If I read the PKCS#12 standard correctly PBES1 was long ago superseeded by the "newer" version of the key derivation system named "PBES2" (mostly PBKDF2 based) with should be used instead. But keytool does not make use of it. This is my interpretation of the error message.

Therefore the certificate and the key may be acceptable, but the PKCS#12 container is not acceptable. You may try to extract key and certificate and save them in a new PKCS#12 file using a current software like OpenSSL (or you simply generate the whole PKCS#12 file directly using OpenSSL).

[JiriOndrusek]

Do you happen to know what aspect of the generated keystore is not FIPS-compliant with keytool-maven-plugin? At the first sight, the plugin mojos seem to support all we need: keysize, keyalgorithm, storetype...

I probably mislead a little bit with my comment. It is possible to run successfully the keytool-maven-plugin, but I haven't found a way of generating such strong certificates to satisfy runtime in FIPS. I remember seeing some not-supported algorithms for signing or similar, when I was trying to use keystore only. I don't remember the detail but will save them during investigation of other FIPS issues.

This sounds like an answer: https://stackoverflow.com/a/50398011

PKCS#12 stores the private key encrypted with a password derived key. It looks like keytool uses pbeWithSHAAnd128BitRC2-CBC (pkcs-12PbeIds 5), an PBES1 algorithm for doing so. Even the keytool.exe of Oracle Java 9 does use this algorithm as you can verify by uploading a .p12 file to the online ASN.1 decoder decoding a sample PKCS#12 file. If I read the PKCS#12 standard correctly PBES1 was long ago superseeded by the "newer" version of the key derivation system named "PBES2" (mostly PBKDF2 based) with should be used instead. But keytool does not make use of it. This is my interpretation of the error message. Therefore the certificate and the key may be acceptable, but the PKCS#12 container is not acceptable. You may try to extract key and certificate and save them in a new PKCS#12 file using a current software like OpenSSL (or you simply generate the whole PKCS#12 file directly using OpenSSL).

Thanks for the explanation. I can confirm the behavior, as I tried JKS keystores at first, but they are not accepted by FIPS-enabled system. I had to move to PKCS12

[JiriOndrusek]

This PR is using BCFIPS, which is not the right call anymore. Once the following change is merged into cxf and leveraged by the CQ, this PR should be reworked.

[JiriOndrusek]

Superseeded by https://github.com/apache/camel-quarkus/pull/5980