Not able to enable FIPS for Liberty with Semeru Java 11 or 17 deployed with WLO

[mtamboli]

Enabling FIPS for Liberty requires to use NSS tool to import keys and certificates from a PKCS#12 keystore file into the NSS database. User does not control the default keystore for Liberty container deployed with WLO. So it is not possible to enable FIPS for the Liberty application when using Semeru Java 11 or 17.

I followed docs to configure FIPS for Liberty.

• I updated Containerfile
  To install NSS and tools RUN dnf -y install nss && dnf -y install nss-tools

• Update jvm.options

-Dsemeru.fips=true 
-Djava.security.debug=semerufips
-Djavax.net.debug=all 

• Load keystore to NSS Database

pk12util -i keystore.p12 -W changeit -d /etc/pki/nssdb
pk12util -i truststore.p12 -W changeit -d /etc/pki/nssdb

[leochr]

The keystore and trustore would have to be created externally and imported into the Liberty container. Once we have a clear understanding of the process, we could potentially look into generating them as part of the Liberty container image if possible.

@idlewis The issue I mentioned in the scrum is WASdev/ci.docker#493. A stack product managed to import their custom keystore/truststore (although it required a workaround for the default keystore, which should no longer be required once the changes for OpenLiberty/ci.docker#427 is merged).

[idlewis]

Assuming that you already have TLS certificate/private key files, you can create a key.p12 file in the container build with a command similar to:
openssl pkcs12 -export -name "default" -inkey "tls.key" -in "tls.crt" -out "key.p12" -password pass:changeit
You should then be able to run the pk12util command to add the key.p12 to the NSS database. NB. I believe the pk12util command needs to be run as root in the container build, you may need to add a 'USER' directive in the Dockerfile

You would also need to add keystore config to the liberty server.xml as part of the docker build. Example 3 from this page
https://www.ibm.com/support/pages/node/6612693
describes the necessary config.

When deploying the application using the operator, I think you would also need to set .spec.manageTLS=false in the CR.

[leochr]

@mtamboli please refer to the information above. We hope that it unblocks you and allows you to proceed with testing Liberty in containers with Semeru + FIPS.

At this time we neither provide (nor claim to do) any FIPS support within Liberty container images and/or Operator. We plan to investigate what can be done at the Liberty container and Operator layers for a better user experience. Please share your feedback once your testing is completed. Thank you.

[leochr]

@mtamboli Did you/your team have a chance to try the above? Please share feedback. We would like to plan for native FIPS support within Liberty container and/or Operator and are interested on SVT feedback.

[mtamboli]

@leochr I will look at this again and get back to you soon.

[mtamboli]

Assuming that you already have TLS certificate/private key files, you can create a key.p12 file in the container build with a command similar to: openssl pkcs12 -export -name "default" -inkey "tls.key" -in "tls.crt" -out "key.p12" -password pass:changeit You should then be able to run the pk12util command to add the key.p12 to the NSS database. NB. I believe the pk12util command needs to be run as root in the container build, you may need to add a 'USER' directive in the Dockerfile

You would also need to add keystore config to the liberty server.xml as part of the docker build. Example 3 from this page https://www.ibm.com/support/pages/node/6612693 describes the necessary config.

When deploying the application using the operator, I think you would also need to set .spec.manageTLS=false in the CR.

@idlewis @leochr are you suggesting that I create tls.crt and tls.key files locally and copy them to my container with other config files and build the key.p12 as part of the building container image? would that be acceptable from security perspective?

[mtamboli]

Can you please provide me high level (valid scenario you expect to work) steps which you expect to work and I will be happy to try it out?

[idlewis]

@idlewis @leochr are you suggesting that I create tls.crt and tls.key files locally and copy them to my container with other config files and build the key.p12 as part of the building container image? would that be acceptable from security perspective?

@mtamboli Yes, that is what I was suggesting. It is not ideal from a security perspective, as the container image would contain the keystore, but until the operator has direct support for enabling FIPS, I'm not sure there is a better option.
I'll add another update with details of a scenario for you try.

[idlewis]

@mtamboli I've created a new git repo with some sample files that should build a liberty docker container that will run with FIPS support here:
https://github.com/idlewis/liberty-fips
I could successfully run a curl command against this container e.g.
curl -k -u 'bob-admin:bob-pwd' https://localhost:9443/IBMJMXConnectorREST
Please note that the certificate and key files are randomly generated and self signed, so do not contain any sensitive info

To run this container with the Liberty operator in OCP, I think all you would need to do is:

1. Build and push the container to an accessible registry
2. Ensure that the CR definition for the operator has .spec.manageTLS=false, and port 9443 exposed via a service.

Hope that helps.

[mtamboli]

@idlewis I will take a look and give it a try.
Do you and @leochr think this is something we can recommend to customer if they wish to enable FIPS for containers? If we have to create a blog on this, would these steps be ok to mention?