Manage certificates manually

If your internal or third party certificates are not stored in a remote configuration management center such as Vault, we can also define the certificates locally in a JSON file.


Internal certificates

For the internal certification between the WebSphere Commerce Docker containers, ensure that the Common Name (CN) in your certificate and "SubjectAlternativeName" can match the host name that the Docker containers will use. Also, when other source containers connect to a target container, the source container must use the target container's host name. There is strict verification logic in place to check whether the host name used in a request is the same as the SubjectAlternativeName in the certificate on the target container. If the host names do not match, then the connection fails. Here are the SubjectAlternativeNames in the default internal certification included in the WebSphere Commerce Docker containers:

If you do not use the default host names (app/search/store/xc/db) then you need to reconfigure the connections between containers. Here are some options that we can consider.

Note: To replace the default internal certificates, we must name the JSON file as default.json. Otherwise, the certificates are imported using the name of JSON file as an alias in the keystore list.


External certificates


How do I define certificate information in a JSON file?

Note: When you copy the certificates to the JSON file, we must replace the line break with \n to ensure that the entire certificate string is on one line.


How do I generate self-signed certificates?

Here is a general example of how to generate certificate. We can also use our own method of generating certificates.

  1. Create a configuration file to include certificate information. Here is a template for a myconfiguration.conf file. 

      [req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[ dn ]
C=US
ST=California
L=Los Angeles
O=MyOrg
OU=Commerce
emailAddress=<email address>
CN = <current_domain_name>

[ req_ext ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[ alt_names ]
DNS.0 = <current_domain_name>

  2. Create a private_key. Use the key in the server.key.secure file as the private_key name/value pair of the JSON file. 

      openssl genrsa -out server.key.secure 2048

  3. Create a request certificate with parameters from the configuration file. 

      openssl req -new -key server.key.secure -out server.csr -config myconfiguration.conf

  4. Create a certificate with parameters from the configuration file. Use the certificate in server.crt file as the value of the certificate name/value pair in the JSON file. For self-signed certificates, this value is also the issuing_ca. 

      openssl x509 -req -days 365 -in server.csr -signkey server.insecure.key -out server.crt -extensions req_ext -extfile myconfiguration.conf

    If we are using a CA, the issuing_ca is provided by the CA.

  5. Check the request file and certificate to ensure SubjectAltName exists. 

      openssl req -text -noout -in server.csr
openssl x509 -in server.crt -text -noout


How do I load the JSON files to the /SETUP/certs/custom directory of a Docker container?

Here are two methods of copying the JSON files to our Docker image.

Importing the local certificates from the JSON file into your running Docker container are handled by the /SETUP/bin/updateLocaCerts.sh script included in all the IBM provided Docker containers. The updateLocalCerts.sh script looks in the /SETUP/certs/custom directory and loads all JSON files.


Related tasks
Accessing Docker image Help


Related reference
Environment data structure in Consul/Vault
Manage certificates with Vault