Servicios
El marco EJBCA para servicios de temporizador maneja procedimientos que se ejecutan de manera oportuna y realizan varias tareas en segundo plano.
Tipos de servicios
Los siguientes tipos de servicios están disponibles:
Nombre del servicio | Descripción |
Rellena una VA con certificados y CRL enviados desde una CA mediante SCP Publisher . | |
Comprueba si una CA tiene certificados a punto de caducar y envía una notificación por correo electrónico al usuario final y/o al administrador. | |
Descarga periódicamente una CRL de la URL proporcionada y la importa a EJBCA, actualizando también cualquier información de revocación de los certificados. | |
Comprueba si alguna de las CA configuradas necesita una nueva CRL y la genera si es necesario | |
El protocolo PKCS#11 es frágil en términos de tiempos de espera, por lo que este servicio probará periódicamente todos los tokens criptográficos disponibles realizando una firma de prueba para evitar tiempos de espera de sesión en el HSM. | |
Permite que EJBCA revoque certificados mediante Intune. Dado un inquilino de Intune, el service worker extrae solicitudes de revocación de Microsoft Intune y realiza la revocación de certificados internamente. | |
Descarga periódicamente claves públicas para los proveedores OAuth configurados y actualiza la configuración interna en consecuencia. | |
Genera, persiste y actualiza las respuestas OCSP para las CA configuradas. | |
Mantiene una cola de operaciones de publicación y reintenta periódicamente aquellas que han fallado. | |
Renueva automáticamente los certificados y claves de firma OCSP que vencen en un VA conectado. | |
Comprueba si los certificados de CA están a punto de caducar y los renueva automáticamente. | |
Comprueba periódicamente si hay alguna CA esperando a ser renovada si se ha instalado un certificado de renovación. | |
Comprueba si un usuario no se ha inscrito para obtener un nuevo certificado dentro de un plazo específico desde su última edición. Si no se ha inscrito en este plazo, su estado se establece en Generado y no podrá inscribirse. |
EJBCA también permite escribir complementos para servicios personalizados. Para más información, consulte "Escribir servicios personalizados" .
Configuración del servicio
Un servicio consta de los siguientes componentes: un trabajador que realiza el trabajo real, un intervalo que determina el tiempo hasta la próxima vez que debe ejecutarse el servicio y una acción opcional que debe realizarse si ocurre una determinada condición.
trabajadores
El trabajador es la clase que se ejecutará al ejecutarse el servicio. Cada trabajador puede tener una configuración específica diferente.
Intervalos
Intervalo periódico
Define en días/horas/minutos/segundos la frecuencia con la que se ejecutará el trabajador.
Un trabajador nunca debe configurarse para ejecutarse con una frecuencia mayor al tiempo que toma una sola invocación.
Comportamiento
Acción de correo
Acción que envía una notificación por correo electrónico cuando se ejecuta el servicio y tiene la siguiente configuración:
Dirección del remitente : la dirección de remitente utilizada en el correo electrónico.
Dirección del receptor : La dirección de correo electrónico no especificada por el trabajador.
Fijar a nodos específicos
Permite elegir en qué nodos se puede ejecutar el servicio. Si no se selecciona ningún nodo de la lista, el servicio puede ejecutarse en cualquiera de ellos.
Al iniciar EJBCA, cada nodo añade su nombre de host a la lista de nodos. Esta lista también se puede editar manualmente en la página Configuración del sistema.
Ejecutar en todos los nodos
De forma predeterminada, los servicios se ejecutan solo en un nodo del clúster o en uno de los nodos anclados. Sin embargo, ciertos servicios, como el servicio Keepalive del HSM, deben ejecutarse en todos los nodos.
Al seleccionar Ejecutar en todos los nodos se deshabilita la verificación de si un servicio se ha estado ejecutando en otro nodo y se ejecuta el servicio en todos los nodos.
La opción "Ejecutar en todos los nodos" normalmente solo debería estar habilitada para el servicio Keepalive del HSM . No la seleccione para ningún otro servicio a menos que esté completamente seguro de lo que hace.
Servicios múltiples y agrupamiento en clústeres
Un service worker, excepto el servicio HSM Keepalive, nunca debe ejecutarse simultáneamente en dos nodos (ni más de una instancia de un worker ejecutándose simultáneamente en un nodo). Para evitar que se ejecute más de una instancia en un solo nodo, existe un semáforo que impide que se ejecuten varias instancias del worker en una sola JVM. Si un worker se inicia y otro ya se está ejecutando, se reprograma para que se ejecute en el siguiente intervalo planificado y se finaliza inmediatamente. Para evitar la ejecución simultánea de dos servicios en dos nodos, el servicio tiene una marca de tiempo que se establece al ejecutarse y programa la siguiente ejecución antes de que comience el trabajo real. Esta marca de tiempo permite que otro nodo determine si el servicio ya se está ejecutando en otro nodo y, de ser así, no se inicia.
En la práctica, esto da como resultado que un servicio siempre se ejecutará en un solo nodo, el mismo nodo cada vez, pero el nodo en ejecución puede cambiar a veces.
En la mayoría de los casos, no es necesario anclar un servicio a un nodo específico. Algunas razones para anclar nodos son:
Servicios Keepalive de HSM: este servicio debe tener un servicio ejecutándose en cada nodo, ya que debe mantener activa la sesión PKCS#11 local.
Servicio de RA externo: Si se tienen varias RA y se ejecutan con frecuencia, podría haber una situación de competencia entre los servicios. Fijar la ejecución de servicios en diferentes nodos del clúster hacia diferentes RA externos puede aumentar el rendimiento y simplificar la ejecución.
Servicios de redacción personalizados
Es posible escribir complementos de componentes personalizados que se puedan utilizar con otros estándares (o complementos personalizados) y esta sección explica los pasos necesarios.
Todos los componentes tienen en común la necesidad de crear una clase que implemente la interfaz del componente. A continuación, se crea un archivo JAR especial que contiene las clases de complemento y los metadatos necesarios (descritos a continuación) e implementa el archivo en el servidor de aplicaciones para que se incluya en la ruta de clase. El siguiente paso es crear un servicio utilizando la clase personalizada y, opcionalmente, las propiedades personalizadas que utiliza el componente. El campo de propiedades tiene la misma sintaxis que un archivo de propiedades Java normal.
El archivo JAR debe contener metadatos que describan qué clases implementan qué interfaces. Esto es necesario, ya que EJBCA enumera todas las implementaciones mediante la función ServiceLoader de Java. Para cada interfaz implementada, el archivo JAR debe contener un archivo llamado META-INF/services/name.of.interface, por ejemplo, META-INF/services/org.ejbca.core.model.services.IWorker. Cada archivo debe contener una lista de clases implementadoras, una por línea. Por ejemplo:
# Example file. Should be named META-INF/services/org.ejbca.core.model.services.IWorkercom.example.ejbca.MyWorkercom.example.ejbca.MyOtherWorker No es posible implementar EJBCA en caliente cuando se utilizan servicios personalizados.
Trabajador personalizado
Un trabajador personalizado debe implementar la interfaz org.ejbca.core.model.services.IWorker. Una forma más sencilla es heredar la clase BaseWorker. Luego, se debe implementar un método, "void work()", que realiza el trabajo cada vez que el marco de servicio lo requiere. El método work puede llamar al componente de acción (opcional) mediante "getAction().performAction(someActionInfo);". La información de la acción puede variar según el componente, pero debe implementar la interfaz ActionInfo.CustomWorker.
Si algo sale mal durante el trabajo, ¿se debe lanzar una ServiceExecutionFailedException con un buen mensaje de error?
Consulte org.ejbca.core.model.services.workers.DummyWorker para ver un ejemplo de implementación.
Intervalo personalizado
Un intervalo personalizado debe implementar la interfaz org.ejbca.core.model.services.IInterval. Sin embargo, una forma más sencilla es heredar la clase BaseInterval. Luego, debe implementar el método "public long getTimeToExecution();", que debe devolver el tiempo en segundos hasta la próxima ejecución del servicio. O bien, debe devolver DONT_EXECUTE si el servicio debe detenerse.
Consulte org.ejbca.core.model.services.intervals.DummyInterval para ver un ejemplo de implementación.
Acción personalizada
Una acción personalizada debe implementar la interfaz org.ejbca.core.model.services.IAction.
Una forma más sencilla es heredar la clase BaseAction. En ese caso, solo es necesario implementar el método 'performAction(ActionInfo actionInfo)'. Los métodos deben ejecutar la acción según las propiedades definidas y la ActionInfo (todo opcional). Si se produce un error durante el procesamiento de la acción, se debe generar una ActionException.
Consulte org.ejbca.core.model.services.actions.DummyAction para ver un ejemplo de implementación.
Contenido relacionado
Para obtener información sobre cómo asegurarse de que su servicio de complemento se implemente con EJBCA, consulte Modificar EJBCA .