CA de bóveda de HashiCorp subordinada a la raíz de EJBCA
A continuación se describe cómo crear una CA subordinada en Vault y obtenerla firmada por una CA raíz en EJBCA.
Introducción
Hoy en día, la PKI se necesita en múltiples casos de uso dentro de una organización y a través de sus diversas fronteras. Una amplia gama de productos y herramientas puede ser la más adecuada para un caso de uso específico, mientras que una distribución muy diversa de la PKI dificulta el control y el mantenimiento de las políticas de cifrado y firma, la gestión de claves y la confianza, etc. Una práctica recomendada común en PKI es utilizar una jerarquía de autoridades de certificación (CA) para controlar y utilizar eficientemente la confianza.
Muchas organizaciones utilizan HashiCorp Vault para gestionar secretos y PrimeKey EJBCA para la gestión centralizada de PKI. Es posible utilizar ambos productos conjuntamente de diversas maneras. A continuación, se describe cómo configurar una CA de Vault como CA subordinada o CA raíz en EJBCA. Contar con un único ancla de confianza, en forma de CA raíz, es una práctica común en muchas organizaciones y se puede lograr subordinando HashiCorp Vault a EJBCA.
Prerrequisitos
A continuación, se presenta un enfoque basado en la línea de comandos, adecuado para scripting y automatización. Tenga en cuenta que puede realizar las mismas tareas con interfaces web administrativas.
Para completar la subordinación se requieren los siguientes requisitos previos:
EJBCA
EJBCA implementado con una CA raíz
Un perfil de certificado en EJBCA para la CA subordinada de HashiCorp Vault
Un perfil de entidad final en EJBCA para la CA subordinada de HashiCorp Vault que está configurada para usar el perfil de certificado de la CA subordinada de HashiCorp Vault
Credencial RA que tiene acceso para crear la entidad final de CA subordinada de HashiCorp Vault en EJBCA
Una estación de trabajo con la utilidad EJBCA Client Toolbox configurada para usar EJBCA
Bóveda de HashiCorp
HashiCorp Vault instalado, inicializado y desbloqueado
Procesador JSON jq instalado en el servidor HashiCorp Vault
Interfaz de línea de comandos de Vault v1.3.4
Contenedor Docker de Vault versión 1.4.0
CA de bóveda de HashiCorp subordinada a la raíz de EJBCA
Para completar una subordinación de una CA de Vault, siga los pasos que se describen en las secciones siguientes.
Paso 2: Configuración de la estación de trabajo de ClientToolBox
Paso 3: Finalizar la configuración de la sub CA de HashiCorp Vault
Contenido relacionado
Paso 1: Configuración de HashiCorp Vault
Realice lo siguiente en el servidor Vault mediante la utilidad de línea de comandos de Vault. Acceda al servidor Vault mediante SSH.
Habilitar Vault PKI.
vault secrets enable pkiCrear la CA subordinada de Vault.
vault secrets enable -path=subca01 pkiCree la solicitud de firma de certificado (CSR) de CA subordinada.
vault write -format=json subca01/intermediate/generate/internal common_name="Vault Intermediate Authority G1"key_bits="2048"| jq -r'.data.csr'> subca01.csrEl DN de CA para la CA secundaria de almacén se crea y se aplica en EJBCA. Seleccione los valores adecuados para su organización.
Copie el archivo subca01.csr en la estación de trabajo que tiene configurada la utilidad EJBCA Client Toolbox para realizar acciones en la CA EJBCA.
Paso 2: Configuración de la estación de trabajo de ClientToolBox
A continuación, se describe la interacción con EJBCA mediante la herramienta CLI de servicios web EJBCA Client Toolbox , que puede ejecutarse remotamente desde cualquier estación de trabajo con autenticación TLS mutua. Tenga en cuenta que las mismas acciones también pueden realizarse en las interfaces de usuario de CA o RA de EJBCA, o con otros protocolos y API. Para obtener más información sobre la CLI de servicios web de EJBCA, consulte Uso de la CLI de servicios web y, para el uso general de la interfaz de usuario de EJBCA, consulte la Guía de operaciones de CA.
Realice lo siguiente para firmar la CSR de la sub CA mediante la herramienta CLI del servicio web EJBCA. Anote la ubicación del archivo CSR subca01.csr en los pasos a continuación: /var/tmp .
Abra una ventana de terminal y cambie el directorio a la utilidad clientToolBox.
Crea la entidad final en EJBCA.
./ejbcaClientToolBox.sh EjbcaWsRaCli edituser vault-subca01 foo123false'cn=Vault Intermediate Authority G1,ou=Certification Authorities,o=PrimeKey,c=SE'NULL NULL PrimeKey-Root-G11USERGENERATED NEW Hashicorp-SubCAEE Hashicorp-SubCACPEntregar el CSR para su firma.
./ejbcaClientToolBox.sh EjbcaWsRaCli pkcs10req vault-subca01 foo123 /var/tmp/subca01.csr PEM NONE /var/tmp/Obtenga el certificado CA raíz.
curl -o /var/tmp/root.crt"https://enrollprimekey.primekey.se/ejbca/publicweb/webdist/certdist?cmd=cacert&issuer=CN%3DPrimeKey+Root+CA+G1%2COU%3DCertification+Authorities%2CO%3DPrimeKey%2CC%3DSE&level=0"Agregue el certificado de CA raíz al archivo subca01.crt .
cat /var/tmp/root.crt >> /var/tmp/subca01.pemCopie el archivo subca01.pem al servidor Vault.
Paso 3: Finalizar la configuración de la sub CA de HashiCorp Vault
A continuación, se describe cómo importar el certificado firmado para completar la subordinación y configurar un dominio para emitir los certificados. El archivo PEM debe estar en /var/tmp para completar los siguientes pasos.
Importe el certificado de Sub CA a Vault.
vault write subca01/intermediate/set-signed certificate=@/var/tmp/subca01.pem -format=json"Crear un dominio para emitir certificados.
vault write subca01/roles/primekey-se allowed_domains='primekey.se,primekey.som'allow_subdomains='true'max_ttl='160h'key_usage='DigitalSignature, KeyEncipherment'-format=json"Prueba de emisión de un certificado.
vault write subca01/issue/primekey-se common_name='vault.primekey.se'ttl='24h'-format=json
Uso de la sub CA de HashiCorp Vault
La CA subordinada de HashiCorp ahora puede utilizarse para emitir certificados en su entorno HashiCorp. La ventaja de tener las CA de HashiCorp firmadas por una CA raíz es que los clientes que necesitan configurarse con anclas de confianza, normalmente para confiar en más de una CA subordinada, solo tienen que configurarse con la CA raíz como ancla de confianza. Además, el equipo central de gestión de PKI puede ignorar las CA subordinadas y revocar las sub CA que se hayan visto comprometidas o que ya no deban utilizarse por otros motivos.