CUMBRE
EMPRESA Esta es una característica de EJBCA Enterprise.
El entorno de gestión automática de certificados (ACME) es un protocolo que una autoridad de certificación (CA) y un solicitante pueden utilizar para automatizar el proceso de verificación de la propiedad de un dominio (u otro identificador) y la gestión de certificados.
Operaciones apoyadas
La implementación ACME de EJBCA cumple actualmente con el estándar ACME final IETF - RFC8555 . Todas las operaciones deben llamarse mediante solicitudes POST. Para la operación de directorio, se ofrece una solicitud GET, y para la operación newNonce, también se ofrecen solicitudes GET y HEAD.
Operación | URL | Descripción | Referencia RFC 8555 |
directorio | /ejbca/acme/directorio | Obtenga el objeto de directorio que enumera todas las URL de operaciones de ACME y los metadatos de configuración de ACME. | |
nuevoNonce | /ejbca/acme/nuevoNonce | Antes de realizar cualquier acción POST, el cliente debe recuperar un nonce anti-reproducción del servidor. | |
nueva cuenta | /ejbca/acme/nuevaCuenta | Cree una nueva cuenta ACME o recupere una cuenta existente, incluida la URL y el ID de la cuenta. | |
actualizarCuenta | /ejbca/acme/acct/{ID de cuenta} | Actualizar o desactivar una cuenta existente. Cambiar su información de contacto o aceptar los nuevos Términos de Servicio de ACME si han cambiado. | |
nuevoOrden | /ejbca/acme/nuevoOrden | Cree una nueva orden ACME para uno o varios dominios (u otros identificadores). Este es el primer paso para solicitar la emisión de un certificado. | |
desafío | /ejbca/acme/acct/{accountId}/chall/{challengeId} | Dígale al servidor ACME que puede validar su respuesta de desafío y recuperar el objeto de desafío. | |
nueva autorización | /ejbca/acme/nueva autorización | Solo si la opción Preautorización permitida está habilitada en la configuración de Alias. | |
finalizarOrden | /ejbca/acme/acct/{idDeCuenta}/pedidos/{idDeOrden}/finalizar | Envíe su solicitud de firma de certificado (CSR) y deje que la CA emita su certificado. | |
revocar certificado | /ejbca/acme/revocar certificado | Revocar un certificado. | |
cambio de clave | /ejbca/acme/cambio de clave | Reemplazar la clave de una cuenta existente. | |
certificado | /ejbca/acme/cert/{ID del certificado} | Descargar un certificado. |
Puntos finales y alias de URL
El servicio ACME está disponible en las siguientes URL.
Algunos clientes ACME pueden cortar la cadena de consulta de URL ( ?configurationId=<alias_name> ). Use el estilo de URL con el alias especificado en la ruta de la URL.
Si el usuario agrega o elimina un alias, se establece como el alias ACME predeterminado, si la operación da como resultado exactamente un alias.
Un alias debe constar de 1 a 250 caracteres alfanuméricos (que no estén en blanco) que distingan entre mayúsculas y minúsculas, incluido el signo menos '-' y el guión bajo '_'.
Alias predeterminado con autenticación de cliente | https://<servidor>:8443/ejbca/acme/directorio |
Alias predeterminado sin autenticación de cliente | https://<servidor>:8442/ejbca/acme/directorio |
Alias personalizado <alias_name> con autenticación de cliente | https://<servidor>:8443/ejbca/acme/directorio?configurationId=<nombre_alias> |
Alias personalizado <alias_name> sin autenticación de cliente | https://<servidor>:8442/ejbca/acme/directorio?configurationId=<nombre_alias> |
Detalles específicos de EJBCA
Las aprobaciones en EJBCA para actualizar una entidad final o revocar un certificado no se pueden usar con ACME. Solo se admiten las aprobaciones para la gestión de cuentas de ACME.
Todas las operaciones ACME se realizan mediante el protocolo de pares. Por lo tanto, es perfectamente posible usar una RA externa que ejecute EJBCA como proxy ACME.
Los validadores para la verificación de CAA, etc. se configuran como se describe en Descripción general de validadores .
Debe configurar alias separados para cada perfil de entidad final/perfil de certificado y CA.
Las entidades finales se gestionan en modo RA, lo que significa que se crean o restablecen (estado = NUEVO) antes de inscribir un certificado. Esto implica que la función "Finalizar usuario" disponible en la configuración de la CA no afecta la inscripción de certificados con ACME (consulte Campos de la CA ). La generación por lotes (almacenamiento de contraseñas en texto plano) debe estar habilitada en el perfil de la entidad final.
Los recursos EJBCA ACME opcionales están disponibles con autenticación de cliente reforzada.
Especificaciones del cliente de ACME
Cada cliente ACME, como Certbot o acme.sh, podría requerir su propia restricción para inscribir certificados. Además, debe asegurarse de que la solicitud de certificado enviada por el cliente ACME cumpla con las restricciones de la CA y del perfil. Es decir, inscriba un certificado para varios identificadores, atributos DN adicionales del sujeto, validez del certificado o restricciones en la especificación de la clave utilizada.
Los atributos DN del sujeto y las entradas DNS del sujeto AN se configuran en los perfiles de entidad final. Para obtener más información, consulte Campos de los perfiles de entidad final y Configuración del perfil de entidad final .
La especificación de la clave y la validez del certificado (generalmente < 1 año, o 6 meses con Certbot 1.18) se configuran en los perfiles de certificado, consulte Campos del perfil de certificado .
Configuración
Configuración del perfil de entidad final
Además de los requisitos que dependen de su cliente ACME o de los requisitos individuales de su solicitud de certificado, se deben utilizar las siguientes configuraciones para un perfil de entidad final utilizado con ACME.
Un certificado registrado en ACME para un solo identificador debe tener al menos un campo SAN de dirección IP o DNS adicional.
Campo | Valor |
Nombre de usuario | Dejar en blanco |
Contraseña (o código de inscripción) | Dejar en blanco |
Generación por lotes (almacenamiento de contraseñas en texto sin formato) | Habilite esta opción si restablece la entidad final para la inscripción del certificado. Si no genera RANDOM con el esquema de generación de nombres de RA, debe habilitar esta opción. |
Correo electrónico de la entidad final | Uso, No Obligatorio, Modificable |
Atributos DN del sujeto | |
CN, Nombre común | Obligatorio, modificable |
Perfil de certificado predeterminado | <El perfil de certificado a utilizar> |
CA predeterminada | <La CA que firma el certificado> |
Token predeterminado | Generado por el usuario |
Otros atributos del sujeto | |
Nombre DNS o dirección IP de SAN | No obligatorio, modificable. Agregue tantos identificadores DNS o IP como necesite para sus certificados. |
Configuración del perfil del certificado
Además de los requisitos individuales de su cliente ACME o de su solicitud de certificado, se deben utilizar las siguientes configuraciones para un perfil de certificado utilizado con ACME.
Campo | Valor |
Algoritmos clave disponibles | Elija los algoritmos de clave permitidos |
Curvas ECDSA disponibles | Seleccione los algoritmos de clave ECDSA permitidos |
Longitudes de broca disponibles | Seleccione la longitud de clave deseada en el caso de claves RSA |
Validez o fecha de finalización del certificado | Validez. Es decir, 6 meses, 1 año o 395 días. |
Uso extendido de la clave | Autenticación del servidor |
Aprobaciones | Borrar. Asegúrese de no seleccionar ninguna aprobación , ya que EJBCA solo admite aprobaciones para la gestión de cuentas ACME. |
CA disponibles | <La CA que firma el certificado> |
Restricción de certificado activo único | Revoca todos los certificados previamente registrados de una entidad final registrada con este u otro perfil de certificado con esta opción habilitada. Solo es relevante si el nombre de la entidad final no se genera aleatoriamente mediante el esquema de generación de nombres de RA. |
Habilitación de ACME
El protocolo ACME está deshabilitado de forma predeterminada. Para habilitar el servicio, vaya a CA UI > Configuración del sistema > Configuración del protocolo y seleccione Habilitar para ACME .
Administración de configuraciones de alias de ACME
Al igual que otros protocolos en EJBCA, se pueden mantener varias configuraciones ACME diferentes al mismo tiempo utilizando alias.
Para configurar ACME, seleccione Configuración ACME en el menú Configuración del sistema .
Antes de poder utilizar un alias ACME, debe editarse y almacenarse, incluso si su configuración permanece sin cambios.
Campos globales
Los siguientes campos están definidos globalmente para todas las operaciones de ACME.
Campo | Descripción |
Configuración ACME predeterminada | La configuración a utilizar sin alias especificado. |
Número de validez de nonce de reproducción | Define la validez en milisegundos de un nonce de repetición generado. |
Configuración de alias de ACME
A continuación se muestra una configuración de alias ACME con selección de nombre de usuario por el atributo DN CN del sujeto y cualquier tipo de identificador DNS.

La siguiente tabla enumera los campos específicos de ACME para cada alias con más detalle.
Campo | 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 alternativa. Por ejemplo: UID;SN;CN. Primero, pruebe con UID. Si no existe, pruebe con SN, etc. Habilite la generación por lotes en el perfil de entidad final, si no utiliza nombres de usuario ALEATORIOS (consulte Configuración del perfil de entidad final ). |
Prefijo de generación de nombres RA | Especifique un prefijo para el nombre de usuario generado. '${RANDOM}' se puede usar para tener 12 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 12 caracteres aleatorios como sufijo. |
Perfil de entidad final | El perfil de entidad final que se usará para las entidades finales inscritas con este alias. La CA que firma el certificado es la CA predeterminada de este perfil de entidad final, y el perfil de certificado utilizado para el certificado es el perfil de certificado predeterminado de este perfil de entidad final. |
Preautorización permitida | Preautorización, según se define en la sección 7.4.1 del RFC 8555. El cliente de ACME puede autorizar los identificadores de los certificados antes de la creación del pedido. |
Se permite la emisión de certificados comodín | Si este alias se puede usar para emitir certificados con nombres DNS comodín en sus SAN. Consulte la sección 7.1.3 de RFC 8555 . |
Certificado comodín con desafío http-01 permitido | Si está deshabilitada, no se genera ningún desafío http-01 para identificadores con comodín (p. ej., *.primekey.com). Solo está activa si está habilitada la opción "Emisión de certificados con comodín permitida". Valor predeterminado: habilitado. |
Tipos de desafío de identificadores DNS | Seleccione "Cualquier tipo" para crear todos los tipos de desafío. Si solo se requiere un tipo de desafío específico, seleccione, por ejemplo, solo el desafío http-01 o dns-01 . |
URL del sitio | URL de un sitio web que describe esta CA. Opcional. Consulte la sección 7.1.1 del RFC 8555 . |
URL de las Condiciones del Servicio | URL de sus términos de servicio para ACME. Consulte la sección 7.1.1 del RFC 8555 . |
Cambios en la URL de los Términos de Servicio | URL para informar sobre cómo gestionar los cambios en sus términos de servicio para ACME. Consulte la sección 7.3.1 del RFC 8555 . |
Requerir la aprobación del cliente para cambios en los Términos de Servicio | Especifica si los usuarios deben aprobar la nueva versión si se modifica la URL de los Términos de Servicio. Valor predeterminado: habilitado. |
Aceptar los nuevos Términos de Servicio permitidos | Especifica si los usuarios pueden aceptar los nuevos Términos de Servicio después de modificarlos. Los clientes de ACME deben solicitar el recurso updateAccount con termsOfServiceAgreed establecido en verdadero. Si no se permite, los clientes deben solicitar una nueva cuenta (incluidas las nuevas claves). Solo está activo si la opción "Requerir aprobación del cliente para cambios en los Términos de Servicio" está habilitada. Valor predeterminado: habilitado. |
Resolución de DNS | Un solucionador de DNS específico, utilizado al procesar desafíos dns01. |
Puerto DNS | Puerto utilizado para comunicaciones DNS. |
Ancla de confianza DNSSEC | El ancla de confianza de la ICANN, configurable en caso de que alguna vez cambie. |
Reintentar después | Valor utilizado para indicar que el cliente debe volver a intentar sondear el punto final de autorización después de un tiempo (en segundos). El valor predeterminado es 0 y se utiliza principalmente para clientes como cert-manager, que envían solicitudes post-as-get mientras esperan que el servidor ACME prepare el desafío. |
Puertos de redireccionamiento autorizados | Lista de puertos autorizados para redirecciones del lado del cliente para la validación de desafío http-01 para identificadores DNS. El valor predeterminado es 22, 25, 80 y 443. Déjelo en blanco si no hay restricciones. |
Validez del pedido | Se debe completar el intervalo de tiempo dentro de los desafíos para los identificadores de pedidos. El formato es legible con precisión de segundos, es decir, 10 días 12 horas o 30 segundos 30 minutos 1 hora. La cadena de formato se normaliza al almacenar los datos del formulario. El valor predeterminado es 1 hora. |
Requerir aprobación para el registro de la cuenta | Perfil de aprobación que se aplicará para el registro de cuentas ACME; consulte Aprobaciones . Valor predeterminado: Ninguno. |
Requerir aprobación para el cambio de clave de cuenta | Perfil de aprobación que se aplicará al cambio de clave de cuenta ACME; consulte Aprobaciones . Valor predeterminado: Ninguno. |
Requerir certificado de cliente | El cliente ACME debe autenticarse utilizando un certificado de cliente válido y una autorización para ver, crear y editar entidades finales, así como para acceder a la CA firmante e inscribir certificados. |
DN de sujeto de CA raíz preferido | Si existen cadenas de certificados cruzados para la CA designada, esta configuración permite exigir una única cadena de certificados cruzados para todos los clientes que la soliciten. Su valor predeterminado es "default" y, para eliminar dicha restricción, elimine el valor y guarde la configuración. Cuando tiene un valor predeterminado, finalizeOrder contiene el enlace a la cadena con la cadena de certificados de CA predeterminada, y los encabezados de enlace en la respuesta del certificado contienen enlaces a cadenas alternativas, como se menciona en la sección 7.4.2 de la RFC 8555. Si se exige una cadena, finalizeOrder contiene el enlace a la cadena con la cadena cruzada configurada y la respuesta del certificado no incluye enlaces a cadenas de certificados alternativas. |
Requerir vinculación de cuenta externa | Vinculación de cuenta externa (EAB), según se define en la sección 7.4.3 del RFC 8555 . |
ACME con autenticación de cliente
Si se habilita la opción "Requerir certificado de cliente" , un cliente ACME requiere un certificado de cliente válido para la autenticación HTTPS y reglas de acceso suficientes para la inscripción o revocación de certificados, así como otras funciones disponibles con ACME. Si se revoca el certificado de cliente, las solicitudes a los recursos ACME fallarán con el mensaje de usuario "Este punto final ACME requiere autenticación de certificado de cliente".
ACME sobre pares con autenticación de certificado de cliente no debe requerir que el certificado de cliente se almacene en la RA (establezca web.reqcertindb en falso en web.properties).
Otorgue este conjunto de reglas de acceso al certificado de cliente utilizado para ACME.
/ca_functionality/crear_certificado/
/ra_funcionalidad/crear_entidad_final/
/ra_funcionalidad/editar_entidad_final/
/ra_funcionalidad/entidad_final_vista/
/ra_functionality/revocar_entidad_final/
/ca/${Nombre de la CA}/
/endentityprofilesrules/${Nombre de EEP}/create_end_entity/
/endentityprofilesrules/${Nombre de EEP}/edit_end_entity/
/endentityprofilesrules/${Nombre de EEP}/view_end_entity/
/endentityprofilesrules/${Nombre de EEP}/revoke_end_entity/
Administración de enlaces de cuentas externas de ACME (EAB)
Si la opción "Requerir enlace de cuenta externa" está deshabilitada, no se consideran las solicitudes EAB anidadas en la solicitud newAccount de ACME. De lo contrario, una solicitud newAccount de ACME sin una solicitud EAB anidada fallará con el código de estado HTTP 400 (Solicitud incorrecta) y el error de ACME "externalAccountRequired" si el cliente no envía un EAB válido con la solicitud newAccount.
EJBCA admite el EAB compatible con ACME con solicitudes EAB protegidas por MAC de clave simétrica. Además, EJBCA admite solicitudes EAB protegidas por firma de clave privada asimétrica.
Combine ACME EAB con la vinculación de cuentas generales
El EAB ACME con clave simétrica admite la combinación con enlaces de cuentas externas generales, consulte Enlaces de cuentas externas .
El identificador de clave codificado en base64Url del EAB de ACME debe coincidir con uno de los identificadores de enlace de cuenta externa, disponibles en el espacio de nombres del EAB configurado en el perfil de certificado correspondiente. No importa si la cuenta de ACME se registró con este identificador de clave o si el valor se almacenó después del registro.
ACME EAB con configuración de clave simétrica

EAB ACME inicial con configuración de clave simétrica.
ACME EAB compatible con RFC8555
Campo | Descripción |
Tipo EAB | Compatible con RFC8555 (MAC - clave simétrica) |
Generar clave | Genera una clave simétrica AES de 256 bits. La clave se almacena cifrada o no (véase Cifrar clave ). Se representa como un valor codificado en base64Url en el campo de texto Insertar clave base64Url . El hash SHA-1 de la clave AES se genera y se almacena como un valor codificado en base64Url como identificador de clave, y se representa en el campo de texto Identificador de clave tal cual. |
Identificador de clave | El identificador de la clave secreta de la clave simétrica. El valor no debe estar vacío, sino tener un máximo de 256 caracteres y estar codificado en base64URL. No es necesario que el valor sea una huella digital según ningún algoritmo conocido. Lo introduce el usuario. Dado que el EAB se almacena en la configuración del alias de ACME, EJBCA solo verifica que el mensaje EAB contenga el identificador de clave correcto. |
Algoritmo MAC | El algoritmo MAC secreto para firmar la solicitud EAB protegida por MAC (solo HS256 en ese momento). |
Cifrar clave | Cifra la clave compartida en el almacén de datos si se selecciona (se muestra en texto claro en la GUI). |
Clave de cifrado | El token criptográfico utilizado para cifrar/descifrar la clave compartida. |
Alias de clave de cifrado | El alias de clave del par de claves de tokens criptográficos utilizado para cifrar/descifrar la clave compartida. |
Cargar clave PEM/DER | <p
Cargue una clave AES simétrica codificada en PEM o DER o una secuencia de bytes. Si se carga una clave, no es necesario especificar la clave base64Url a continuación y se completa después de guardar el formulario. Para generar un archivo de clave AES de 192 bits, utilice 'openssl rand 192 > name.key' o 'cat /dev/urandom | head -c 192 > name.key'. |
Insertar clave base64Url | Clave simétrica. El valor no debe estar vacío (excepto si se carga un archivo), sino tener un máximo de 512 caracteres y estar codificado en base64. |
El identificador de clave , el algoritmo MAC y la clave de inserción base64Url deben compartirse con los titulares de cuentas ACME para solicitar un recurso newAccount con una solicitud EAB válida. Para obtener información sobre el formato del mensaje, consulte la solicitud newAccount con EAB conforme a RFC8555 .
ACME EAB con configuración de clave privada/pública asimétrica.

EAB ACME inicial con configuración de clave simétrica.
EAB protegido por firma de clave asimétrica
Campo | Descripción |
Tipo EAB | Certificado/Clave pública (firma de clave de cuenta asimétrica) |
Usar clave pública | Establézcalo como verdadero si desea cargar una clave pública o como falso si desea cargar un certificado X.509. Si se establece como verdadero y se carga un certificado, solo se almacena la clave pública y se genera la huella digital utilizando el algoritmo de firma seleccionado. |
Algoritmo de firma | El algoritmo de firma secreto para firmar la solicitud EAB protegida por firma. Solo se considera si se utiliza una clave pública. De lo contrario, este campo se rellenará con el algoritmo de firma del certificado después de guardar el formulario. |
Cargar clave pública o certificado PEM/DER | Cargue la clave pública RSA o ECDSA o el certificado X.509 con codificación PEM o DER. Si carga un certificado o una clave, los campos de texto "Clave pública o huella digital del certificado" e "Insertar clave pública PEM o certificado" a continuación no necesitan completarse manualmente, sino que se completan después de guardar el formulario. |
Clave pública o huella digital del certificado | La clave pública o huella digital del certificado. El valor no debe estar vacío, sino tener un máximo de 256 caracteres y estar codificado en base64URL. No es necesario que el valor sea una huella digital según ningún algoritmo conocido. El usuario puede sobrescribirlo. Dado que el EAB se almacena en la configuración del alias ACME, EJBCA solo verifica que el mensaje EAB contenga la información correcta. cadena. Esta cadena podría usarse como un mensaje secreto, que se transmite en un canal separado. |
Insertar clave pública PEM o certificado | Certificado X.509 con formato PEM o clave pública RSA o ECDSA, incluidos los límites. El valor no debe estar vacío, sino tener una longitud máxima de 4096 caracteres. |
La clave pública o huella digital del certificado , el algoritmo de firma (en caso de clave pública) y la clave pública PEM o certificado insertado deben compartirse con los titulares de cuentas ACME para solicitar un recurso de nueva cuenta con una solicitud EAB válida. La solicitud EAB debe firmarse con el algoritmo de firma del certificado o, en caso de clave pública, con la proporcionada por el usuario. Para más información sobre el formato del mensaje, consulte Solicitud de nueva cuenta con EAB y firma de clave asimétrica .
Identificadores y validación de desafíos
EJBCA actualmente admite la validación de identificadores de dominio e IP.
Los identificadores de dominio se pueden validar mediante el desafío http-01 o dns-01, según se define en la sección 8 del RFC 8555. Los identificadores IPv4 o IPv6 se pueden validar únicamente con el desafío http-01, según se define en la sección 5 del RFC 8738 (JDK8). La validación por desafío de identificadores IPv6 requiere un servidor de aplicaciones en ejecución con IPv6 habilitado (-Djava.net.preferIPv6Addresses=true, Wildfly14 solo funciona con IPv4 o IPv6).
Desafío HTTP (http01)
Si el cliente elige utilizar http-01 tipo desafío, pretende demostrar que controla el dominio o IP solicitado en el certificado aprovisionando un recurso bajo el mismo nombre de dominio o IP y puerto 80, es decir http://example.org/.well-known/acme-challenge.
Desafío de DNS (dns01)
Si el cliente opta por usar el tipo de desafío dns-01, se obliga a proporcionar un registro TXT con la misma respuesta de token descrita anteriormente. Según la RFC 8555, se requiere DNSSEC para los desafíos dns01.
Aprobaciones
Las aprobaciones se pueden utilizar con la gestión de cuentas ACME.
Aprobaciones para el nuevo recurso de cuenta
Si se utilizan aprobaciones para el recurso newAccount, las solicitudes a este recurso devuelven una respuesta HTTP 500 (Error interno del servidor) que incluye un mensaje de problema de ACME de tipo urn:ietf:params:acme:error:serverInternal que indica el estado de la solicitud de aprobación creada y su ID. Por ejemplo, "Se ha enviado una solicitud para registrar su cuenta ACME para su aprobación. RequestID=123456789" después de que se haya enviado la primera solicitud de recurso ACME. Las solicitudes posteriores devuelven respuestas con el mismo asunto que indican el estado de la solicitud de aprobación, ya sea PENDIENTE, RECHAZADO o EXPIRADO. Si la aprobación se acepta, una solicitud al recurso newAccount crea la cuenta y devuelve el HTTP 201 (Creado), como se esperaba. Si una aprobación ha expirado, ya no es posible registrar las claves para esta cuenta y se deben generar nuevas claves.
Aprobaciones para el recurso keyChange
Si se utilizan aprobaciones para el recurso keyChange, las solicitudes a este recurso devuelven una respuesta HTTP 500 (Error interno del servidor) que incluye un mensaje de problema ACME de tipo urn:ietf:params:acme:error:serverInternal que indica el estado de la solicitud de aprobación creada y su ID (véase el ejemplo en Aprobaciones para el recurso newAccount) . Si una solicitud de aprobación ha expirado, se renueva automáticamente al solicitar el recurso keyChange.
Condiciones de servicio
Al registrar inicialmente una cuenta ACME con el recurso newAccount, el titular debe aceptar las Condiciones de Servicio del servicio ACME. Si la opción "Requerir aprobación del cliente para cambios en las Condiciones de Servicio" está habilitada y estas han cambiado, no se podrá solicitar ningún recurso ACME, excepto newAccount. Para aceptar las nuevas Condiciones de Servicio del servicio ACME, los clientes deben registrar una nueva cuenta con el recurso newAccount (con nuevas claves) o aceptar las nuevas Condiciones de Servicio con el recurso updateAccount (consulte los ejemplos de flujo de trabajo ). Por lo tanto, la opción "Aceptar las nuevas Condiciones de Servicio" debe estar habilitada.
Compatibilidad con clientes ACME
EJBCA es compatible con los siguientes clientes ACME (incluidos en la lista de clientes ACME compatibles de Letsencrypt ). Para obtener información sobre la instalación y el uso, consulte la sección correspondiente del cliente ACME:
Interfaz de usuario Swagger
Swagger UI te permite visualizar e interactuar con los recursos de la API. El entorno de Swagger UI está disponible en tu navegador en la URL https://localhost:8443/ejbca/swagger-ui (utilice el puerto 8443 ya que ACME utiliza autenticación de certificado de cliente).
Puede cambiar entre mostrar ACME o la API REST mediante la interfaz de usuario Swagger. Seleccione una lista de especificaciones .

La interfaz de usuario Swagger solo está disponible si compila EJBCA en modo de no producción, es decir, con ejbca.productionmode=false configurado en conf/ejbca.properties .
La interfaz de usuario Swagger para ACME solo estará disponible si ACME está activado como protocolo; consulte Habilitación de ACME .
Ejemplos de solicitudes
A continuación, se enumeran las operaciones ACME necesarias para obtener un certificado. Para las solicitudes newAccount y revokeCert, DEBE haber un campo "jwk"; de lo contrario, un campo "kid".
Solicitud getDirectory
Devuelve las URL de cada operación ACME y los metadatos del servicio.
GET /acme/directory HTTP/ 1.1{ "newNonce" : "https://footrust.local:8443/ejbca/acme/newNonce" , "newAccount" : "https://footrust.local:8443/ejbca/acme/newAccount" , "newOrder" : "https://footrust.local:8443/ejbca/acme/newOrder" , "newAuthz" : "https://footrust.local:8443/ejbca/acme/newAuthz" , "revokeCert" : "https://footrust.local:8443/ejbca/acme/revokeCert" , "keyChange" : "https://footrust.local:8443/ejbca/acme/keyChange" , "meta" :{ "termsOfService" : "https://footrust.com/acme/terms" , "website" : "https://footrust.com" , "caaIdentities" :[ "footrust.com"], "externalAccountRequired" : false}} Solicitud de nueva cuenta
Crea una nueva cuenta ACME en EJBCA y la devuelve junto con la respuesta. EJBCA utiliza una clave pública para verificar el JWS (es decir, el elemento jwk del encabezado JWS) y autenticar futuras solicitudes de la cuenta. EJBCA admite los tipos de clave RSA y EC. Si la cuenta con esta clave ya existe, se devuelve junto con la respuesta.
POST https: //localhost:8442/ejbca/acme/newAccount HTTP/1.1Content-Type: application/jose+json{ "protected" : base64url({ "alg" : "ES256" , "jwk" : {...}, "nonce" : "6S8IqOGY7eL2lsGoTZYifg" , "url" : "https://example.com/acme/newAccount"}), "payload" : base64url({ "contact" : [ "mailto:cert-admin@example.com"], "termsOfServiceAgreed" : true}), "signature" : "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I"} Solicitud de nueva cuenta con EAB compatible con RFC8555
Crea una nueva cuenta ACME para EJBCA y la devuelve con la respuesta.
La solicitud EAB anidada se firma utilizando una clave simétrica y un algoritmo HMAC compartido por la CA.
POST https: //localhost:8442/ejbca/acme/newAccount HTTP/1.1Content-Type: application/jose+json{ "protected" : base64url({ "alg" : "ES256" , "jwk" : {...}, "nonce" : "6S8IqOGY7eL2lsGoTZYifg" , "url" : "https://example.com/acme/newAccount"}), "payload" : base64url({ "contact" : [ "mailto:cert-admin@example.com" , "tel:+12025551212"], "termsOfServiceAgreed" : true , "externalAccountBinding" : { "protected" : base64url({ "alg" : "HS256" , "kid" : /* key identifier from CA */ , "url" : "https://example.com/acme/newAccount"}), "payload" : base64url( /* same as in "jwk" above */ ), "signature" : /* MAC using MAC key from CA */}}), "signature" : "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I"} Solicitud de nueva cuenta con EAB con firma de clave asimétrica
Crea una nueva cuenta ACME para EJBCA y la devuelve con la respuesta.
La solicitud EAB anidada está firmada por el mismo JWK que firmó el mensaje externo. A diferencia de la solicitud EAB estándar (véase más arriba), esta carga útil contiene un mapa que incluye la clave de cuenta que se registrará. Además, este mapa contiene la clave pública o la huella digital del certificado compartida por la CA y la firma de la clave de cuenta mediante una clave privada compartida con la CA y el algoritmo de firma acordado.
POST https: //localhost:8442/ejbca/acme/newAccount HTTP/1.1Content-Type: application/jose+json{ "protected" : base64url({ "alg" : "ES256" , "jwk" : {...}, "nonce" : "6S8IqOGY7eL2lsGoTZYifg" , "url" : "https://example.com/acme/newAccount"}), "payload" : base64url({ "contact" : [ "mailto:cert-admin@example.com" , "tel:+12025551212"], "termsOfServiceAgreed" : true , "externalAccountBinding" : { "protected" : base64url({ "alg" : "HS256" , "url" : "https://example.com/acme/newAccount"}), "payload" : base64url({ "key" : / * same as in "jwk" above * /, "cf" : / * certificate or huella digital de clave public key fingerprint shared by the CA * /, "aks" : / * signature of the account key using the signature algorithmand clave private key corresponding to the clave public key sent to the ACME CA * /,}), "signature" : / * MAC using same MAC key that signed the outer JWS message. * /}), "signature" : "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I"} Solicitud de actualización de cuenta
Actualiza la información de contacto de una cuenta ACME.
POST https: //localhost:8442/ejbca/acme/acct/evOfKhNU60wg HTTP/1.1Content-Type: application/jose+json{ "protected" : base64url({ "alg" : "ES256" , "kid" : "https://example.com/acme/acct/evOfKhNU60wg" , "nonce" : "6S8IqOGY7eL2lsGoTZYifg" , "url" : "https://example.com/acme/acct/evOfKhNU60wg"}), "payload" : base64url({ "contact" : [ "mailto:cert-admin@example.com" ,]}), "signature" : "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I"} Solicitud de actualización de cuenta y aceptación de los nuevos Términos de servicio
Actualiza un acuerdo ACME a los nuevos Términos de Servicio si han cambiado. Esta función no cumple con la RFC. Para usar esta nueva solicitud de Cuenta, deben estar habilitadas las opciones "Requerir aprobación del cliente para cambios en los Términos de Servicio" y "Aceptar los nuevos Términos de Servicio" .
POST https: //localhost:8442/ejbca/acme/acct/evOfKhNU60wg HTTP/1.1Content-Type: application/jose+json{ "protected" : base64url({ "alg" : "ES256" , "kid" : "https://example.com/acme/acct/evOfKhNU60wg" , "nonce" : "6S8IqOGY7eL2lsGoTZYifg" , "url" : "https://example.com/acme/acct/evOfKhNU60wg"}), "termsOfServiceAgreed" : true}), "signature" : "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I"} Solicitud de actualización de cuenta y desactivación de cuenta
Desactiva una cuenta ACME (no reversible).
POST https: //localhost:8442/ejbca/acme/acct/evOfKhNU60wg HTTP/1.1Content-Type: application/jose+json{ "protected" : base64url({ "alg" : "ES256" , "kid" : "https://example.com/acme/acct/evOfKhNU60wg" , "nonce" : "ntuJWWSic4WVNSqeUmshgg" , "url" : "https://example.com/acme/acct/evOfKhNU60wg"}), "payload" : base64url({ "status" : "deactivated"}), "signature" : "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I"} Solicitud de nuevo pedido
Crea una nueva orden ACME.
POST /acme/newOrder HTTP/ 1.1Content-Type: application/jose+json{ "protected" : base64url({ "alg" : "ES256" , "kid" : "https://example.com/acme/acct/evOfKhNU60wg" , "nonce" : "5XJ1L3lEkMG7tR6pA00clA" , "url" : "https://example.com/acme/new-order"}), "payload" : base64url({ "identifiers" : [{ "type" : "dns" , "value" : "www.example.org" },{ "type" : "dns" , "value" : "example.org" }], "notBefore" : "2016-01-01T00:00:00Z" , "notAfter" : "2016-01-08T00:00:00Z"}), "signature" : "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"}La respuesta newOrder contiene información sobre los desafíos. Para más información, consulte la sección 7.5.1 del RFC 8555.
Solicitud de nueva autorización
Solicitar una preautorización para un identificador (una solicitud por identificador).
POST /acme/newAuthz HTTP/ 1.1Host: example.comContent-Type: application/jose+json{ "protected" : base64url({ "alg" : "ES256" , "kid" : "https://example.com/acme/acct/evOfKhNU60wg" , "nonce" : "uQpSjlRb4vQVCjVYAyyUWg" , "url" : "https://example.com/acme/newAuthz"}), "payload" : base64url({ "identifier" : { "type" : "dns" , "value" : "example.org"}}), "signature" : "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"} solicitud de desafío
Llame al servicio ACME de EJBCA para verificar la respuesta al desafío, que demuestra que posee control sobre el dominio.
POST /acme/acct/{accountId}/chall/{challengeId} HTTP/ 1.1Content-Type: application/jose+json{ "protected" : base64url({ "alg" : "ES256" , "kid" : "https://example.com/acme/acct/evOfKhNU60wg" , "nonce" : "Q_s3MWoqT05TrdkM2MTDcw" , "url" : "https://example.com/acme/chall/prV_B7yEyA4"}), "payload" : base64url({}), "signature" : "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"} solicitud de finalización de pedido
Para generar el certificado.
POST /acme/acct/{accountId}/orders/{orderId}/finalize HTTP 1.1Content-Type: application/jose+json{ "protected" : base64url({ "alg" : "ES256" , "kid" : "https://example.com/acme/acct/evOfKhNU60wg" , "nonce" : "MSF2j2nawWHPxxkE3ZJtKQ" , "url" : "https://example.com/acme/order/TOlocE8rfgo/finalize"}), "payload" : base64url({ "csr" : "MIIBPTCBxAIBADBFMQ...FS6aKdZeGsysoCo4H9P" ,}), "signature" : "uOrUfIIk5RyQ...nw62Ay1cl6AB"}La respuesta a la llamada finalizeOrder es el certificado.
Códigos de estado HTTP
Código de estado HTTP | Descripción |
200 | Éxito |
201 | Creado |
204 | Sin contenido |
400 | Solicitud incorrecta |
401 | No autorizado |
403 | Prohibido |
404 | Extraviado |
409 | Conflicto |
500 | Error Interno del Servidor |