Optional: Using Vault as a certificate authority

We can use vault as a certificate authority by specifying VAULT_CA=true. This is an optional configuration and can be used with any of the configuration mode supported to handle internal certification between the containers.

If you have Vault configured as a certificate authority (CA), we can use VAULT_CA=true, which triggers /SETUP/bin/updateCerts.sh in the Docker image. For information about configuring Vault as a CA, see Manage certificates with Vault.

VAULT_CA=true is an independent configuration that we can use with any of the three modes (CONFIGURE_MODE=Vault, CONFIGURE_MODE=EnvVariables, or no configuration mode). If we are using CONFIGURE_MODE=Vault|EnvVariables, ensure that you also specify the mandatory parameters for our mode. For example, if you enable CONFIGURE_MODE=Vault and VAULT_CA=true, then you need to specify TENANT, ENVIRONMENT, and ENVTYPE because it is needed for CONFIGURE_MODE=Vault. When you read the container parameters and notice that the same variables are used in different configuration modes (such as VAULT_TOKEN), you just need to define it once as a container environment variable. The different configuration modes will share the same variables that you provide. The parameter VAULT_CA=true also has it's own two configuration modes.

• Without CONTAINER_HOSTNAME

• (v9.0.0.2) With CONTAINER_HOSTNAME=<customHostName>

Starting a container with VAULT_CA=true but without CONTAINER_HOSTNAME

Use this method in an environment where the container variables are grouped in the form <TENANT><ENVIRONMENT><ENVTYPE><TARGETKEY>. For example, if you use VAULT to store your parameters and we are using CONFIGURE_MODE=Vault.

This method is ideal in a Docker orchestration platform such as Kubernetes or DC/OS where we can resolve <TENANT><ENVIRONMENT><ENVTYPE>. When VAULT_CA=true, the start up logic /SETUP/bin/updateCerts.sh applies the internal certification based on the unique naming pattern <TENANT><ENVIRONMENT><ENVTYPE><DOCKER_CONTAINER>.<DOMAIN_NAME> as the common_name and SubjectAlternativeName. With this mode, the host name is fixed. If you do not provide a DOMAIN_NAME, the default is default.svc.cluster.local. For example, to start a container with the DOMAIN_NAME as txn,

docker run -it -e LICENSE=accept  \
    -e VAULT_TOKEN=<vault_token > \
    -e VAULT_URL=<vault_url. For example, http://IP:Port/v1> \
    -e VAULT_CA=true \
    -e TENANT=<tenantValue> \
    -e ENVIRONMENT=<environmentValue. For example, non-prod> \
    -e ENVTYPE=<envtypeValue. For example, auth> \
    -e DOMAIN_NAME=<The container's hostname, which will be used to apply certification. For example, txn> \
    -e <Parameter1>=<Value1>
    -e <Parameter2>=<Value2>
    .... 
    <Docker_Image>

(v9.0.0.2)

Starting a container with VAULT_CA=true and CONTAINER_HOSTNAME=<customHostName>

Starting with WebSphere Commerce Version 9.0.0.2, we can start the container with VAULT_CA=true and CONTAINER_HOSTNAME=<customHostName>. Use this method on our own custom environment where you do not have <TENANT><ENVIRONMENT><ENVTYPE>. For example, if we are using a local environment and we are not using CONFIGURE_MODE=Vault, then you will want to specify CONTAINER_HOSTNAME.

When CONTAINER_HOSTNAME is passed, the start up logic /SETUP/bin/updateCerts.sh applies the internal certification based on the CONTAINER_HOSTNAME as the certificate's common_name and SubjectAlternativeName. For example, to start a container with host name mycontainerhostname

docker run -it -e LICENSE=accept  \
    -e VAULT_TOKEN=<vault_token > \
    -e VAULT_URL=<vault_url. For example, http://IP:Port/v1> \
    -e VAULT_CA=true \  
    -e CONTAINER_HOSTNAME=mycontainerhostname   
    -e <Parameter1>=<Value1>
    -e <Parameter2>=<Value2>
    ....
    <Docker_Image>