Gestionar certificados con Vault

De forma predeterminada, los contenedores de Docker de HCL Commerce permiten usar Vault como sistema de gestión de certificados.

Para obtener más información sobre Vault, consulte Vault.

Certificados internos

Para la certificación interna entre los contenedores de Docker de HCL Commerce, debe asegurarse de que el nombre común (CN) del certificado y "SubjectAlternativeName" puedan coincidir con el nombre de host que utilizarán los contenedores de Docker. Además, cuando otros contenedores de origen se conectan a un contenedor de destino, el contenedor de origen debe utilizar el nombre de host del contenedor de destino. Hay una lógica de verificación estricta para comprobar si el nombre de host que se utiliza en una petición es el mismo que el SubjectAlternativeName del certificado en el contenedor de destino. Si los nombres de host no coinciden, la conexión falla.

A continuación se indican los SubjectAlternativeName en la certificación interna predeterminada que se incluye en los contenedores de Docker de HCL Commerce:

SubjectAlternativeName [
  DNSName: *
  DNSName: app
  DNSName: web
  DNSName: search
  DNSName: store
  DNSName: tooling-web
  DNSName: store-web
  DNSName: query
  DNSName: data-query
  DNSName: ingest
  DNSName: nifi
  DNSName: registry
  DNSName: elasticsearch
  DNSName: zookeeper
  DNSName: localhost
  DNSName: search_master
  DNSName: search_repeater
  DNSName: search_slave
]

Si no utiliza los nombres de host predeterminados, deberá volver a configurar las conexiones entre contenedores. Para obtener información sobre cómo crear sus propios certificados, consulte Gestionar certificados. De lo contrario, puede utilizar Vault como la autoridad de certificación (CA).

Configurar Vault para que actúe como autoridad de certificación (CA)

Puede configurar Vault como un CA con un sistema de fondo PKI. Si desea utilizar este método, debe codificar el nombre de fondo de PKI como 'selfserve_production_pki' y el rol de PKI como 'generate-cert'. Suponiendo que tiene instalado Vault, no sellado y un entorno que tiene un cliente de Vault que puede conectarse al servidor de Vault con la dirección y señal correctas, puede realizar los siguientes pasos para configurar Vault como CA.

Cree un sistema de fondo de tipo PKI.

vault secrets enable -path=selfserve_production_pki -description="SelfServe Root CA" -max-lease-ttl=87600h pki

Habilite la característica PKI de Vault para que actúe como entidad certificadora (CA) para emitir certificados.
1. Ejecute el mandato para crear un certificado de CA raíz.
```
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
```
2. Ejecute el siguiente mandato para crear un rol que se utilizará para emitir la certificación para cada contenedor de Docker.
```
vault write selfserve_production_pki/roles/generate-cert key_bits=2048 max_ttl=8760h allow_any_name=true enforce_hostnames=false
```
  El mandato se completa con éxito. Datos escritos a: Mensaje selfserve_production_pki/roles/generate-cert.

Verifique si puede obtener la certificación de 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

Debería recibir una respuesta similar a la siguiente salida.

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
'''

Inicio de un contenedor con VAULT_CA=`true`

Después de configurar Vault como CA, puede iniciar el contenedor con el parámetro VAULT_CA=true . Utilice este método en una plataforma de orquestación de Docker como, por ejemplo, Kubernetes. Cuando VAULT_CA=true, los scripts siguen el

TENANTENVIRONMENTENVTYPEcontainer_name.DOMAIN_NAME

patrón para aplicar las certificaciones. Con esta modalidad, el nombre de host es fijo. Si no proporciona un DOMAIN_NAME, el valor predeterminado es default.svc.cluster.local.

Iniciar un contenedor con VAULT_CA=`true` pero sin CONTAINER_HOSTNAME=`customHostName`

A partir de la versión 9.0.0.2 de HCL Commerce, puede iniciar el contenedor con VAULT_CA=true y CONTAINER_HOSTNAME=customHostName. Utilice este método en su propio entorno personalizado en el que no tenga TENANTENVIRONMENTENVTYPE. Cuando se pasa CONTAINER_HOSTNAME, la lógica de inicio de /SETUP/bin/updateCerts.sh aplica la certificación interna basándose en el nombre de host que usted proporcione. Por ejemplo, para iniciar el Store server Docker container con el nombre de host 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>

Certificados externos

Para una comunicación SSL segura entre HCL Commerce y un sistema externo, asegúrese de importar los certificados adecuados en su almacén de claves y almacén de confianza. Asegúrese también de que el código de personalización hace referencia al nombre de certificado correcto para esa comunicación. Puede colocar sus certificados de terceros en Vault para permitir que el script de configuración updateCerts.sh importe automáticamente cualquier certificado en el almacén de claves.

Para incluir certificados externos:

Cree un paquete de certificados (certBundle) para su certificado externo.

Nota: Si el propósito de un paquete de certificados que está creando es confiar en un certificado asignado para un sistema externo, solo se debe especificar issusing_ca. En este caso, los valores certificate y private_key pueden estar vacíos o quedar fuera de la definición certBundle por completo.

Un certBundle es un objeto JSON que contiene un certificado, su clave privada y el certificado o la cadena de certificados de la entidad de certificación (CA). Un ejemplo de un certBundle es el siguiente.

{ 
 "certificate": "certificate", 
 "private_key": "private_key", 
 "issuing_ca": "ca_certificates" 
}

El contenido del paquete de certificados es el siguiente.

El valor certificate contiene el certificado, en formato PEM base64, que se debe asignar al servidor de aplicaciones HCL Commerce especificado:

El valor de este certificado debe ajustarse dentro de las líneas de texto -----BEGIN CERTIFICATE-----\n y -----END CERTIFICATE-----.
El valor del certificado debe ser solo una línea de texto y terminar en \n, para denotar el final de la línea.

Un ejemplo del valor certificate es el siguiente.

El valor private_key contiene la clave privada que coincide con el certificado y es necesario instalar el certificado para el servidor de aplicaciones de HCL Commerce:

El valor de este certificado debe ajustarse dentro de las líneas de texto -----BEGIN RSA PRIVATE KEY-----\n y -----END RSA PRIVATE KEY-----.
El valor del certificado debe ser solo una línea de texto y terminar en \n, para denotar el final de la línea.

Un ejemplo del valor certificate es el siguiente.

El valor issuing_ca contiene el certificado de entidad de certificación (CA), o cadena de certificados de entidad de certificación, que se utilizan para validar el certificado. Por ejemplo, si el certificado está firmado por un certificado de CA intermedio, tanto el certificado de CA intermedio como su certificado de CA raíz deben incluirse dentro del valor issuing_ca.

El valor de este certificado debe ajustarse dentro de las líneas de texto -----BEGIN CERTIFICATE-----\n y -----END CERTIFICATE-----.
El valor del certificado debe ser solo una línea de texto y terminar en \n, para denotar el final de la línea.

Un ejemplo del valor issuing_ca es el siguiente.

Escriba los datos de certBundle en Vault.
Importante: Cada certBundle debe tener un nombre exclusivo. Por ejemplo, cert1 y cert2.
Por ejemplo, el siguiente comando curl escribe el contenido de certBundle, cert_bundle_json en la definición cert1 de un inquilino y entorno especificados.
```
curl -sS -X POST -H "X-Vault-Token:<Vault_token>" -d "{\"value\":<cert_bundle_json>}" http://<Vault_IP>:8200/v1/<tenant>/<environment>/certs/cert1 
```
Especifique qué certificados certBundle se deben implementar en cada servidor de aplicaciones de HCL Commerce.
Esto se hace actualizando la definición de certsBundle en el inquilino y el entorno especificados, {tenant}/{environment}/certsBundle, con el siguiente formato de objeto JSON.
```
{ 
    "tsapp": "cert1,cert2", 
    "crsapp": "cert1,cert2", 
    "searchapp": "cert1,cert2", 
    "xcapp": "cert1,cert2", 
    "storeapp": "cert1,cert2" 
} 
```
En este ejemplo, certsBundle cert1 y cert2 se implementan en cinco servidores de aplicaciones de HCL Commerce y se aplican dentro de ellos.
Implemente las aplicaciones de HCL Commerce para aplicar los certificados externos.
El script de utilidad de updateCerts.sh no aplicará certificados sin una implementación para desencadenarlo.