Configuración de alias en modo cliente

Esto cubre la configuración de alias en el modo cliente.

Al otorgar acceso a EST en el modo de cliente solo se permiten entidades previamente registradas, mediante un código de inscripción único (a menos que esté configurado para permitirlo varias veces) en el CSR o un certificado de cliente de proveedor (consulte Modo de proveedor ).

A continuación se muestra la pantalla de configuración del alias EST ( Configuración del sistema > Configuración EST ).

imágenes/descargar/archivos adjuntos/124519752/est3.png

A continuación se enumeran las opciones de configuración de alias EST disponibles.

Valor	Descripción
Extraer componente de nombre de usuario	Cuando llega una solicitud, debe compararse con una entidad final prerregistrada en EJBCA. Este valor define qué campo DN del sujeto de la solicitud, en la CSR de la solicitud EST, se utiliza para asignar la solicitud a una entidad final. Este es el nombre de usuario utilizado para registrar la entidad final. El modo de proveedor funciona de forma ligeramente diferente; consulte Modo de proveedor .
Módulo de autenticación	Para autorizar las solicitudes iniciales de certificado. Especifica dónde se almacena el código de inscripción de la entidad final. Normalmente, se almacena en un atributo ChallengePassword en la CSR PKCS#10 (véase RFC 2985 ). Si el cliente no puede crear un atributo ChallengePassword en la CSR, una opción es usar un campo DN de solicitud especificado en la CSR como código de inscripción (la opción DnPartPwd).
Nombre de CA	El/los certificado(s) de la CA devuelto(s) a la llamada "cacerts" de EST para este alias. Dado que no hay ninguna entidad final involucrada en cacerts, esto podría ser diferente de la CA que emite el certificado de entidad final, si esta se registró con otra CA emisora. Asegúrese de que coincidan, según su caso práctico y cómo haya elegido usar EST.
Modo de certificado de proveedor	En lugar de usar el módulo de autenticación mencionado anteriormente, es posible autenticar una solicitud inicial con un certificado TLS (certificado de proveedor). Esto es similar a usar CMP con 3GPP .
Lista de CA de proveedores	Lista de autoridades de certificación, normalmente importadas como CA externas, que pueden usarse para autenticar certificados de proveedores de clientes.
Permitir cambio de nombre de asunto	Al usar el Modo de Certificado de Proveedor, un caso común es modificar el DN del sujeto del cliente, de lo que figura en el certificado TLS (certificado de proveedor) a lo que figura en la CSR. Según la RFC 7030, sección 4.2.1 , esto se permite si la CSR incluye un atributo ChangeSubjectName ( RFC 6402, sección 2.8 ), y este alias EST lo permite, por supuesto.
Renovación de certificado con las mismas claves	Si se selecciona Permitir , se puede realizar una solicitud de reinscripción para la misma clave pública anterior. Tenga en cuenta que el certificado de cliente siempre es necesario para la renovación, mientras que el nombre de usuario y la contraseña nunca son necesarios, independientemente de la configuración anterior.

Puertos de red y autenticación de certificado de cliente TLS

Usar EST puede ser complicado desde el punto de vista de la configuración de red. Algunas llamadas, como cacerts y simpleenroll, deben realizarse mediante TLS, pero normalmente no requieren la autenticación del certificado del cliente, ya que el cliente aún no posee un par de claves ni un certificado utilizables. Sin embargo, una llamada a simplereenroll requiere la autenticación del certificado del cliente para autenticarse con el certificado actual del cliente y aprobar automáticamente la renovación y emisión de un nuevo certificado. Para complicar aún más las cosas, al usar el modo Proveedor, simpleenroll también requiere la autenticación del certificado del cliente mediante TLS.

En una instalación EJBCA estándar, al comunicarse directamente con la instancia EJBCA, se verá obligado a utilizar puertos de red diferentes para las llamadas que requieren autenticación de certificado de cliente y las llamadas que no la requieren.

8442: TLS solo con autenticación de servidor
8443: TLS con autenticación de servidor y cliente

Si usa un proxy frente a JBoss/WildFly, puede habilitar el funcionamiento de EST en un único puerto TLS (es decir, una URL simple como https://ejbca.example.com/), haciendo que la autenticación del certificado del cliente sea opcional. Esta configuración de proxy de endpoint es fácil de realizar con Apache o Nginx y se utiliza en los productos Appliance y Cloud de PrimeKey.

Ejemplo de flujo de trabajo

Modo cliente con autenticación de contraseña de desafío

Ejemplo de inscripción: una entidad final se preinscribe en EJBCA. El cliente obtiene primero un certificado de CA y luego se inscribe para obtener un certificado de cliente, utilizando una contraseña de desafío en la CSR (el cliente EST es una entidad final no confiable). A continuación, el cliente realiza una renovación, autenticándose con el certificado de cliente emitido previamente.

La configuración EST es un alias EST con el nombre est y las siguientes configuraciones:

Configuración	Valor
Modo operativo EST	Cliente
Extraer componentes del nombre de usuario	CN
Módulo de autenticación	DesafíoPwd
Nombre de CA	Gestión CA
Modo de certificado de proveedor	FALSO
Renovación de certificado con las mismas claves	verdadero

Descargue el certificado CA de la conexión TLS EJBCA (normalmente el valor predeterminado es CA de administración) y configure la variable de entorno necesaria para estclient:

$ export EST_OPENSSL_CACERT= /tmp/ManagementCA .cacert.pem

Usando la biblioteca Cisco EST Client libEST , ejecute los siguientes comandos estclient para generar una clave y obtener un certificado de la CA:

 certs mkdir
 
# Get CA certificate, by "RA:
 . /estclient -g -s 127.0.0.1 -p 8442 -o certs --pem-output
 
# Inspect the fetched CA certificate
 openssl x509 - in certs /cacert-0-0 .pem -text -noout
 
# Get client certificate, for username selected by CN (myclient) authenticated with enrollment code as ChallengePassword in the CSR
 # First create the CSR and inspect it
 cat > openssl.conf
 [ req ]
 distinguished_name = req_distinguished_name
 attributes = req_attributes
 [ req_distinguished_name ]
 commonName = Common Name (eg, YOUR name)
 commonName_max = 64
 [ req_attributes ]
 challengePassword = A challenge password
 challengePassword_min = 4
 challengePassword_max = 20
 ^D
 openssl req -nodes -newkey rsa:2048 -keyout device.key -out device.csr -config openssl.conf
 # Enter Common Name '123456789' and challenge password 'password'
 openssl req - in device.csr -text
 # Then make the EST request
 . /estclient -e -s 127.0.0.1 -p 8442 -o certs --pem-output -y device.csr
 
# Inspect the fetched client certificate
 openssl x509 - in certs /cert-0-0 .pem -text -noout
 
# Re-enroll, directly by the client when certificate is about to expire, using the old client cert to authenticate with:
 # There is a bug in the estclient making it impossible to use a new key/csr, so you have to allow renewal with same key
 . /estclient -r -s 127.0.0.1 -p 8443 -o certs -c certs /cert-0-0 .pem -k device.key --pem-output
 
# Inspect the new, renewed, client certificate
 $ openssl x509 - in certs /cert-0-0 .pem -text -noout
 
# Revoke the clients certificates by going to CA UI and using Search End Entities to find the end entity and revoke certificates.
 # Try to re-enroll again, which will not work with a revoked client certificates.
 . /estclient -r -s 127.0.0.1 -p 8443 -o certs -c certs /cert-0-0 .pem -k device.key --pem-output
 
# Enroll with an EC key. First we have to generate the key, a Prime256v1 key on this case, and then use this key for enrollment.
 openssl ecparam -name prime256v1 -genkey -noout -out prime256v1-key.pem
 openssl req -nodes -new -key prime256v1-key.pem -out device-ec.csr -config openssl.conf
 # Enter Common Name '123456789' and challenge password 'password'
 openssl req - in device-ec.csr -text
 . /estclient -e -s 127.0.0.1 -p 8442 -o certs --pem-output -y device-ec.csr
 openssl x509 - in certs /cert-0-0 .pem -text -noout
 
# Re-enroll, also with EC, using the same key (using the same key can be dissalowed in the EST alias).
 . /estclient -r -s 127.0.0.1 -p 8443 -o certs -c certs /cert-0-0 .pem -k prime256v1-key.pem --pem-output
 openssl x509 - in certs /cert-0-0 .pem -text -noout

También puede usar curl para realizar las llamadas EST. Tenga en cuenta que la codificación base64 debe estar sobre el CSR binario. El comando para la inscripción inicial con curl sería (usando el mismo CSR generado anteriormente).

 # Convert the PEM encoded CSR to DER encoded and base64 encode
 openssl req - in device.csr -outform DER -out device.csr.der
 openssl base64 - in device.csr.der -out device.b64 -e
 # Make the EST request
 curl - v --cacert /tmp/ManagementCA .cacert.pem --data @device.b64 -o device-p7.b64 -H "Content-Type: application/pkcs10" -H "Content-Transfer-Encoding: base64" https: //127 .0.0.1:8442/.well-known /est/est/simpleenroll
 # Decode the response and look at the cert
 openssl base64 - in device-p7.b64 -out device-p7.der -d
 openssl pkcs7 -inform DER - in device-p7.der -print_certs -out device-cert.pem
 openssl x509 - in device-cert.pem -text -noout 

Modo de vendedor

Ejemplo de inscripción: una entidad final se preinscribe en EJBCA. El cliente obtiene primero el certificado de CA y luego se inscribe para obtener un certificado de cliente mediante un certificado de cliente de proveedor TLS preinstalado en el dispositivo. EJBCA conoce la autoridad de certificación que emite el certificado de cliente de proveedor como CA externa.

Importación de CA de proveedores a EJBCA

Aquí está el certificado VendorRootCAEC384.cacert.pem para nuestro ejemplo.

 cat > VendorRootCAEC384.cacert.pem
 -----BEGIN CERTIFICATE-----
 MIIB5zCCAY2gAwIBAgIIfIFBpHsapFAwCgYIKoZIzj0EAwMwRzELMAkGA1UEBhMC
 U0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxHTAbBgNVBAMMFFZlbmRvciBS
 b290IENBIEVDMzg0MB4XDTIwMTAxOTA2MjExMloXDTQwMTAxNDA2MjExMlowRzEL
 MAkGA1UEBhMCU0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxHTAbBgNVBAMM
 FFZlbmRvciBSb290IENBIEVDMzg0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
 Pg1gVL60dcs+pI0xqdt+ZxFsi0z0PM/++tXy3CTN1MIL+UL7hjIbHZoKHDydDjvX
 Jh2wNEvR1uby3XIwg0+zVaNjMGEwDwYDVR0TAQH /BAUwAwEB/zAfBgNVHSMEGDAW
 gBSK0LnIltrD+4XTciuLinXtYpk /yzAdBgNVHQ4EFgQUitC5yJbaw/uF03Iri4p1
 7WKZP8swDgYDVR0PAQH /BAQDAgGGMAoGCCqGSM49BAMDA0gAMEUCIQDsFbCpZbxA
 tPYrCaNm+8viymtxgW59rrUqbi4GweEqBQIgMvS0OeKVASGAeBIUoI3GBgszzVgj
 M6MzBjOO586jzSs=
 -----END CERTIFICATE-----
 cat > VendorSubCAEC384.cacert.pem
 -----BEGIN CERTIFICATE-----
 MIIB5jCCAYugAwIBAgIIc8lyzz9D+tQwCgYIKoZIzj0EAwMwRzELMAkGA1UEBhMC
 U0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxHTAbBgNVBAMMFFZlbmRvciBS
 b290IENBIEVDMzg0MB4XDTIwMTAxOTA2MjE0MVoXDTQwMTAxNDA2MjExMlowRTEL
 MAkGA1UEBhMCU0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxGzAZBgNVBAMM
 ElZlbmRvciBTdWJDQSBFQzM4NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABP4c
 764FiC2EPqHqkHmRn7OdQoinqWe73yKfBSdTxppnQntMW1oq4kkO1A9qxWgiBN4f
 nvx /oByN38Pe1Sl0w1yjYzBhMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAU
 itC5yJbaw /uF03Iri4p17WKZP8swHQYDVR0OBBYEFOAbHblwsKqYhl4u5DX9hBpN
 KAAWMA4GA1UdDwEB /wQEAwIBhjAKBggqhkjOPQQDAwNJADBGAiEAhWK79GK75Y ++
 uVLcF6TK2+FWvF0bN820Fwsdmzqsk1ACIQCkwGxvCmZ5RBclq3aWS37wnfucxqeU
 6efhzZTOTcKwGA==
 -----END CERTIFICATE-----

Importe estos certificados en EJBCA como CA externas en la interfaz de administración con Autoridades de certificación → Importar certificado de CA , asígneles los nombres Vendor Root CA y Vendor Sub CA .

Para aceptar conexiones TLS con esta CA como ancla de confianza, también debe importarla al almacén de confianza de JBoss/WildFly. En una instalación predeterminada de EJBCA, este se encuentra en $JBOSS_HOME/standalone/configuration/keystore/truststore.jks.

 keytool -importcert -trustcacerts -keystore truststore.jks -alias VendorRootCA -file VendorRootCAEC384.cacert.pem
 keytool -importcert -trustcacerts -keystore truststore.jks -alias VendorSubCA -file VendorSubCAEC384.cacert.pem 

Creación de un alias EST

La configuración de EST es un alias de EST con el nombre estvendor y las siguientes configuraciones:

Configuración	Valor
Modo operativo EST	Cliente
Extraer componentes del nombre de usuario	CN
Nombre de CA	Gestión CA
Módulo de autenticación	Ninguno
Modo de certificado de proveedor	verdadero
Lista de CA de proveedores	Sub CA del proveedor
Permitir cambio de nombre de asunto	verdadero
Renovación de certificado con las mismas claves	FALSO

Cliente preinscrito

El cliente que se autorizará para la inscripción debe agregarse a EJBCA para que este cliente específico reciba un certificado. La entidad final puede agregarse mediante la CLI, la interfaz de usuario o la API REST o WS.

El CN suele coincidir con el número de serie del dispositivo que se va a registrar. La contraseña proporcionada en la línea de comandos no es necesaria para la inscripción y puede configurarse con un valor aleatorio. Si no se requiere contraseña en el perfil de la entidad final, puede configurarse como "null". En este ejemplo, el DN del sujeto del certificado del proveedor coincide con el DN del certificado solicitado. En este caso, no es necesario utilizar el atributo ChangeSubjectName en la CSR.

Con EST, para la renovación, es importante que el nuevo DN y el nombre alternativo de la solicitud coincidan en la CSR con el certificado existente utilizado para la autenticación de renovación TLS; de lo contrario, la solicitud de renovación fallará. El atributo CSR ChangeSubjectName se puede usar para la inscripción inicial en el modo de proveedor, pero no para la renovación, lo cual es importante para evitar que un dispositivo suplante la identidad de otro durante la renovación.

 bin /ejbca .sh ra addendentity --username 1234.primekey.com --dn "CN=1234.primekey.com,O=PrimeKey,C=SE" --caname ManagementCA --eeprofile=TLSClientEEProfile --certprofile=TLSEndEntityCertProfile -- type 1 --token USERGENERATED --password ZUhgGPuu-doesnt-matter-randomize

Para inscribirse en un certificado de operador, el cliente debe enviar el certificado del proveedor y la CA secundaria en el campo de protocolo de enlace TLS de la solicitud EST .

A continuación, se proporcionan vendor-key.pem (clave privada del proveedor del dispositivo), vendor-cert.pem (certificado del proveedor del dispositivo) y VendorSubCAEC384.cacert.pem (certificado de sub CA del proveedor).

En la terminal del cliente, cree los archivos de certificado necesarios:

 cat > vendor-key.pem
 -----BEGIN PRIVATE KEY-----
 MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgUmy7YVUMGuemV637
 Vcq91ZNL9WAnF56fC1dThaGy5T6gCgYIKoZIzj0DAQehRANCAASyrEYCkTX4ApjD
 R9E36V63cUgkZwD4raKpGMZ6jO2RnfPjtcalGK1sDdlF+GSh9XpLul9GibPiDLIX
 Ten4Un2I
 -----END PRIVATE KEY-----
 cat > vendor-cert.pem
 -----BEGIN CERTIFICATE-----
 MIIB2DCCAX2gAwIBAgIIVZHqvoM7h7wwCgYIKoZIzj0EAwMwRTELMAkGA1UEBhMC
 U0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxGzAZBgNVBAMMElZlbmRvciBT
 dWJDQSBFQzM4NDAeFw0yMDEwMTkwNjIyNTlaFw00MDEwMTQwNjIxMTJaMDwxCzAJ
 BgNVBAYTAlNFMREwDwYDVQQKDAhQcmltZUtleTEaMBgGA1UEAwwRMTIzNC5wcmlt
 ZWtleS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASyrEYCkTX4ApjDR9E3
 6V63cUgkZwD4raKpGMZ6jO2RnfPjtcalGK1sDdlF+GSh9XpLul9GibPiDLIXTen4
 Un2Io2AwXjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFOAbHblwsKqYhl4u5DX9
 hBpNKAAWMB0GA1UdDgQWBBRln9C8ctMywHZ+Azk4IsZnu0HmXzAOBgNVHQ8BAf8E
 BAMCB4AwCgYIKoZIzj0EAwMDSQAwRgIhAImjJNNR2LkSWBBmThF3SrhErXtFB5t6
 T9AZPqRXnuGQAiEAt9RUxTqGc0d4olxtsMU7O /yJ/L2OayUruRjOOZZHLcc =
 -----END CERTIFICATE----- 

Para realizar la renovación mediante EST, debe asegurarse de que los perfiles de certificado utilizados para emitir el certificado de cliente sean compatibles con la autenticación de certificados de cliente TLS. Esto implica, por ejemplo, incluir la "Autenticación de cliente" en la extensión de uso de clave extendida.

Inscripción con autenticación TLS de certificado de proveedor

A continuación se muestra un ejemplo de flujo de trabajo completo que utiliza CURL, donde la inscripción inicial utiliza la autenticación de certificado de cliente TLS usando un certificado de proveedor y la reinscripción utiliza el certificado de cliente (operador) existente.

 # Get CA certificates
 curl https: //localhost:8442/.well-known/est/estvendor/cacerts -o cacerts.p7 --cacert ManagementCA.cacert.pem
 # Generate a key and CSR for a "device"
 # Make sure the subject DN and subject alternative name matches the requirements of the end entity profile.
 openssl req -nodes -newkey rsa: 2048 -keyout device.key -out device.csr -outform DER -subj "/CN=1234.primekey.com/O=PrimeKey/C=SE"
 openssl req -inform DER -in device.csr -text -noout
 openssl base64 -in device.csr -out device.b64 -e
 # Make initial enrollment, using TLS client certificate authentication
 curl -v --cacert ManagementCA.cacert.pem --cert vendor-cert.pem --key vendor-key.pem --data @device .b64 -o device-p7.b64 -H "Content-Type: application/pkcs10" \
 -H "Content-Transfer-Encoding: base64" https: //localhost:8443/.well-known/est/estvendor/simpleenroll
 # Convert the response into a PEM encoded certificate
 openssl base64 -in device-p7.b64 -out device-p7.der -d
 openssl pkcs7 -inform DER -in device-p7.der -print_certs -out device-cert.pem
 openssl x509 -in device-cert.pem -text -noout
 # Generate a new key and CSR for the device, to renew with
 openssl req -nodes -newkey rsa: 2048 -keyout device- new .key -out device- new .csr -outform DER -subj "/CN=1234.primekey.com/O=PrimeKey/C=SE"
 openssl base64 -in device- new .csr -out device- new .b64 -e
 # Re-enroll by the device, authenticating with the existing key/certificate
 curl -v --cacert ManagementCA.cacert.pem --key device.key --cert device-cert.pem --data @device - new .b64 -o device- new -p7.b64 -H "Content-Type: application/pkcs10" -H "Content-Transfer-Encoding: base64" https: //localhost:8443/.well-known/est/estvendor/simplereenroll
 # Convert the response into a PEM encoded certificate
 openssl base64 -in device- new -p7.b64 -out device- new -p7.der -d
 openssl pkcs7 -inform DER -in device- new -p7.der -print_certs -out device- new -cert.pem
 openssl x509 -in device- new -cert.pem -text -noout

ManagementCA.cacert.pem es el certificado de CA raíz de la cadena de CA que emitió el certificado del servidor TLS y debe configurarse con curl para que se establezca la conexión TLS. ManagementCA es el nombre en una instalación EJBCA predeterminada y el certificado puede descargarse desde la interfaz de CA o la interfaz de RA.

Los ejemplos anteriores utilizan el puerto 8442 para TLS con autenticación de servidor y el puerto 8443 para TLS con autenticación de cliente y de servidor (al usar un certificado de autenticación de cliente y una clave privada). El puerto TLS estándar, 443, se utiliza al ejecutar un proxy Apache frente a EJBCA, como en el caso de una instancia de EJBCA Cloud o un dispositivo de hardware PrimeKey. Para instancias de EJBCA Enterprise Cloud o el dispositivo de hardware PrimeKey, el puerto 443 funcionará para llamadas con o sin autenticación de certificado de cliente.