Configuring security parameter

  • Used for SSL configurations to specify the trust store for IBM® Sterling Intelligent Promising containers.
  • By default, the Sterling Intelligent Promising containers trust the Java CA certs.

When data is exchanged, there are situations where your application needs to communicate with an external or a third-party service over secure protocols, such as HTTPS, to use certain capabilities. To enable trust with the external services and establish a successful secure connection, you need to configure SSL certificates in the application. The IBM Sterling Intelligent Promising Operator provides the following properties to configure the SSL certificates for your application and agent servers.

To trust an external service from your application, the IBM Sterling Intelligent Promising Operator provides the following options.
Using default Java trusted certificates
By default, the application trusts all the CA certificates that are bundled with the JRE. Any certificate that is signed with a globally recognized CA is trusted. If you do not want your servers to trust the certificates in default Java TrustStore, set the value of the property to False.
Using a custom TrustStore
This option provides you the flexibility to trust the specific services to which your application must establish an SSL connection. You can create your own TrustStore by using the keytool command of JDK in p12 format. Mount the newly created TrustStore using the additionalMount parameter and provide the complete path to the TrustStore with respect to the volume that is mounted within the pod in the custom resource parameters by using Also, add the password for this TrustStore in the secret that is created as a prerequisite provided in the Creating a secret section, with the key truststore_password.
Using a directory containing trusted certificates
This option provides you the ability to pass trusted server certificates as PEM files in the persistent volume. Provide the path to the directory that contains the trusted certificates in the custom resource parameters by using The application already uses the default Java TrustStore.

The following YAML file is a sample schema of security.

        storeType: JKS
        trustJavaCACerts: true
        trustedCertDir: /customer/certs
        storeLocation: /customer/es.jks
The following table explains the attributes that are applicable for the security parameter of SIPEnvironment.
Property Default value Value type Required Description   string No Specify the directory in the shared volume, which contains the certificates that IBM Sterling Intelligent Promising containers trust.
Note: The importing of certificates is a CPU-intensive task, so use this feature when you have only a few certificates to import.   string No Specify the path of the file in the shared volume, which contains the truststore that IBM Sterling Intelligent Promising containers trust.
Note: Ensure that you pass the TLS TrustStore password that is provided in the stringData.truststore_password attribute of the secret. For more information, see Creating a secret.   string No Specify the type of the truststore that you specified in the storeLocation. Available options are PKCS12 and JKS. true boolean No Set the value to true if you want the servers to trust the default Java CA certificates.

SSL configuration for securing external connections

  1. To update the certificates to the truststore, update the SIPEnvironment to set the following annotation to true. ‘true’
  2. To view the truststore that is created, see the following annotation in SIPEnvironment. /sip-external-certs/client.truststore_1695957582
  3. Go to the container to view the truststore file in step 2, by adding the extensions, .jks, .pkcs12, and .pem, as shown in the following example.
  4. Add the certificates for those services that are on SSL. For more information, see Configuring externalServices parameter.
  5. Add the required certificates in the additional mounts. For more information, see Configuring additionalMounts parameter.
Note: The connection between the client and the ingress must be always on https instead of http.