Legacy Product

Fusion 5.4

Create a Java Keystore for Use with Fusion

Enterprise customers may want to use a signed certificate from an Enterprise Certificate Authority (CA), such as GoDaddy or Let’s Encrypt for their Fusion 5 deployment.

The Fusion 5 default setup will create a self-signed Java Keystore (JKS) file that is used as the JSON Web Token (JWT) signer.

The following instructions detail how to create the api-gateway.jks file using a CA signed certificate.

New installations

1. Create a JKS

Run the following command, replacing the dname(Distinguished Name) field with the name that matches your customer environment, and the keypass and storepass fields with a secure password.

This will create the api-gateway.jks:

keytool -genkeypair -keyalg rsa -keysize 2048 -validity 3650 -dname "CN=sample, OU=sample, O=sample, L=sample, S=sample, C=sample" -storetype jks -keystore api-gateway.jks -keypass password -storepass password -alias jwt-signer

If you change the alias or keystore/truststore passwords, you will need to update the api-gateway deployment YAML with the new values.

2. Create a Certificate Signing Request (CSR)

Run the following command to create a new fusion.csr, which will be sent to the CA:

keytool -keystore api-gateway.jks -certreq -alias jwt-signer -file fusion.csr

3. Send the CSR to your CA to get a signed certificate

The CA will return one of two possible responses:

  • A PKCS12 certificate file, such as CAreply.pkcs.

    This is a full keystore containing all the keys you need, including the root certificate and the signed chain certificate.

  • Several PEM files, such as 0000_cert.pem, 0000_chain.pem, and 0001_chain.pem.

    These files contain the root certificate, the chain certificate(s), and the signed chain certificate.

4. Import the signed certificate into the api-gateway.jks

  • If you received a PKCS file, import it using the following keytool command:

keytool -importcert -alias jwt-signer -file <CAreply.pkcs> -keystore api-gateway.jks -trustcacerts

  • If you receive PEM files, run the following commands to import the keys:

    • keytool -importcert -alias root -file 0000_cert.pem -keystore api-gateway.jks -trustcacerts

    • keytool -importcert -alias intermediate -file 0000_chain.pem -keystore api-gateway.jks -trustcacerts

    • keytool -importcert -alias jwt-signer -file 0001_chain.pem -keystore api-gateway.jks -trustcacerts

5. Upload the api-gateway.jks as a Kubernetes generic secret

The api-gateway service will pull down the api-gateway.jks file during initialization as a Kubernetes secret:

  1. Delete the <namespace>-api-gateway.jks secret if it already exists.

  2. Upload the new secret with the following command:

k create secret generic <namespace>-api-gateway-jks --from-file api-gateway.jks

Existing installation

1. Create a JKS with your CA certificate or the java keytool

If you are using the Java keytool, you can run the same command used in the Create a JKS section:

keytool -genkeypair -keyalg rsa -keysize 2048 -validity 3650 -dname "CN=sample, OU=sample, O=sample, L=sample, S=sample, C=sample" -storetype jks -keystore api-gateway.jks -keypass myPassword -storepass myPassword -alias jwt-signer

2. Scale down Fusion deployment to 0

This step will allow Fusion services to find the latest JKS once it is scaled up at the final step.

See Deploy Fusion at Scale for more information on the process.

3. Delete the existing Kubernetes JKS secret for Fusion

As in the Upload the api-gateway.jks as a Kubernetes generic secret section, delete the existing <namespace>-api-gateway.jks secret.

4. Create a Kubernetes secret with the JKS using the name of the deployment

Upload a new secret using the api-gateway.jks file with the following command:

k create secret generic <deployment>-api-gateway-jks --from-file api-gateway.jks

5. Scale up Fusion deployment

Fusion should accept the JKS once this step is complete.