Truststores
You should only need to follow the below steps if your organisation uses self-signed custom certificates which are signed by an Internal Root Certificate Authority (Root CA).
Overview
In an enterprise environment, it is very common to have an internal root certificate authority (root CA) that signs all certificates used internally for TLS termination on HTTPS sites. While this trust is federated on the operating system level for all domain-connected Windows workstations, non-Windows servers are typically not configured the same way. Even on a Windows workstation, your Java runtime might not necessarily trust the enterprise root CA certificates.
If a Java application attempts to make a connection to an untrusted remote server, it will throw an SSLException
and fail to connect.
Java Truststores
A Java truststore is a bundle of certificates used when establishing connections to remote servers (this could be internal or on the Internet). Each Java runtime ships with a default truststore called cacerts
. Adding certificates directly into cacerts
is usually not recommended unless there is a centrally-managed deployment process for all workstations and servers.
Bot Truststore
A bot requires connections to several servers like the key manager or API agent, as defined in your bot configuration. This configuration should also define the path to a custom truststore, which ensures that the trust relationship is maintained even as the bot's deployment location is moved, as long as the truststore file is moved together with the deployment artifacts.
BDK for Java
The BDK for Java uses the JKS format and the configuration is under the ssl
section within the config.yaml
:
If you are using the BDK for Java's Spring Starters, modify the appropriate application.yaml
file to include the ssl
section under the bdk
section:
BDK for Python
The BDK for Python uses a concatenated PKCS format. Your config.yaml
should look like this:
WDK
The WDK is built on top of BDK for Java's Spring Starter. As such, configuring a custom truststore follows the same steps as the BDK for Java. Your configuration should look like this:
Certificate Chains
A typical internal certificate has has least 2 certificates in its chain - the certificate itself as well as the root CA certificate that signed it. Some enterprises will have intermediate CAs to form a 3-certificate chain. When Java establishes a connection to a remote server, it requires all signing certificates in that chain to be trusted. Hence, when building a truststore, you will need to import every signing certificate in the chain of each remote server that is not already present in the cacerts
bundle.
Publicly-trusted signing certificates from established certificate authorities are already in cacerts
so you will most likely not need to import certificates for services on the public Internet. However, if the Java runtime you are using pre-dates the existence of those certificates, then you will need to add them manually.
Building a Java Truststore
You can follow the same steps as the Java process below for WDK.
For Python you can also follow these steps except instead of using keytool
to import the certificates, simply concatenate all the certificates into a single file.
The keytool
command that ships with all Java runtimes is used to manage truststores. You can build a new truststore or append to an existing one using the same command as follows:
Automatic: Convenience Shell Script
You may use the following convenience shell script to automatically build out a new truststore based on a list of servers. Please remember to include all possible connections that your bot requires. This may include: all Key Manager servers, all API Agent servers, the Symphony pod, any other third-party or internal endpoints that the bot will interact with.
Manual: Collating Certificates in Windows
If you have no access to a Linux-based shell, you can also manually perform this process within a Windows environment. All you need is a browser and a Java runtime with keytool
installed.
Step 1: Visit an endpoint on each server in your browser and view the certificate
Step 2: Select the next signing certificate
In the Certification Path
tab, select the end certificate's parent and View Certificate
Step 3: Export the certificate
In the Details
tab, click Copy to File..
and select the Base-64 encoded X.509
option then save the certificate to disk.
Step 4: Repeat for the rest of the chain
Repeat Steps 2 and 3 until you have exported all signing certificates in the chain.
Step 5: Build the trust store
Launch command prompt and repeat this command for each exported certificate
You can verify the entries by using the -list option:
Last updated