Manage certificates with Vault

Manage certificates with Vault
By default, the WebSphere Commerce Docker containers support the use of Vault as the certification management system.
For more information about Vault, see Vault.

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:
SubjectAlternativeName [
[DNSName: app, DNSName: db, DNSName: search, DNSName: store, DNSName: xc]
]
If you do not use the default host names (app/search/store/xc/db) then you need to reconfigure the connections between containers. To learn how to create our own certificates, see Manage certificates manually. Otherwise we can use Vault as the certificate authority (CA).

External certificates

For external certification between WebSphere Commerce and third party software, ensure that we are importing the proper one-way or two-way certification information.
Ensure that our customization code, created to connect to third party software, use the correct certification name.

Configure Vault to act as the certificate authority (CA)
We can configure Vault as a CA with a PKI backend. If we want use this method, you need to hard code the PKI backend name as 'selfserve_production_pki' and PKI role as 'generate-cert'. Assuming that you have Vault installed, unsealed, and an environment that has a Vault client that can connect to the Vault server with the correct address and token, we can complete the following steps to set up Vault as a CA.
Note: The following steps are taken from the article Install Consul and Vault for configuration and certification management. For more information, refer to the article.
Create a PKI type backend.
vault mount -path=selfserve_production_pki -description="SelfServe Root CA" -max-lease-ttl=87600h pki
Enable Vault PKI feature to act as the CA organization to issue certificates.
Run the command to create a Root CA Certificate.
vault write selfserve_production_pki/root/generate/internal  common_name="selfserve_production_pki Root CA"  ttl=87600h  key_bits=4096  exclude_cn_from_sans=true
Create a role that will be used to issue certification for each Docker container.
vault write selfserve_production_pki/roles/generate-cert key_bits=2048 max_ttl=8760h allow_any_name=true
The command completes with a Success! Data written to: selfserve_production_pki/roles/generate-cert message.
Verify whether we can get certification from PKI.
curl -sS -X POST -H "X-Vault-Token:<Vault_token>" -d "{\"common_name\":\"<common_name>\", \"ttl\":\"1344h\"}" http://Vault_IP:8200/v1/selfserve_production_pki/issue/generate-cert
You should receive a response similar to the following output.
Key Value
--- -----
lease_id cuddletech_ops/issue/web_server/e03318f2-d005-8196-4ed5-a42f9cd55238
lease_duration 2591999
lease_renewable false
certificate -----BEGIN CERTIFICATE-----
MIIE7jCCAtagAwIBAgIUN+vXFuIf42v1SW+mDROUVAm+lUMwDQYJKoZIhvcNAQEL
BQAwKTEnMCUGA1UEAxMeQ3VkZGxldGVjaCBPcHMgSW50ZXJtZWRpYXRlIENBMB4X
DTE2MDcwOTA5MzE1N1oXDTE2MDgwODA5MzIyN1owIjEgMB4GA1UEAwwXc3NsX3Rl
...
issuing_ca -----BEGIN CERTIFICATE-----
MIIF5DCCA8ygAwIBAgIUdhJTQb4YmCyhUUr48L20o0R+dFkwDQYJKoZIhvcNAQEL
...
private_key -----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEApBabDpPZIloRQUpro3tQEls0FEFvsvfraQzQJLD2dicSPZ2s
CqYyT8OXMclrapG7KKTYp79AaTW8LgNg3WvCzoMGDfhLL9m0QomzrMDzoW8Q7iQO
1MV4f6JXjGMbOMMXatKQlO32fLZln8m+/yJ3pOW0S6uatFzZ/N3+ed+gDuUc7eAO
...
private_key_type rsa
serial_number 37:eb:d7:16:e2:1f:e3:6b:f5:49:6f:a6:0d:13:94:54:09:be:95:43
'''
Starting a container with VAULT_CA=true
After you configured Vault as the CA, we can start the container with the VAULT_CA=true parameter. Use this method in a Docker orchestration platform such as Kubernetes or DC/OS. When VAULT_CA=true, the scripts follow the <TENANT><ENVIRONMENT><ENVTYPE><container_name>.<DOMAIN_NAME> pattern to apply certifications. With this mode, the host name is fixed. If you do not provide a DOMAIN_NAME, the default is default.svc.cluster.local. (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>. When CONTAINER_HOSTNAME is passed, the start up logic /SETUP/bin/updateCerts.sh applies the internal certification based on the host name that you provide. For example, to start the Store server Docker container with host name mycustomstore
docker run -d -e LICENSE=accept  \
    -e SPIUSER_NAME=spiuser \
    -e SPIUSER_PWD=<Your spiuser password that you encrypted with wcs_encrypt.sh>
    -e VAULT_TOKEN=<vault_token > \
    -e VAULT_URL=<vault_url. For example, http://IP:Port/v1> \
    -e VAULT_CA=true \  
    -e CONTAINER_HOSTNAME=mycustomstore    
    <Store_Docker_Image>
Related tasks
Accessing Docker image Help

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