security parameter

The security parameter is 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 exchanging data, there are situations where your application need to communicate with an external or a third-party service over secure protocols such as HTTPS for leveraging certain capabilities. To enable trust with the external services and establish a successful secure connection, you need to configure SSL certificates in application.

The following .yaml file is a sample schema of security.

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

Trusting external server certificates

When Sterling Intelligent Promising communicates with external applications, it must trust the external applications. To trust the external application, the Sterling Intelligent Promising Operator provides following options.
  • Using default Java trusted certificates

    By default, the application trusts all the CA certificates bundled with the JRE. Any certificate signed with a globally recognized CA is trusted. In case you do not want your servers to trust the certificates in default Java TrustStore, set the value of ssl.trust.trustJavaCACerts property to False.

  • Using your own truststore

    You can create and manage your own truststore that contains the repository of security certificates, either Certification Authority (CA) certificates or self-signed certificates. You can trust these certificates and use that truststore to trust the external applications. Available options for truststore type are PKCS12 and JKS. You must mount the truststore by using the additionalMounts parameter. For more information, see additionalMounts parameter. Provide the complete path of the truststore which is mounted within the pod and provide it in the custom resource parameter by using ssl.trust.storeLocation as explained in the given security properties table. Also, add the truststore password in the secret that you created, with the key truststore_password. For more information about secrets, see Creating a secret.

  • Using a directory containing trusted certificates

    You can use your certificates to trust external applications. Pass the trusted server certificates through configMaps, secrets, and storage, in the SIPEnvironment custom resource by using the additionalMount parameter. For more information, see additionalMounts parameter. Provide the path of the trusted certificates directory which is mounted within the pod by using the ssl.trust.trustedCertDir property in SIPEnvironment, as explained in the given security properties table.

    For example, in the given sample schema of security, the trustedCertDir is defined to /customer/certs. In that case, all the certificates that are present in this directory and sub-directories will get added to the final truststore which Sterling Intelligent Promising is creating to trust the external application.

After you set the SIPEnvironment over SSL, if you wish to update the truststore or certificates, then set the following annotation to true, to trigger the truststore job to reconcile the changes. By default the value of this annotation is false.
apps.sip.ibm.com/import-certificate-to-truststore: ‘true’
Note: The connection between the client and the ingress must be always on https instead of http.