Configuración del modo EST RA

A continuación se describe la configuración de EST en modo RA.

Configuración de alias en modo RA

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

Dar acceso a EST en modo RA permite a las RA emitir certificados con total libertad, con el contenido del DN del sujeto y el nombre alternativo definido por la solicitud enviada por la RA. Puede limitar los campos y el contenido permitidos del certificado mediante la entidad final y los perfiles de certificado, pero el modo RA generalmente debe usarse solo para RA de confianza.

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/143734741/est1.png

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

Valor

Descripción

Esquema de generación de nombres de RA

DN: Tomará una parte del DN de la solicitud y la usará como nombre de usuario (use la lista para seleccionar las partes). Se pueden especificar varios atributos de DN como respaldo. Por ejemplo: UID;SN;CN. Primero, pruebe con UID. Si no existe, pruebe con SN, etc.
ALEATORIO: generará un nombre de usuario aleatorio de 12 caracteres.
CORREGIDO: Ingrese los atributos DN manualmente como una cadena delimitada por punto y coma (por ejemplo, CN;UID;SN), en lugar de agregar los valores mediante el botón Agregar cuando se selecciona el botón de opción DN.
NOMBRE DE USUARIO: utilice el DN completo de la solicitud como nombre de usuario.

Prefijo de generación de nombres RA

Especifique un prefijo para el nombre de usuario generado. '${RANDOM}' se puede usar para tener 10 caracteres aleatorios como prefijo.

Sufijo de generación de nombres RA

Especifique un sufijo para el nombre de usuario generado. '${RANDOM}' se puede utilizar para tener 10 caracteres aleatorios como sufijo.

Nombre de RA CA

La CA desde la cual este alias emitirá el certificado.

Perfil de entidad final

El perfil de entidad final que se aplicará a las entidades finales que se inscriban. Define los campos de nombre DN y altName obligatorios.

Perfil del certificado

El perfil de certificado que se aplicará a las entidades finales que inscriban. Este controla el tipo de certificado, es decir, el uso de la clave y otras extensiones.

Requerir certificado de cliente

Especifica si se requiere un certificado de cliente para la inscripción. El certificado de cliente no necesita ser conocido por EJBCA (si la opción web.reqcertindb en conf/web.properties está establecida en falso), pero la CA emisora sí. El certificado de cliente debe pertenecer a un rol con plenos derechos de RA.

Nombre de usuario/contraseña del cliente

Establece un nombre de usuario y una contraseña para la inscripción. El nombre de usuario recibirá todos los derechos de RA. Si se requiere un certificado de cliente, se comprobarán tanto el certificado como el nombre de usuario y la contraseña para la inscripción inicial. Para la renovación (reinscripción), el nombre de usuario y la contraseña nunca son necesarios, pero el certificado de cliente siempre lo es.

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.


Si bien es posible configurar un alias EST sin nombre de usuario de cliente y sin requerir certificado de cliente, dicho alias EST no se puede utilizar ya que se requiere autenticación con certificado o nombre de usuario/contraseña para la inscripción inicial.

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, pueden realizarse mediante TLS, pero sin necesidad de autenticación del certificado de cliente. La llamada simpleenroll puede realizarse mediante TLS, con o sin autenticación del certificado de cliente (consulte las opciones de configuración anteriores). Sin embargo, una llamada a simplereenroll siempre requiere la autenticación del certificado de cliente para autenticarse con el certificado actual del cliente y aprobar automáticamente la renovación y emisión de un nuevo certificado.

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 de cliente sea opcional. Esta configuración del proxy de endpoint es fácil de realizar con Apache o Nginx y se utiliza en los productos Appliance y Cloud de PrimeKey.

Pruebas - Interoperabilidad del cliente

Cisco liberta

Clone libert de Cisco y compílelo según las instrucciones:

$ cd examples /client
$ # via environment specify the initial CA certificate to use for verifying TLS connection.
$ cp <path to server cert> server.pem
$ export EST_OPENSSL_CACERT=server.pem
$ # Where to save certs
$ mkdir certs
$ # Optionally get new CA certificates
$ . /estclient -g -s <ip or hostname to EJBCA> -p 8442 -o certs --pem-output
$ # certs should now contain a cacert-0-0.pem file
$ # enroll with CA. publicCert.pem and privetKey.pem are the TLS client cert I wish to use for auth. RequestDN will be 'CN=myclient'
$ . /estclient -e -s <ip or hostname to EJBCA> -p 8443 -o certs -c publicCert.pem -k privateKey.pem -u estadmin -h foo123 --pem-output --common-name myclient
$ # certs will now contain a cert-0-0.pem and key-xx.pem
$ # client cert is about to expire, reenroll, requires client certificate authentication to the server
$ . /estclient -r -s <ip or hostname to EJBCA> -p 8443 -o tmp -c tmp /cert-0-0 .pem -k tmp /key-xx .pem --pem-output
$ # certs should now contain an updated cert-0-0.pem

Rizo

También puede probar el acceso a las URL EST mediante comandos curl .

A continuación se muestra un ejemplo de flujo de trabajo completo que utiliza CURL, donde la inscripción inicial utiliza la autenticación EST de nombre de usuario/contraseña y la reinscripción utiliza el certificado de cliente existente.

# Get CA certificates
curl https: //<hostname to EJBCA>:8442/.well-known/est/<name of alias>/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 end entity profile.
openssl req -nodes -newkey rsa: 2048 -keyout device.key -out device.csr -outform DER -subj "/CN=123456789"
openssl base64 -in device.csr -out device.b64 -e
# Make initial enrollment, using EST password authentication (client certificate is also possible)
curl -v --cacert ManagementCA.cacert.pem --user estadmin:foo123 --data @device .b64 -o device-p7.b64 -H "Content-Type: application/pkcs10" -H "Content-Transfer-Encoding: base64" https: //<hostname to EJBCA>:8442/.well-known/est/<name of alias>/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
# 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=123456789"
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: //<hostname to EJBCA>:8443/.well-known/est/<name of alias>/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

ManagementCA.cacert.pem es el certificado de CA raíz de la cadena de CA que emitió el certificado de servidor TLS y debe configurarse con curl para establecer la conexión TLS. ManagementCA es el nombre en una instalación EJBCA predeterminada y el certificado puede descargarse desde la interfaz de usuario de la CA o la interfaz de usuario de la 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 servidor (cuando se utiliza un certificado de autenticación de cliente y una clave privada). El puerto TLS estándar, 443, se utiliza al ejecutar un proxy Apache en front-end o EJBCA, como en el caso de una instancia de EJBCA Enterprise Cloud o un dispositivo PrimeKey PKI. Para las instancias de EJBCA Enterprise Cloud o el dispositivo PrimeKey PKI, el puerto 443 funcionará para llamadas con o sin autenticación de certificado de cliente.

También puede autenticarse como administrador de EST con un certificado de cliente. El comando es ligeramente diferente: utiliza la autenticación por certificado además del nombre de usuario y la contraseña:

# Enroll
$ curl -v --cacert ManagementCA.cacert.pem --user estadmin:foo123 --cert ra-cert.pem --key ra-key.pem --data @device .b64 -o device-p7.b64 -H "Content-Type: application/pkcs10" \
-H "Content-Transfer-Encoding: base64" https: //<hostname to EJBCA>/.well-known/est/simpleenroll
# Re-enroll
$ 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: //<hostname to EJBCA>/.well-known/est/simplereenroll

Cliente Perl EST

Hay un cliente Perl EST muy completo y un conjunto de pruebas en https://github.com/killabytenow/pest .

Ejemplo de flujo de trabajo con pest que registra un dispositivo con un alias EST autenticado con nombre de usuario y contraseña. El cliente pest también admite la autenticación con certificado de cliente.

./pest --url https://localhost:8442/.well-known/est/estnew -C ~/tmp/ManagementCA.cacert.pem -O -o output cacerts
./pest --url https://localhost:8442/.well-known/est/estnew -C ~/tmp/ManagementCA.cacert.pem -u estadmin:foo123 -s "/CN=123456/O=PrimeKey/C=SE" -O -o output -B simpleenroll

La renovación se realiza mediante la autenticación del certificado de cliente TLS, utilizando el certificado antiguo y la clave privada.

./pest --url https: //localhost:8443/.well-known/est/estnew -C ~/tmp/ManagementCA.cacert.pem -c output/enroll-001.pem -k output/private.key -O -o output_new -B simplereenroll

También puede solicitar un cambio de nombre mediante el cliente pest, lo que genera un error 400 Bad Request de EJBCA ya que el certificado renovado debe tener el mismo DN de sujeto que el antiguo utilizado para la autenticación TLS.

./pest --url https: //localhost:8443/.well-known/est/estnew -C ~/tmp/ManagementCA.cacert.pem -c output/enroll-001.pem -k output/private.key -s "/CN=987654/O=PrimeKey/C=SE" -O -o output_new -B simplereenroll

Si usa un proxy frente a JBoss/WildFly, puede habilitar EST para que funcione en un solo puerto TLS (es decir, una URL simple como https://ejbca.example.com/ ). 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

Ejemplo de inscripción: una RA obtiene primero el certificado de la CA y luego el certificado del cliente mediante autenticación de usuario y contraseña (el cliente EST actúa como RA). 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

REAL ACADEMIA DE BELLAS ARTES

CA predeterminada

EST CA

Perfil de entidad final

Perfil EST EE (con solo el atributo DN requerido por CN)

Perfil del certificado

Perfil predeterminado

Requerir certificado de cliente

FALSO

Nombre de usuario del cliente

estado

Contraseña del cliente

foo123

Renovación de certificado con las mismas claves

FALSO

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

Ejecute los siguientes comandos estclient para generar una clave y obtener un certificado de la CA:

$ mkdir certs
# 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, by "RA", authenticated with username/password
$ . /estclient -e -s 127.0.0.1 -p 8442 -o certs -u estadmin -h foo123 --pem-output --common-name myclient
# 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:
$ . /estclient -r -s 127.0.0.1 -p 8443 -o certs -c certs /cert-0-0 .pem -k certs /key-xx .pem -u estadmin -h foo123 --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 certs /key-xx .pem --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
. /estclient -e -s 127.0.0.1 -p 8442 -o certs -u estadmin -h foo123 --pem-output --common-name myclient -x prime256v1-key.pem
$ 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 -x prime256v1-key.pem
$ openssl x509 - in certs /cert-0-0 .pem -text -noout