Resumen de las notas de actualización de EJBCA
A continuación, se resumen las notas de actualización de todas las versiones de EJBCA publicadas. Para obtener más información sobre una versión específica, consulte las notas de actualización de EJBCA correspondientes .
Para obtener instrucciones de actualización e información sobre las rutas de actualización, consulte Actualización de EJBCA . Para obtener información detallada sobre las nuevas funciones y mejoras de la versión correspondiente, consulte las Notas de la versión de EJBCA .
EJBCA 7.9.x a EJBCA 7.10
Publicar actualización
Al actualizar a EJBCA 7.10.0.1, debe realizar una actualización posterior. Esta actualización es necesaria para la preautorización de ACME. Si no se realiza, la creación de órdenes fallará para los identificadores preautorizados y el cliente ACME deberá solicitar una nueva autorización. Las preautorizaciones de ACME caducan a las 24 horas. Para evitar estos casos, deshabilite el protocolo ACME (en Configuración del sistema EJBCA > Configuración del protocolo > ACME ). antes de la actualización y vuelva a habilitarlo una vez que se complete la actualización posterior.
Para realizar la actualización posterior, haga clic en la opción de menú Actualización del sistema EJBCA y, a continuación, en Iniciar actualización posterior . Para obtener más información, consulte Actualización de EJBCA .
Cambios de comportamiento
Producir respuestas OCSP firmadas previamente solo para certificados no vencidos
El trabajador de prefirma de respuestas de OCSP ahora genera respuestas para certificados vigentes y actualiza las respuestas caducadas para los certificados vigentes. Los certificados caducados seguirán recibiendo respuestas de OCSP generadas en línea. Para obtener más información, consulte Prefirma de respuestas de OCSP .
Mejoras en la importación de ConfigDump
La herramienta ConfigDump de EJBCA ahora solo importará o actualizará miembros de roles si el token utilizado es importante para el rol que se actualiza. Un token se considera importante para un rol si los derechos de acceso que le otorga no se duplican en otro rol que tenga el mismo token como miembro. Para más información, consulte la herramienta ConfigDump.
Reglas de acceso más precisas para la GUI de RA
Se han añadido las reglas de acceso /ca_functionality/use_username y /ca_functionality/use_approval_request_id , que corresponden a las páginas con el mismo nombre en la interfaz de usuario de RA EJBCA. Estas reglas de acceso se añaden automáticamente a todos los roles con acceso /ca_functionality/create_certificate . Para obtener más información, consulte Reglas de acceso y Reglas de acceso del administrador de RA .
Nueva extensión agregada de forma predeterminada durante la inscripción automática de MS
Para abordar una vulnerabilidad reciente descubierta en la autenticación basada en certificados de Microsoft, EJBCA ahora admite la nueva extensión szOID_NTDS_CA_SECURITY_EXT , que asigna el certificado a un objeto de usuario/equipo de Active Directory. La extensión se habilitará de forma predeterminada para todos los perfiles de certificado y se incluirá en los certificados inscritos mediante la integración de la inscripción automática de Microsoft de EJBCA. La inscripción mediante otros endpoints y protocolos no se ve afectada. Para obtener más información, consulte Extensión de seguridad ObjectSid de Microsoft en los campos del perfil de certificado .
Desusos
Inscripción automática basada en scripts
Se ha eliminado la inscripción automática heredada basada en scripts (relevante antes de que la inscripción automática de Microsoft se integrara en EJBCA). Para obtener más información sobre la inscripción automática en EJBCA, consulte Descripción general de la inscripción automática de Microsoft .
Herramienta CLI de validación
La CLI de validación heredada no ha recibido soporte durante varios años y se eliminará en esta versión para ser eliminada en la próxima versión principal/de funciones.
EJBCA 7.8.x a EJBCA 7.9.0
EJBCA 7.8.2 a EJBCA 7.9.0
Cambios de comportamiento
Declaración de restricciones de nombre de URI en la interfaz de usuario
Se actualizó la gestión de las restricciones de nombre URI en la interfaz de usuario. Anteriormente, se preveía que el protocolo formara parte de la restricción de nombre, lo cual no cumplía con la RFC 5280. Este comportamiento se ha modificado en la interfaz de usuario, pero no afecta a las restricciones de nombre declaradas mediante WS o REST.
Ya no se requieren los accesos "Ver entidad final" y "Eliminar entidad final" para la inscripción desde la GUI de RA
En versiones anteriores de EJBCA, era necesario otorgar acceso "Eliminar entidad final" para que un rol pudiera crear solicitudes de certificado en la interfaz gráfica de RA. Además, se requería el acceso "Ver entidad final" al inscribirse mediante CSR. A partir de EJBCA 7.9.0, ninguna de estas reglas de acceso es necesaria, y solo se necesita el acceso "Crear entidad final" . Para obtener más información, consulte "Reglas de acceso de administrador de RA" .
Uso recomendado de scripts Bash agrupados con aplicaciones CLI
Si ejecuta una de nuestras diversas aplicaciones CLI, como el verificador CAA, la CLI EJBCA o ClientToolBox, le recomendamos encarecidamente ejecutar el script .sh incluido en lugar de ejecutar la aplicación directamente desde la línea de comandos con java -jar . Si lo hace, tenga en cuenta que debe añadir la opción -Dlog4j1.compatibility=true al comando.
Nuevas API de Microsoft Azure
A partir de la versión 7.9, EJBCA ya no utiliza la biblioteca ADAL obsoleta para acceder a las API de Microsoft Azure. Si su instalación de EJBCA utiliza Intune SCEP, el Servicio de Revocación de Certificados de Microsoft Intune o el Publicador de CRL de Azure, es posible que deba actualizar su configuración.
Además, si está utilizando un par para cualquiera de los servicios anteriores, tanto el par como la CA principal deberán ejecutar al menos la versión EJBCA 7.9.
Desusos
GUI de RA externa heredada
La sección UI del RA externo heredado (que se recomendaba antes de la implementación del RA EJBCA) ha quedado obsoleta y se ha eliminado.
GUI de inscripción por lotes
La GUI de inscripción por lotes no ha recibido soporte durante varios años y ahora se ha dejado de usar y se ha eliminado .
EJBCA 7.8.1 a EJBCA 7.8.2
Uso recomendado de scripts Bash agrupados con aplicaciones CLI
Si ejecuta una de nuestras diversas aplicaciones CLI, como el verificador CAA, la CLI EJBCA o ClientToolBox, le recomendamos encarecidamente ejecutar el script .sh incluido en lugar de ejecutar la aplicación directamente desde la línea de comandos con java -jar. Si lo hace, tenga en cuenta que debe añadir la opción -Dlog4j1.compatibility=true al comando.
EJBCA 7.8.0 a EJBCA 7.8.1
Se ampliaron los límites de tamaño del perfil de entidad final
Los perfiles de entidad final se han actualizado para admitir hasta 10 000 campos SDN, SAN o SDA.
Tenga en cuenta que las exportaciones realizadas mediante StateDump o la interfaz de usuario de CA anteriores a la versión 7.8.1 dejarán de ser válidas tras este cambio. Las exportaciones de ConfigDump no se verán afectadas.
EJBCA 7.7.0 a EJBCA 7.8.0
Acciones de actualización
El reclamo de AUD debe configurarse para los proveedores de OAuth antes de la actualización posterior
Al actualizar a EJBCA 7.8.0, se añadirá un nuevo campo a cada proveedor de OAuth definido que defina una reclamación de Audiencia . Tras la actualización, no se ejecutará hasta que este campo se complete para todos los proveedores de OAuth definidos.
<p La verificación de la reclamación aud para todos los usuarios autenticados con OAuth comenzará después de ejecutar la actualización. Si no se han definido proveedores de OAuth, este paso puede omitirse.Cambios de comportamiento
Inscripción al Certificado ACME
Los perfiles de entidad final utilizados para la inscripción de certificados ACME deben tener habilitada la opción Generación por lotes (almacenamiento de contraseñas en texto sin cifrar) . Para obtener más información, consulte Configuración de perfiles de entidad final en ACME .
Cambios en la base de datos
Se agregó tabla para el seguimiento de operaciones de emisión abortadas
Se ha agregado una nueva tabla, IncompleteIssuanceJournalData , para rastrear operaciones de emisión de certificados fallidas o canceladas cuando se utiliza la transparencia de certificados.
Al igual que otras tablas, esta tabla se crea de forma predeterminada al iniciar.
Las definiciones de tablas están disponibles en doc/sql-scripts/create-tables-ejbca-*.sql
Notas importantes
Mejorar la fiabilidad de la publicación directa
Esta sección solo es relevante cuando se utiliza la publicación directa.
Se ha añadido la opción " Usar publicación directa segura" a los publicadores. Con esta opción habilitada, EJBCA escribirá temporalmente los certificados en la cola de publicadores incluso si la publicación directa está habilitada, de modo que la publicación pueda reanudarse en caso de que la transacción falle.
Además, esta opción hace que la operación de emisión finalice justo antes de que se produzca la publicación directa, en lugar de después.
Se recomienda habilitar la opción "Usar publicación directa segura" para los editores que utilizan la publicación directa y requieren la máxima fiabilidad. En el caso de algunas PKI de alto volumen, esto puede provocar una ligera disminución del rendimiento.
Mejora de la fiabilidad de la presentación de certificados de transparencia
Esta sección solo es relevante cuando se utilizan marcas de tiempo de transparencia de certificados (SCT) en los certificados.
A partir de EJBCA 7.8.0, EJBCA mantiene un diario (en IncompleteIssuanceJournalData ) de precertificados, de modo que se puedan revocar si ocurre una interrupción después de la generación del precertificado, pero antes de que finalice la generación del certificado final.
Se ha añadido un nuevo tipo de Servicio, Servicio de Revocación de Precertificados , que revoca los precertificados después de un tiempo definido (por defecto 30 minutos), si la operación de emisión no ha finalizado.
Se recomienda agregar el Servicio de revocación de precertificado si se utilizan marcas de tiempo de transparencia de certificados en los certificados.
EJBCA 7.6.0 a EJBCA 7.7.0
Cambios de comportamiento
Aprobaciones para la gestión de cuentas ACME
La implementación ACME de EJBCA ahora admite aprobaciones para los recursos newAccount y keyChange.
Esquema de generación de nombres RA para ACME
El nombre de las entidades finales utilizadas para emitir certificados con la implementación ACME de EJBCA se puede determinar mediante un esquema de generación de nombres. Esta funcionalidad admite prefijos y sufijos con nombres de entidad finales aleatorios, constantes o derivados de los atributos del DN del sujeto, como el CN u otros.
EJBCA 7.5.x a EJBCA 7.6.0
Cambios de comportamiento
Registro de OCSP configurable en la GUI
La configuración del registro de auditoría y del registro de transacciones de OCSP ahora se configura en la interfaz gráfica de usuario de EJBCA en lugar del archivo de configuración ocsp.properties (consulte Administración del respondedor de OCSP) . La configuración existente en ocsp.properties se migra a la base de datos al implementar EJBCA 7.6.0 por primera vez. La propiedad ocsp.log-timezone se ignora y se utiliza la zona horaria especificada en ocsp.log-date .
Aplicación más estricta de la ejecución de scripts desde el editor personalizado de propósito general
Se ha mejorado la aplicación de qué scripts locales se pueden ejecutar desde los publicadores personalizados de propósito general para verificar la habilitación de scripts y la inclusión de una lista de permitidos cada vez que se ejecuta el publicador. Si utiliza un publicador personalizado de propósito general para ejecutar scripts localmente en la CA, verifique que el acceso a los scripts esté habilitado en la configuración del sistema EJBCA ( Configuración del sistema → Scripts externos → Habilitar acceso a scripts externos) . Si los scripts están habilitados y no se aplica ninguna lista de permitidos, el cambio no le afectará. Si los scripts están habilitados y se aplica una lista de permitidos, asegúrese de que el script ejecutado esté en dicha lista.
Enmascaramiento de contraseña adicional en ConfigDump y Statedump
Las exportaciones de ConfigDump incluían previamente ciertas contraseñas que permitían importarlas a otros entornos. A partir de EJBCA 7.6.0, todas las contraseñas están enmascaradas. Esto significa que ahora debe editar el archivo de configuración exportado antes de la importación o editar los valores en EJBCA después de la importación. Para más información, consulte la herramienta ConfigDump .
Las contraseñas de alias se exportan cifradas en la herramienta Statedump . Si se importa un archivo de configuración de Statedump a un sistema con una clave de cifrado diferente, la entrada no se puede descifrar y, en su lugar, se usará la cadena hexadecimal con el cifrado (anterior) como contraseña de alias. Puede editar las contraseñas en los archivos XML de Statedump antes de importarlas o cambiarlas después de la importación mediante la CLI de EJBCA o la interfaz de usuario de CA.
Revocación de CMP: aplicación de controles multiinquilino al emitir un perfil de entidad final
Al usar una RA que llama a EJBCA con CMP y utiliza la autenticación de certificado de cliente (mensajes CMP firmados), las solicitudes de revocación ahora siempre controlan la autorización de la RA contra el perfil de entidad final utilizado para emitir el certificado. Esto permite la separación de las RA según los perfiles de entidad final. Tenga en cuenta que si dependía únicamente del privilegio de revocación para las RA, esto podría impedir la revocación si sus reglas de acceso no permiten la revocación desde los mismos perfiles de entidad final para los que se permite la emisión.
Uso extendido de claves aplicado para conexiones entre pares
Debido a un problema en versiones anteriores de EJBCA, las conexiones entre pares salientes aceptarían certificados de servidor que tuvieran una extensión de Uso de clave extendido (EKU), pero sin el valor de Autenticación del servidor.
La extensión del certificado EKU ya está implementada. Esto afecta solo a los sistemas con extensiones de certificado EKU configuradas incorrectamente. Los sistemas con extensiones de certificado EKU configuradas correctamente no requerirán ningún cambio.
EJBCA 7.5.0.1 a EJBCA 7.5.1
Cambios de comportamiento
Ahora se aplica el uso extendido de claves para conexiones entre pares
Debido a un error en versiones anteriores de EJBCA, las conexiones entre pares salientes aceptarían certificados de servidor que tuvieran una extensión de Uso de clave extendido (EKU), pero sin el valor de Autenticación del servidor.
La extensión del certificado EKU ya está implementada. Esto afecta solo a los sistemas con extensiones de certificado EKU configuradas incorrectamente. Los sistemas con extensiones de certificado EKU configuradas correctamente no requerirán ningún cambio.
EJBCA 7.4.x a EJBCA 7.5.0.1
A continuación se presentan cambios y requisitos importantes al actualizar de EJBCA 7.4 a EJBCA 7.5.0.1.
EJBCA 7.5.0 fue una versión interna, que generalmente no estaba disponible para los clientes.
Cambios en la base de datos
EJBCA 7.5.0.1 contiene las nuevas columnas accountBindingId en CertificateData y tokenProviderId en RoleMemberData, así como subjectDn y email en ApprovalData (agregado en EJBCA 7.4.3).
Hibernate crea automáticamente las columnas al implementar EJBCA 7.5.0.1 por primera vez. Sin embargo, si el usuario de la base de datos EJBCA no tiene privilegios GRANT, deberá ejecutar los comandos ALTER en los scripts SQL de actualización antes de implementar EJBCA. Los scripts SQL se encuentran en doc/sql-scripts/ .
Cambios de comportamiento
Nueva propiedad web de autenticación segura
Para admitir la autenticación con certificado y token OAuth2, se agregó una nueva propiedad web.reqauth al archivo de configuración web.properties, que reemplaza y deja obsoleta la propiedad anterior web.reqcert.
La nueva propiedad web.reqauth aplica la autenticación segura mediante el certificado TLS del cliente o el token OAuth2 para acceder a la interfaz de administración de EJBCA. El cambio es compatible con versiones anteriores, por lo que la antigua propiedad web.reqcert puede seguir utilizándose en las configuraciones existentes. Sin embargo, tenga en cuenta que las nuevas instalaciones solo deben usar la propiedad web.reqauth .
Manejo mejorado de aprobaciones de RA y CA
Las aprobaciones de RA y CA ahora se gestionan en sus respectivas interfaces de usuario.
Aprobaciones relacionadas con RA trasladadas a la interfaz de usuario de RA
Las aprobaciones para las siguientes acciones ahora se gestionan mediante la interfaz de usuario de RA y ya no aparecen en la interfaz de usuario de CA:
Agregar/Editar entidad final
Recuperación de claves
Revocación
Aprobaciones relacionadas con CA trasladadas a CA UI
Las aprobaciones relacionadas con la CA se muestran en la interfaz de usuario de la CA ( Funciones de supervisión > Aprobar acciones ) y las aprobaciones para la activación del token de CA ya no aparecen en la interfaz de usuario de RA. Para obtener más información, consulte Aprobar acciones .
Codificación predeterminada del texto del aviso de política. La extensión del certificado X.509 se cambió a UTF-8.
Al crear una nueva CA, la opción " Usar UTF-8 en el texto del aviso de política" tenía el valor predeterminado " falso" para ser compatible con versiones anteriores de Windows. Dado que Windows ahora admite la codificación UTF-8 estándar, el valor predeterminado de " Usar UTF-8 en el texto del aviso de política" se ha cambiado a "verdadero " (habilitado). Este cambio solo se aplica a la creación de nuevas CA; los valores de las CA existentes no se modifican.
Se eliminó la compatibilidad con la inscripción nativa del navegador
Se ha eliminado la opción Crear certificado de navegador del menú Web público porque los navegadores relevantes ya no admiten esta funcionalidad.
Edición eIDAS
Si se actualiza una instalación de software de la edición EJBCA eIDAS , se deben habilitar las siguientes dos opciones en conf/web.properties para que las opciones de Utimaco CP5 HSM sean visibles en la interfaz de usuario de administración al crear nuevos tokens criptográficos y activar claves en tokens criptográficos.
p11ng.cryptotoken.enabled= truep11ng.utimacocp5.enabled= true EJBCA 7.4.2 a EJBCA 7.4.3
Cambio de protocolo de conector de pares incompatible con versiones anteriores que afecta a EST
Se requirió un cambio incompatible con versiones anteriores en el protocolo del conector de pares para reforzar la seguridad del dominio de las RA. Este cambio afecta la transmisión de EST de la RA a la CA y se implementó añadiendo una nueva llamada de método al protocolo y deshabilitando la anterior.
Para evitar problemas de actividad durante la actualización:
Actualice las RA antes de actualizar la CA
oSi desea actualizar la CA antes de la RA o ejecutar RAs en la versión 7.4.2 o anterior, con una CA en la versión 7.4.3 o posterior, debe establecer la propiedad raapi.legacyest.enabled=true en el archivo de configuración conf/web.properties y, a continuación, reconstruir e implementar EJBCA para volver a habilitar la antigua llamada al método EST. Tenga en cuenta que la antigua llamada al método no aplica la seguridad del dominio de la RA; es decir, no se aplicarán las restricciones establecidas en el rol de conector de pares.
Conmutación por error para el servicio de actualización de CRL
El servicio de actualización de CRL conmutará a otro nodo del clúster si no puede completar su trabajo. Antes de ejecutarse, comprobará si la clave de firma de CRL es accesible mediante una firma de prueba. Si al menos una clave de firma de CRL de una CA activa es inaccesible, el trabajo se pospone para que otro nodo del clúster pueda ejecutar el servicio. En versiones anteriores de EJBCA, el servicio fallaba y volvía a ejecutarse en el mismo nodo.
Un efecto secundario importante a tener en cuenta es que si una CA no puede acceder a una clave de firma de CRL, se bloqueará la emisión de CRL para todas las CA de esa instancia. Si la clave de firma de CRL es accesible en otro nodo del clúster, el trabajo se transferirá automáticamente. De lo contrario, debe desactivar la CA cuya clave de firma de CRL es inaccesible para que el servicio pueda volver a ejecutarse.
Publicar actualización
Al ser una versión menor, no se requiere ninguna actualización posterior.
EJBCA 7.4.1 a EJBCA 7.4.2
Las respuestas de OCSP ya no incluyen el código de motivo no especificado
A partir de EJBCA 7.4.2, las respuestas de OCSP donde se revoca el certificado con el código de motivo "No especificado" ya no incluirán el atributo de código de motivo.
Este cambio es necesario para cumplir con los cambios en los Requisitos básicos del foro CA/B versión 1.7.1, vigentes a partir del 30 de septiembre de 2020.
Publicar actualización
Al ser una versión menor, no se requiere ninguna actualización posterior.
EJBCA 7.4.0 a EJBCA 7.4.1
Actualización de caché de firma OCSP deshabilitada de forma predeterminada
A partir de EJBCA 7.4.1, la actualización de la caché de firmas OCSP no se realiza de forma predeterminada si se desconoce la CA emisora del certificado. Esto mejora el rendimiento (al reducir las visitas a la base de datos) cuando EJBCA gestiona solicitudes OCSP, especialmente en entornos agrupados.
Para habilitar la actualización de la caché de firmas de OCSP y restaurar el comportamiento anterior si es necesario, seleccione la opción Habilitar actualización de la caché de firmas de OCSP (deshabilitada de forma predeterminada) en la sección de configuración global de OCSP ( Funciones del sistema > Atajos de teclado internos > OcspKeyBinding ). Para obtener más información, consulte Administración del respondedor de OCSP .
Publicar actualización
Al ser una versión menor, no se requiere ninguna actualización posterior.
EJBCA 7.3.x a EJBCA 7.4.0
Procedimientos requeridos
En versiones de EJBCA anteriores a la 7.4.0, los procesadores de solicitudes (definidos por la interfaz org.cesecore.certificates.ca.ExtendedUserDataHandler ) se definían estableciéndolos como la propiedad certreqhandler.class para alias de CMP individuales. En EJBCA 7.4.0, el uso de los procesadores de solicitudes se ha extendido también a las API REST y WS, por lo que su configuración se ha trasladado a las CA individuales. Este cambio no se puede realizar automáticamente, por lo que para seguir usando los procesadores de solicitudes en instalaciones existentes, siga el siguiente procedimiento para mantener un tiempo de actividad del 100 %:
Actualice EJBCA en todos los nodos existentes en un clúster, pero no lo ejecute aún después de la actualización .
En cada CA que desee utilizar procesadores de solicitudes , edite esa CA y elija la implementación utilizada.
Una vez configuradas todas las CA, ejecute post-upgrade para eliminar la propiedad vestigial de los alias de CMP.
Cambios en la base de datos
Nueva tabla OCSPResponseData
EJBCA 7.4 contiene una nueva tabla llamada OCSPResponseData para almacenar respuestas OCSP enlatadas .
Hibernate crea esta tabla automáticamente al implementar EJBCA 7.4 por primera vez. Sin embargo, si el usuario de la base de datos no tiene privilegios para crear tablas , deberá agregarla manualmente antes de implementar EJBCA. Los scripts SQL para agregar esta tabla se encuentran en doc/sql-scripts/ .
Además, agregue los nuevos índices manualmente de la siguiente manera:
CREATE INDEX ocspresponsedata_idx1 ON OcspResponseData (cAId);CREATE INDEX ocspresponsedata_idx2 ON OcspResponseData (serialNumber);CREATE INDEX ocspresponsedata_idx3 ON OcspResponseData (nextUpdate); Nuevos índices para CRLData
Desde la introducción de las CRL particionadas en EJBCA 7.1.0 , hemos observado que las recomendaciones de índice predeterminadas en doc/sql-scripts/create-index-ejbca.sql ya no funcionan si las CRL particionadas están habilitadas para una CA. Consulte ECA-8680 para obtener más información.
Para solucionar esto, EJBCA intentará modificar los índices existentes durante una actualización posterior a EJBCA 7.4.0 como se muestra en la siguiente tabla:
Operación realizada durante una actualización posterior a EJBCA 7.4.0 | Nombre del índice | Consulta SQL |
Eliminar índice si existe | crldata_idx3 | ELIMINAR ÍNDICE SI EXISTE crldata_idx3 EN CRLData; |
Eliminar índice si existe | crldata_idx4 | ELIMINAR ÍNDICE SI EXISTE crldata_idx4 EN CRLData; |
Crear nuevo índice a menos que ya exista | crldata_idx5 | CREAR ÍNDICE SI NO EXISTE crldata_idx5 EN CRLData(cRLNumber, issuerDN, crlPartitionIndex); |
Crear nuevo índice a menos que ya exista | crldata_idx6 | CREAR ÍNDICE ÚNICO SI NO EXISTE crldata_idx6 EN CRLData(issuerDN, crlPartitionIndex, deltaCRLIndicator, cRLNumber); |
Si el usuario de la base de datos EJBCA no tiene permisos suficientes para modificar estos índices, se mostrará un error en el registro, pero la actualización posterior se realizará correctamente. A continuación, podrá modificar estos índices manualmente.
Cambios de comportamiento
Comprobación más estricta de las extensiones de certificado
Las versiones anteriores de EJBCA no reportaban ningún error cuando las extensiones de certificado estaban presentes en una entidad final (por ejemplo, en solicitudes de servicio web), pero no estaban permitidas en el perfil de certificado. En este caso, las extensiones de certificado no permitidas se ignoraban silenciosamente.
Dado que el comportamiento anterior podría causar problemas de cumplimiento, EJBCA ahora informará un error y cancelará la emisión si la solicitud contiene una extensión que no está permitida por el perfil del certificado.
Esta comprobación solo se realiza cuando las extensiones del certificado se especifican en la entidad final. El comportamiento no cambia cuando se especifican extensiones de certificado en una CSR. Esto se controla mediante la opción " Permitir anulación de extensión por CSR" .
Comprobación de OrgID del foro CA/B en solicitud externa
Si el identificador de organización del foro CA/B está presente en la solicitud externa (por ejemplo, en solicitudes de servicio web), pero la casilla de verificación Usar correspondiente en el perfil de entidad final está desactivada y la del perfil de certificado está seleccionada, la emisión del certificado fallará con el mensaje de error correspondiente (anteriormente el certificado se emitió correctamente).
En caso de que la solicitud no contenga un Identificador de organización del foro CA/B y la casilla de verificación Usar relacionada con ella en el Perfil del certificado esté desactivada, pero en el Perfil de entidad final esté configurada como Usada , Requerida y Modificable sin un valor predefinido, el certificado no se emitirá (anteriormente el certificado se emitía sin el ID de organización del foro CA/B dentro de él).
Si hay un valor predefinido en el perfil de entidad final, entonces el certificado se emitirá utilizando ese valor incluso si el identificador de organización del foro CA/B falta en la solicitud.
Corrección de seguridad de SCEP: acceso más restrictivo a las CA
En versiones anteriores de EJBCA, la CA para SCEP solo estaba restringida por el Perfil de Entidad Final y el Perfil de Certificado configurados. La opción Nombre de CA de RA , aunque documentada como restrictiva para la CA, en realidad solo se usaba como opción predeterminada.
A partir de EJBCA 7.4.0 (y 6.15.2.5, 7.3.1.1), un alias SCEP solo permitirá la emisión utilizando la CA seleccionada como Nombre de CA de RA . Esta CA debe seguir seleccionada en el Perfil de Entidad Final configurado y en el Perfil de Certificado.
Ignorar el URI de emisores de CA predeterminados vacíos independientemente de cómo se creó la CA
Anteriormente había una inconsistencia entre las CA creadas por CLI y UI al emitir certificados con:
En el perfil de certificado Acceso a información de autoridad>Usar CA definida, el emisor de CA está habilitado.
En la CA, no se estableció ningún URI de emisor de CA predeterminado.
Con una CA creada por CLI, la emisión falló, mientras que con una CA creada por UI, la emisión se realizó correctamente sin un URI de emisor de CA en el certificado emitido. Este comportamiento se ha adaptado a las CA creadas por UI; es decir, cuando no se configura ningún URI de emisor de CA definido por la CA, la emisión del certificado se realiza correctamente, sin ningún URI de emisor de CA en el certificado emitido. Consulte ECA-8788 para obtener más información.
Códigos de retorno de falla de SCEP modificados
Los siguientes códigos de retorno en SCEP se han modificado para alinearse mejor con el borrador y devolver errores SCEP FailInfo .
Estado | Código de retorno anterior | Nuevo código de retorno |
Intentar realizar la renovación del certificado de cliente utilizando un certificado de cliente vencido | Estado HTTP 400 (Solicitud incorrecta) | Solicitud incorrecta(2) |
Intentar realizar la renovación del certificado de cliente en un certificado de cliente revocado | Estado HTTP 401 (No autorizado) | Solicitud incorrecta(2) |
Intentando realizar la renovación del certificado de cliente en un usuario con estado 'revocado' | Estado HTTP 401 (No autorizado) | Solicitud incorrecta(2) |
RFC 5019 Se agregaron encabezados de caché a POST
En versiones anteriores de EJBCA, solo las solicitudes GET tenían los encabezados de caché RFC 5019. Ahora, estos también se han añadido a POST.
Publicar actualización
Al actualizar a EJBCA 7.4.0, debe realizar una actualización posterior una vez actualizados todos los nodos. Esta actualización es necesaria debido a un cambio en la representación de las CRL particionadas en CRLData. Esta actualización también reindexará CRLData si el usuario de la base de datos tiene suficientes privilegios.
Para realizar la actualización posterior, haga clic en la opción de menú Actualización del sistema EJBCA y, a continuación, en Iniciar actualización posterior . Para obtener más información, consulte Actualización de EJBCA .
EJBCA 7.2.x a EJBCA 7.3.0
Cambios en la base de datos
Corte del archivo OCSP
A partir de EJBCA 7.3, si la extensión de corte de archivo de OCSP está habilitada para la asignación de claves de OCSP, esta se incluye en todas las respuestas de OCSP. En versiones anteriores de EJBCA, la extensión de corte de archivo de OCSP solo se incluía en las respuestas de OCSP enviadas al solicitar un certificado caducado.
La extensión de corte de archivo se deshabilita después de una actualización si la propiedad ocsp.expiredcert.retentionperiod no se ha configurado en ocsp.properties .
Información importante sobre la actualización
Durante una actualización, la propiedad ocsp.expiredcert.retentionperiod especificada en ocsp.properties se migra a la base de datos de la siguiente manera:
La propiedad ocsp.expiredcert.retentionperiod se lee desde ocsp.properties .
Si no se encuentra la propiedad o está establecida en -1 , se deshabilita el corte de archivo y no hay nada que migrar.
Si el corte de archivo está habilitado, se agrega una extensión de corte de archivo OCSP a cada enlace de clave OCSP con un período de retención según lo especificado por ocsp.expiredcert.retentionperiod .
Para garantizar que no haya cambios de comportamiento entre EJBCA 7.2 y EJBCA 7.3, asegúrese de que lo siguiente esté configurado antes de actualizar:
Las combinaciones de teclas OCSP están configuradas para todas las CA (solo las CA con una combinación de teclas OCSP responderán con una extensión de corte de archivo).
La propiedad ocsp.expiredcert.retentionperiod en ocsp.properties está establecida en el valor correcto.
Una vez completada la actualización, puede eliminar la propiedad ocsp.expiredcert.retentionperiod de ocsp.properties ya que ya no se utiliza y, opcionalmente, habilitar la configuración para basar la fecha límite de archivo en la fecha notBefore del emisor.
Cambios de comportamiento
Especificación de la clave de firma del certificado al crear CA
Al crear nuevas CA, se recomienda encarecidamente seleccionar específicamente la clave de firma del certificado. Anteriormente, se podía seleccionar la clave predeterminada, lo que podía ser un atajo práctico en entornos de prueba. Para mejorar la usabilidad y evitar errores de configuración, hemos eliminado la posibilidad de especificar la clave predeterminada para la clave de firma del certificado. Generalmente, el cambio no será perceptible, ya que es lo que la mayoría de los usuarios ya hacen.
Cumplimiento de la RFC 8555 del Entorno de gestión automática de certificados (ACME)
La implementación de ACME ahora cumple con la RFC 8555 y no es compatible con la versión anterior, que implementaba el borrador 12 de ACME. Los principales cambios entre estas dos versiones son que todas las operaciones de ACME, excepto directorio y newNonce, deben autenticarse mediante solicitudes POST. La nueva versión se probó con certbot 0.37.0 (así como 0.31.0) y PJAC 3.0.1.
EJBCA 7.3.0.X a EJBCA 7.3.1
Cambios de comportamiento
Cumplimiento de la transparencia de los certificados
Se realizó un cambio para cumplir con los requisitos básicos del foro CA/B. Si no se obtienen suficientes SCT de los registros de transparencia de certificados y no se emite un certificado final, EJBCA almacenará el precertificado en la tabla CertificateData (además de registrarlo en la auditoría) y responderá a las consultas de OCSP con el estado "bueno".
EJBCA 7.3.1 a EJBCA 7.3.1.1
Cambios de comportamiento
Corrección de seguridad de SCEP: acceso más restrictivo a las CA
En versiones anteriores de EJBCA, la CA para SCEP solo estaba restringida por el Perfil de Entidad Final y el Perfil de Certificado configurados. La opción Nombre de CA de RA , aunque documentada como restrictiva para la CA, en realidad solo se usaba como opción predeterminada.
A partir de EJBCA 7.3.1.1 (así como en las versiones 6.15.2.5 y 7.4.0), un alias SCEP solo permitirá la emisión utilizando la CA seleccionada como Nombre de CA de RA . Tenga en cuenta que esta CA debe seguir seleccionada en el Perfil de Entidad Final configurado y en el Perfil de Certificado.
EJBCA 7.3.1.1 a EJBCA 7.3.1.2
Cambios de comportamiento
Algoritmo de validez y firma del certificado de enlace CVCA
CONTROL DE ACCESO EXTENDIDO (EAC) SOLO PARA PASAJEROS
Al renovar una CA de verificación de país (CVCA) en la interfaz de administración de EJBCA, se crea automáticamente un certificado de enlace. En versiones anteriores de EJBCA, el certificado de enlace CVCA heredaba la validez (fecha de no posterior) del certificado CVCA anterior. Esto se ha solucionado y la fecha de no posterior del certificado de enlace CVCA ahora coincide con la validez del nuevo certificado CVCA, de acuerdo con la Política de certificación común para la infraestructura de control de acceso extendido para documentos de viaje y residencia (BSI TR-03139) .
Al renovar una CA de verificación de país (CVCA) y cambiar el algoritmo de firma de la nueva CVCA, el certificado de enlace se firmaba previamente con el algoritmo de la nueva CVCA. Esto se ha solucionado y el certificado de enlace ahora se firma con el algoritmo de la CVCA anterior. Tenga en cuenta que el identificador del algoritmo en el certificado de enlace corresponde al nuevo algoritmo, ya que este está vinculado a la clave pública, no a la firma del certificado.
EJBCA 7.3.1.3 a EJBCA 7.3.1.4
Cambios de comportamiento
Las extensiones personalizadas y otros complementos deben declararse en cesecore.propertes
EJBCA 7.3.1.2 introdujo reglas más estrictas para la deserialización de objetos de la base de datos con el fin de evitar problemas de seguridad relacionados con la ejecución de código hostil. Como resultado, la mayor parte del código personalizado inyectado en EJBCA ha dejado de ser válido. Por lo tanto, estas clases deben declararse en cesecore.properties como una lista separada por comas:
custom. class .whitelist=com.widget.WidgetCustomExtension,com.widget.AnotherWidgetCustomExtensionPara obtener más información, consulte Permitir clases personalizadas en la base de datos y Administrar configuraciones de EJBCA .
EJBCA 7.1 a EJBCA 7.2.0
Cambios de comportamiento
Servlets de almacén de certificados y de almacén de CRL siempre disponibles
Los archivos de configuración certstore.properties y crlstore.properties se eliminan y ya no deben utilizarse.
Estos archivos de configuración permitían especificar la raíz de contexto del servlet y si este debía estar disponible en el archivo EAR. A partir de EJBCA 7.2, estos dos servlets siempre están disponibles y se ha eliminado la propiedad de raíz de contexto. El acceso a estos servlets se controla mediante la Configuración de Protocolos Modulares.
- <p >Si está utilizando una raíz de contexto personalizada para estos servlets, debe reconfigurar su cliente para utilizar la nueva raíz de contexto o colocar un proxy HTTP entre EJBCA y su cliente.
Si actualiza desde EJBCA 6.11 o posterior y su implementación anterior no contenía el servlet, el acceso a este se deshabilitará después de la actualización. Sin embargo, si actualiza desde EJBCA 6.10 o anterior (donde no se implementó la función de Configuración de Protocolos Modulares), el acceso al servlet no se puede configurar automáticamente durante la actualización, ya que no hay forma de determinar si su implementación anterior lo contenía. Si su implementación anterior no contenía el servlet y no desea que sea accesible, deberá deshabilitarlo manualmente.
Para obtener más detalles, consulte Notas de actualización de EJBCA 7.2 .
Registro mejorado de ejecución de servicios
Anteriormente, los registros indicaban si los service workers se habían ejecutado o no, pero no indicaban el estado de la ejecución (los errores se representaban como parte de la salida). Se han modificado los service workers para que reporten a los registros el estado completo de la ejecución, que puede ser "Exitoso" (si se ejecutó), "Failed" (si se ejecutó, aunque con algunos fallos) o "Sin acción" (si se ejecutó, pero no se requirió ninguna acción).
CA predeterminada para alias SCEP
Si el alias utilizado opera en modo RA y el parámetro de mensaje no se especifica en la solicitud SCEP, las operaciones SCEP GetCACert , GetCACertChain , GetNextCACert y GetCACaps utilizan el nombre de CA de RA definido por el alias, en lugar de depender de la propiedad scep.defaultca . Esto proporciona mayor flexibilidad y una configuración más sencilla para implementaciones donde editar los archivos de configuración resulta incómodo o imposible.
El comportamiento anterior para determinar el nombre de CA a utilizar era el siguiente:
Si se envió un mensaje, utilice la CA especificada por el mensaje.
Si no se envió ningún mensaje, utilice la CA especificada por la propiedad scep.defaultca .
A partir de EJBCA 7.2, el nombre de la CA a utilizar se calcula de la siguiente manera:
Si se envió un mensaje, utilice la CA especificada por el mensaje.
Si el alias está en modo RA y no se envía ningún mensaje, utilice el nombre de CA de RA especificado por el alias.
Si el alias está en modo CA, se define la propiedad scep.defaultca y no se envía ningún mensaje, utilice la CA especificada por la propiedad scep.defaultca.
Si el alias está en modo CA, la propiedad scep.defaultca no está definida y no se envía ningún mensaje, se produce un error.
Para obtener más información, consulte SCEP .
Transparencia del certificado
Almacenamiento en caché persistente
Se ha añadido el almacenamiento en caché persistente de las SCT (Marcas de Tiempo de Certificado Firmado) de Transparencia de Certificados, además del almacenamiento en caché en memoria existente. Esto añade una nueva tabla, SctData, para almacenar los datos de SCT en caché. Asegúrese de que esta tabla exista si utiliza Transparencia de Certificados.
Dado que puede haber varias SCT por certificado, la tabla SctData aumentará de tamaño con el tiempo. Por lo tanto, recomendamos encarecidamente crear un índice en la columna de huellas dactilares . Consulte doc/sql-scripts/create-index-ejbca.sql para obtener un comando SQL para crear el índice.
Almacenamiento en caché de registros no funcionales (fallo rápido)
La caché de fallo rápido ahora está habilitada por defecto. Para más información, consulte las Notas de la versión de EJBCA 7.2 .
Asegúrese de que solo las CA de confianza según los registros CT se utilicen en los perfiles de certificado donde CT esté habilitado. Si se envía un certificado emitido por una CA no confiable, el registro CT devolverá un error y EJBCA lo considerará no funcional (para todas las CA, no solo para la no confiable). Para deshabilitar la caché de "fallo rápido", configure la propiedad ct.fastfail.enabled como "false" en el archivo conf/cesecore.properties . Para obtener más información, consulte Transparencia de certificados .
Publicar actualización
Al actualizar a EJBCA 7.2.0, debe realizar una actualización posterior una vez actualizados todos los nodos. Esta actualización posterior es necesaria debido a una mejora que permite configurar la hora de inicio y la hora de finalización del certificado personalizado con granularidad en segundos. Anteriormente, el valor de la hora se guardaba con granularidad en minutos. Para realizar la actualización posterior, haga clic en la opción de menú Actualización del sistema EJBCA y, a continuación, en Iniciar actualización posterior . Para obtener más información, consulte Actualización de EJBCA.
EJBCA 7.2.0 a EJBCA 7.2.1
Cambios de comportamiento
Renovación de EST
Para la operación EST 'simpleenroll', si ya existe una entidad final con el nombre de usuario especificado, se trata como una renovación: se emite un nuevo certificado para la entidad final existente (siempre que ninguna configuración impida este comportamiento, por ejemplo, "Exigir DN Único" o "Exigir Claves Públicas Únicas"). Anteriormente, esta solicitud se rechazaba, aunque es poco probable que ocurra, ya que los nombres de usuario de las entidades finales se generaban aleatoriamente.
EJBCA 7.0.x a EJBCA 7.1.0
Cambios en la base de datos
Se ha añadido una nueva columna, crlPartitionIndex, a las tablas de base de datos CertificateData, NoConflictCertificateData y CRLData . Si el usuario de la base de datos EJBCA no tiene privilegios GRANT, deberá ejecutar los comandos ALTER en los scripts de actualización. Tenga en cuenta que si utiliza el Publicador de Autoridades de Validación con publicación de CRL , debe actualizar al menos las tablas CRLData en las VA (o toda la base de datos) antes de actualizar las CA.
Una vez implementado EJBCA 7.1.0 , es seguro eliminar las tablas de bases de datos hardtokendata, hardtokenissuerdata, hardtokenprofiledata y hardtokenpropertydata .
Los scripts de actualización están disponibles en la carpeta src/upgrade/700_710 .
Cambios de comportamiento
Nuevas reglas de acceso para roles de RA
Algunas reglas de acceso para los roles creados en la web de RA faltaban o no estaban configuradas correctamente.
El nuevo comportamiento en EJBCA 7.1 es el siguiente:
Al seleccionar la opción Aprobar acciones de entidad final , se concede acceso tanto para ver como para aprobar entidades finales. En versiones anteriores de EJBCA, solo se concedía acceso para aprobar entidades finales, pero no para ver aprobaciones.
Al seleccionar "Crear certificados" , se concede acceso para emitir certificados para una entidad final. Esta regla de acceso no estaba disponible en la web de RA en versiones anteriores de EJBCA.
Al seleccionar "Ver entidades y certificados" , se concede acceso tanto a las entidades como a los certificados emitidos para ellas. En versiones anteriores de EJBCA, solo se concedía acceso a las entidades, pero no a los certificados.
Las reglas de acceso faltantes no se otorgarán automáticamente a los roles existentes durante una actualización. Debe editar manualmente los roles de RA existentes creados en la Web de RA y habilitar las opciones correspondientes para que los cambios surtan efecto.
El algoritmo de firma de respuesta CMP predeterminado ahora es SHA256
El algoritmo de firma utilizado para firmar las respuestas CMP ahora es SHA256 en lugar de SHA1 de forma predeterminada. Este algoritmo solo se utiliza si la solicitud CMP no contiene un algoritmo de firma, por lo que, para la mayoría de los usuarios, no hay cambios y se utilizará SHA1 si el cliente envía mensajes firmados con SHA1. El único caso típico en el que se utiliza el algoritmo predeterminado es cuando los mensajes del cliente están protegidos por HMAC y el servidor CMP está configurado para responder con mensajes firmados. Si los clientes CMP comprenden SHA256, podrán procesar las respuestas, ya que el algoritmo utilizado forma parte de ellas.
EJBCA 7.0.0 a EJBCA 7.0.1
Cambios de comportamiento
Conjunto de entropía SN por CA
A partir de EJBCA 7.0.1, la entropía del número de serie se establece por CA en lugar de globalmente desde la propiedad ca.serialnumberoctetsize en cesecore.properties, y el valor predeterminado se ha incrementado de 8 a 20 octetos. Las CA existentes se actualizarán automáticamente utilizando el valor establecido, mientras que las nuevas CA recibirán 20 octetos de entropía por defecto.
EJBCA 6.15 a EJBCA 7.0
Cambios en la base de datos
Se ha añadido la columna certificateRequest a las tablas CertificateData , NoConflictCertificateData y Base64CertData . La nueva columna admite valores nulos y está vacía por defecto. Hay scripts de actualización disponibles en la carpeta src/upgrade/615_70 . Tenga en cuenta que este campo no se utiliza actualmente, pero se usará en futuras versiones para almacenar la CSR junto con el certificado emitido.
Cambios de comportamiento
Sensibilidad a mayúsculas y minúsculas en la coincidencia de DN completo para miembros del rol
Hemos actualizado el X509 con la opción de coincidencia de DN completo para que distinga entre mayúsculas y minúsculas. Anteriormente, podía realizar una coincidencia sin distinguir entre mayúsculas y minúsculas, aunque estaba configurado para hacerlo.
Le recomendamos encarecidamente que verifique que sus roles de administrador que utilizan X509: con DN completo estén configurados correctamente antes de actualizar .
Limitaciones en las cadenas DN con soporte para RDN multivalor
Hemos añadido compatibilidad en segundo plano con RDN multivalor, lo que incluye un análisis más estricto de los DN. El cambio más notable es que antes, al usar signos más en un DN, estos se escapaban automáticamente. Ahora, es necesario escaparlos. Para más información, consulte Nombres Distinguidos de Sujeto .
Orden modificado del componente DN en el archivo de muestra
Hemos corregido el orden del componente DN organizationIdentifier en el archivo de ejemplo dncomponents.properties.sample .
Si ha estado utilizando un archivo dncomponents.properties personalizado, basado en el archivo de ejemplo , y ha utilizado el componente DN organizationIdentifier , podría experimentar problemas si modifica dicho archivo para que coincida con el valor actualizado. Infórmenos si se encuentra en esta situación y le ayudaremos.
EJBCA 6.14 a EJBCA 6.15.0
Cambios en la base de datos
Con la introducción del soporte del protocolo ACME en EJBCA 6.15, tuvimos que introducir las siguientes tablas nuevas en EJBCA:
Datos de la cuenta de Acme
Datos de autorización de Acme
Datos del desafío Acme
Datos de AcmeNonce
Datos de pedidos de Acme
Como siempre, estos pueden crearse automáticamente si los derechos de usuario de la base de datos son suficientes o pueden crearse manualmente utilizando los scripts de creación incluidos.
Hemos creado índices para:
Datos de la cuenta de Acme
Datos de autorización de Acme
Datos del desafío Acme
Datos de pedidos de Acme
Los índices se encuentran en doc/sql-scripts/create-index-ejbca.sql y recomendamos aplicarlos en cualquier entorno de producción que utilice ACME.
Cambios de comportamiento
Extensiones de certificado personalizadas
Con la introducción de comodines y CCE no obligatorios, hemos optimizado la gestión de las extensiones en las solicitudes de inscripción. Mientras que en versiones anteriores las extensiones indefinidas en la solicitud simplemente se eliminaban del certificado final, en la versión 6.15 y posteriores, las solicitudes que contengan extensiones no coincidentes se considerarán erróneas y se rechazarán.
EJBCA 6.13 a EJBCA 6.14.0
Cambios en las reglas de acceso
Los requisitos de las reglas de acceso para generar CSR desde la interfaz de usuario para combinaciones de teclas internas se han cambiado de /cryptotoken/keys/ generate/ a /cryptotoken/ use/ para permitir que estos roles estén separados.
Cambios en EJBCAWS
EjbcaWS.obtenerNúmeroRestanteDeAprobaciones
El método org.ejbca.core.protocol.ws.common.IEjbcaWS.getRemainingNumberOfApprovals(int) ha cambiado su comportamiento para cumplir con los requisitos del mundo real. El javadoc anterior indicaba:
/** * * @param requestId the ID of an approval request * @return the number of remaining approvals required, or STATUS_REJECTED (-1) if request was rejected * @throws ApprovalException if a request of the given ID didn't exist * @throws AuthorizationDeniedException if the current requester wasn't authorized. * @throws ApprovalRequestExpiredException if sought approval request has expired * */Esto era incorrecto, ya que ApprovalDataVO.STATUS_REJECTED es en realidad -2. Para mantener la fidelidad a la API, hemos cambiado el valor de retorno a -1 para los resultados rechazados. El nuevo javadoc indica lo siguiente:
/** * * @param requestId the ID of an approval request * @return the remaining number of approvals for this request (with 0 meaning that the request has passed) or -1 if the request has been denied * @throws ApprovalException if a request of the given ID didn't exist * @throws AuthorizationDeniedException if the current requester wasn't authorized. * @throws ApprovalRequestExpiredException if approval request was expired before having a definite status * */El cambio adicional es que la implementación anterior generaba una excepción para las aprobaciones que habían expirado después de ser aprobadas. Desde la versión 6.14, este método devolverá 0 si la aprobación fue aprobada (o -1 si fue rechazada), incluso si ya ha expirado.
EjbcaWS.getProfiles
Se descubrió que este método podría filtrar información sobre perfiles de entidad final e ID de CA a los que el administrador solicitante no estaba autorizado. Si se solicita un perfil de entidad final, el usuario solicitante debe estar autorizado según las siguientes reglas:
/ra_functionality/view_end_entity_profiles
a cualquier CA a la que se haga referencia en el EEP
a cualquier CA a la que se haga referencia en cualquier Perfil de Certificado al que se haga referencia en el EEP
Si se solicita un perfil de certificado, el usuario solicitante debe estar autorizado según las siguientes reglas:
/ca_functionality/ver_perfiles_de_certificado
a cualquier CA a la que se haga referencia en el perfil del certificado
Actualización de los validadores de CAA
Se detectó un pequeño error en la versión 6.13: la lista de dominios de nivel superior ignorados se redujo a una sola entrada si el validador se editaba o guardaba. EJBCA actualizará automáticamente los validadores al editarlos en la versión 6.14, pero por este motivo, es necesario que los validadores CAA no se editen durante la actualización. Por lo demás, los validadores CAA funcionarán con normalidad.
EJBCA 6.12 a EJBCA 6.13.0
Creación de la tabla NoConflictCertificateData
La actualización a EJBCA 6.13.0 requiere la creación de la tabla NoConflictCertificateData. El servidor de aplicaciones creará la tabla automáticamente si el usuario de la base de datos tiene permisos de creación, o bien puede crearse manualmente mediante los scripts estándar de creación de bases de datos de EJBCA. Esta tabla solo se utiliza en instalaciones que utilizan la base de datos Oracle con configuraciones asíncronas y solo se usará si algún certificado está configurado para el modo de descarte .
EJBCA 6.11 a EJBCA 6.12.0
Gestión de roles de RA
EJBCA 6.12 cambia el funcionamiento de los espacios de nombres de roles para los administradores con acceso a la regla de acceso "/" . En versiones anteriores a la 6.12, el acceso a la regla "/" otorgaba implícitamente acceso a todos los espacios de nombres de roles, incluso si el administrador solo se añadía a roles en uno o más espacios de nombres específicos. A partir de la 6.12, esto ya no es así, y los administradores deben añadirse explícitamente a roles en los espacios de nombres a los que deberían poder acceder. Tenga en cuenta que el rol de superadministrador tiene acceso predeterminado al espacio de nombres raíz y no se ve afectado por este cambio, a menos que se haya trasladado a otro espacio de nombres.
UnidFnr
En versiones anteriores de EJBCA, el directorio de confianza (trustdir) y el certificado de CA se definían en ocsp.properties para la extensión OCSP UnidFnr. Durante la actualización a EJBCA 6.12.0, las extensiones definidas por el OID en ocsp.properties se añadirán a cada enlace de clave OCSP. Además, cada certificado del directorio de confianza UnidFnr especificado se importará como entrada de confianza para cada enlace de clave. Si UnidFnr está habilitado en su instalación, el certificado de CA al que apunta " ocsp.unidcacert " DEBE importarse a EJBCA antes de la actualización.
EJBCA 6.10 a EJBCA 6.11.0
EJBCA 6.11 introduce el protocolo EST. Tenga en cuenta que, como medida de seguridad, el respondedor EST está desactivado por defecto (al igual que todos los protocolos nuevos a partir de ahora) y debe activarse en la Configuración del Sistema.
EJBCA 6.11 actualiza el Protocolo de Pares con información sobre los derechos del protocolo (CMP, ETC, etc.). Debido a un pequeño error en el sistema de control de versiones del protocolo, se recomienda encarecidamente actualizar las RA/VA antes que las CA. Sin embargo, realizar la actualización en el orden incorrecto implica simplemente que cualquier proxy de CMP o WS dejará de funcionar durante la actualización.
Hemos configurado la ejecución de scripts externos desde EJBCA (el nuevo Validador de Certificados de Comandos Externos y el antiguo Publicador Personalizado de Propósito General) en la Configuración del Sistema. Esta opción estará desactivada de forma predeterminada, principalmente para evitar confusiones en entornos donde no se puede aplicar. Si actualmente está ejecutando un Publicador Personalizado de Propósito General, esta opción se activará durante la actualización.
SHA1WithRSA y SHA1WithECDSA ya no son algoritmos de firma aceptables para un respondedor OCSP. Si utiliza un respondedor heredado que aún necesita usar estos algoritmos obsoletos, debe configurarlos en la opción "ocsp.signaturealgorithm" en conf/ocsp.properties.
Las cadenas codificadas en base64 rellenadas incorrectamente ya no son aceptadas por el decodificador base64 de Bouncy Castle utilizado en EJBCA.
EJBCA 6.10.0 a EJBCA 6.10.1
La actualización a la versión 6.10.1 solo afectará a los usuarios que escriban en los registros de Transparencia de Certificados durante la emisión de certificados. La versión 6.10.1 introduce el concepto de ETIQUETAS, que permite a las CA ordenar los registros de CT en diferentes grupos. Las etiquetas sustituyen la casilla "Obligatorio" introducida en la versión 6.10, lo que permite a las CA especificar con mayor precisión en qué registros escribir. El proceso de actualización añadirá etiquetas automáticamente; los registros pertenecientes a Google o marcados como obligatorios se etiquetarán como "OBLIGATORIOS", mientras que los demás se etiquetarán como "SIN ETIQUETA". Tras la actualización, es necesario ejecutar una actualización posterior para eliminar las referencias antiguas de los registros.
EJBCA 6.9.x a EJBCA 6.10.0
No se requieren operaciones de actualización al actualizar de 6.9.x a 6.10.
EJBCA 6.8.x a EJBCA 6.9.0
Al actualizar a EJBCA 6.9.0, todos los cambios se realizan automáticamente y no se requiere ningún paso posterior a la actualización.
En la base de datos, el único cambio es la creación de la tabla BlacklistData. Esta tabla está vacía por defecto, pero se puede rellenar con datos para validar las solicitudes con una lista negra mediante la nueva función Validadores. Si se espera que esta tabla contenga muchos datos, se recomienda aplicar un índice en el archivo create-index-ejbca.sql.
EJBCA 6.7.x a EJBCA 6.8.0
Al actualizar a EJBCA 6.8.0, la actualización inicial se realizará automáticamente al implementar la versión 6.8.0. En resumen, los siguientes cambios se habrán implementado o se implementarán en el paso posterior a la actualización. Tenga en cuenta que a continuación se detallan estos pasos:
1. La actualización posterior ahora se puede realizar en la GUI de administración
2. Las implementaciones de roles, miembros de roles y reglas de acceso han cambiado.
3. Ahora se pueden configurar perfiles de aprobación por acción en CA y Perfil de certificado
Además de esto, las ramas y las implementaciones personalizadas basadas en el código EJBCA deben tener en cuenta los siguientes cambios:
4. Los tokens de autenticación ahora se cargan dinámicamente y las implementaciones personalizadas necesitarán modificaciones.
Por último, se deben tener en cuenta los siguientes cambios de comportamiento:
5. Se ha eliminado la capacidad de buscar información en la columna "Detalles" del registro de auditoría.
6. La API de WebService ha cambiado para las aprobaciones
7. El comando CLI 'role addadmin' ha sido renombrado 'role addrolemember'
8. En el protocolo CMP, se ha introducido una validación de cadena de certificados más estricta en los campos extraCerts (utilizados en el modo Proveedor 3GPP y en el modo RA).
Descripciones completas de los cambios:
1. La actualización posterior ahora se puede realizar en la GUI de administración
A partir de la versión 6.8.0, la opción de menú "Actualización del sistema" estará disponible en la interfaz de usuario cuando el sistema necesite una actualización posterior. Esta actualización puede activarse desde aquí en lugar de desde la CLI.
2. Las implementaciones de roles, miembros de roles y reglas de acceso han cambiado.
Todas las reglas ahora son recursivas y, durante la actualización, las reglas de acceso existentes se convierten para otorgar el mismo acceso. Tenga en cuenta que, al crear nuevos objetos con una regla de aceptación recursiva, el acceso se otorgará automáticamente.
Después de una actualización posterior, las sesiones de autenticación (es decir, administradores) que coinciden con múltiples roles tendrán acceso combinado de todos los roles. En versiones anteriores, los diferentes métodos de autenticación tenían diferente prioridad en el caso en que la sesión autenticada pudiera pertenecer a múltiples roles.
Los operadores de coincidencia "No distingue entre mayúsculas y minúsculas" y "No distingue entre mayúsculas y minúsculas" ya no están permitidos. Si los usa actualmente, debe reconfigurar sus roles para poder continuar después de la actualización.
Cada clave de coincidencia ahora indica si la coincidencia debe distinguir entre mayúsculas y minúsculas. Se recomienda usar el operador de valor de coincidencia predeterminado para las reglas existentes (normalmente significa "Igual a mayúsculas y minúsculas").
Para la nueva implementación, se han introducido dos nuevas tablas: RoleData y RoleMemberData. Las tablas AdminGroupData, AdminEntityData y AccessRulesData ya no se actualizarán con nuevos datos, pero se conservan por motivos de actualización y para garantizar el 100 % de disponibilidad.
3. Ahora se pueden configurar perfiles de aprobación por acción en CA y Perfil de certificado
Las CA y los perfiles de certificado se actualizarán automáticamente, utilizando los mismos perfiles para las mismas acciones que antes.
Tenga en cuenta que los perfiles de certificado exportados de 6.6 y 6.7 se pueden importar, pero no de versiones anteriores.
4. Los tokens de autenticación ahora se cargan dinámicamente y las implementaciones personalizadas necesitarán modificaciones.
Las implementaciones de tokens de autenticación ahora implementan la interfaz de marcador AuthenticationTokenMetaData, que se utiliza para cargarlos dinámicamente mediante manifiestos de servicio.
5. Se ha eliminado la capacidad de buscar información en la columna "Detalles" del registro de auditoría.
Esto se debe a que la búsqueda no generaba resultados en las filas con acentos, lo que generaba un comportamiento inconsistente. Esta funcionalidad se reintroducirá cuando la búsqueda siempre genere los mismos resultados.
6. La API de WebService ha cambiado para las aprobaciones
Durante la revisión de Aprobaciones en EJBCA 6.7.0, se modificó la clase de excepción WaitingForApprovalException, donde el atributo approvedId se cambió al más útil requestId. Dado que este valor era poco útil para las llamadas a servicios web, consideramos que no era perjudicial cambiarlo, pero cualquier implementación de terceros de la API de WS debería tener en cuenta este cambio.
NOTA: Ahora es posible almacenar nombres alternativos de sujeto en CertificateData y buscar certificados basándose en ellos. Esta función está deshabilitada por defecto y debe habilitarse con "Búsqueda habilitada" para "Nombre alternativo de sujeto" en los perfiles de certificado antiguos.
7. El comando CLI 'role addadmin' ha sido renombrado 'role addrolemember'
Aparte de esto, el comando es idéntico a las versiones anteriores.
8. En el protocolo CMP, se ha introducido una validación de cadena de certificados más estricta en los campos extraCerts (utilizados en el modo Proveedor 3GPP y en el modo RA).
Si ha estado utilizando clientes CMP que anteriormente presentaban errores al enviar cadenas incompletas o incorrectas en este campo, es posible que ahora sean rechazados. Esto podría ocurrir, por ejemplo, si su proveedor de eNodeB utiliza una CA de proveedor que emite certificados no válidos según el estándar RFC5280.
EJBCA 6.6.1 a EJBCA 6.7.0
EJBCA 6.7.0 elimina el valor ocsp.responderidtype de ocsp.properties. Desde la introducción de las combinaciones de teclas internas en EJBCA 6.0.0, el tipo de ID del respondedor (hash de clave predeterminado) se ha configurado individualmente para cada combinación de teclas de OCSP. Por lo tanto, el valor de ocsp.properties solo se ha utilizado para las CA que actúan como sus propios respondedores. A partir de EJBCA 6.7.0, este valor se configurará desde la pestaña Combinaciones de teclas de OCSP en lugar de en ocsp.properties.
EJBCA 6.6.0 a EJBCA 6.6.1
La actualización a EJBCA 6.6.1 permite una precisión de segundos para la configuración de certificados de CA y de usuario, y permite la emisión de certificados de corta duración. Para ello, se implementó un nuevo campo de validez para la CA y el perfil del certificado. Este campo se rellena al cargar un perfil de CA y de certificado desde un objeto de datos por primera vez.
Además, se modificó la gestión de los años bisiestos. Anteriormente, EJBCA tenía en cuenta los años bisiestos al crear una CA o un perfil de certificado cuando se especificaba una validez en años (con la sintaxis "10y") y añadía días adicionales según correspondiera. Desde la versión 6.6.1, EJBCA siempre cuenta un año como 365 días, por lo que si necesita contabilizar los años bisiestos, deberá especificarlos manualmente, por ejemplo, como "10y 2d". Las CA y los perfiles de certificado de versiones anteriores mantendrán sus periodos de validez sin cambios.
EJBCA 6.5.x a EJBCA 6.6.0
La actualización a la versión 6.6.0 requerirá reemplazar la configuración de aprobación en las CA y los perfiles de certificado por perfiles de aprobación. Si se utilizan aprobaciones, debe ejecutar el siguiente comando después de implementar la nueva versión de EJBCA:
$ ant upgradey reinicie JBoss. Si las aprobaciones no están en uso, este paso no es necesario.
La actualización a 6.6.0 implica los siguientes cambios:
Cambios en los datos del certificado
Cambios en ApprovalData
Registro web público automático
Cambios en las aprobaciones de servicios web
Eliminación de la regla de acceso /ca_functionality/store_certificate
Notas sobre el tiempo de actividad de la actualización del 100 %
Perfiles de aprobación
1. Cambios en los datos del certificado
CertificateData tiene tres nuevas columnas: "notBefore", "endEntityProfileId" y "subjectAltName".
CertificateData se utiliza para almacenar los certificados emitidos y puede ser bastante grande. Aunque la implementación de la nueva versión de EJBCA eventualmente realizará el cambio de esquema en instalaciones más grandes, recomendamos encarecidamente modificar manualmente la tabla antes de implementar la nueva versión de EJBCA. (De lo contrario, podría tener que forzar el reinicio del servidor de aplicaciones). Dado que CertificateData es utilizado por EJBCA al ejecutarse como autoridad de validación, también debe realizar este cambio de esquema de base de datos en sus aplicaciones virtuales antes de actualizar para que la publicación funcione.
Consulte src/upgrade/650_660/650_660-upgrade-<database>.sql para obtener la declaración ALTER de SQL correcta.
En el caso en que endEntityProfileId y subjectAltName no hayan cambiado para las entidades finales desde la emisión del certificado, puede copiar este valor usando una declaración SQL como (consulte a su administrador de base de datos para conocer la sintaxis adecuada y la viabilidad de ejecutar esta consulta en su base de datos de producción):
UPDATE CertificateData AS a INNER JOIN UserData AS b ON a.username = b.usernameSET a.endEntityProfileId = b.endEntityProfileId, a.subjectAltName = b.subjectAltName WHERE a.endEntityProfileId IS NULL ; 2. Cambios en ApprovalData
ApprovalData incorpora un nuevo concepto de perfil de aprobación. Las aprobaciones creadas antes de la versión 6.6.0 seguirán estando disponibles, pero no se podrán realizar aprobaciones en nodos que ejecuten versiones de EJBCA anteriores a la 6.6.0 en una base de datos actualizada (es decir, durante la actualización). Como parte de este cambio, las notificaciones de aprobación ahora se configuran por partición de aprobación en lugar de globalmente. Revise su perfil de aprobación después de implementar el nuevo código.
a. Registro web público
Si ha estado utilizando el registro automático en la antigua Web pública, debe crear un perfil de aprobación y seleccionar usarlo para las acciones "Agregar/Editar entidad final", ya sea en la configuración de CA o en la configuración del perfil de certificado.
3. Cambios en las aprobaciones de servicios web
Si ha estado utilizando Aprobaciones con la API de WebService, ha configurado las opciones de aprobación en jaxws.properties (solo para llamadas a genTokenCertificates o viewHardToken). Esta opción de configuración ha cambiado como parte del nuevo concepto de perfil de aprobación. Consulte jaxws.properties y configure un nuevo perfil de aprobación para las Aprobaciones de WebService.
4. Eliminación de la regla de acceso /ca_functionality/store_certificate
La regla de acceso /ca_functionality/store_certificate se ha eliminado por la sencilla razón de que no se utilizaba. No se eliminará de ningún rol existente, ya que es inofensiva (y su eliminación es invasiva).
5. Notas sobre el tiempo de actividad de la actualización del 100 %
a. Perfiles de aprobación
Los perfiles de aprobación (del tipo Perfil de Aprobación Acumulativo) se crearán y configurarán automáticamente durante el inicio del primer nodo actualizado para las CA y los perfiles de certificado que utilicen aprobaciones. Durante la actualización, es posible que se reciban solicitudes de aprobación desde nodos no actualizados, las cuales se analizarán automáticamente al leerse desde los nodos actualizados; es decir, se configurarán para usar el mismo perfil que si se hubieran creado en un nodo actualizado. Para garantizar un tiempo de actividad del 100 %, esto significa que todas las acciones (inscripción, revocación, activación de la CA, etc.) pueden continuar durante la actualización y procesarse desde los nodos actualizados. Por otro lado, los nodos no actualizados no podrán aprobar acciones creadas o leídas por los nodos actualizados hasta que se complete el proceso de actualización.
EJBCA 6.5.1 a EJBCA 6.5.3
La versión 6.5.3 implica un cambio menor en el comando CLI "ca editca". Se han eliminado los indicadores "-listFields" y "-getValue" y se han reemplazado por los comandos "ca listcafields" y "ca getcafield".
EJBCA 6.5.0 a EJBCA 6.5.1
EJBCA 6.5.1 implica dos cambios menores en los alias de CMP:
Los perfiles de entidad final (para configuraciones de RA) se referenciaban por nombre en lugar de por ID. Dado que los nombres de los perfiles de entidad final son volátiles y no se garantiza su unicidad, esto generaba problemas: al cambiar el nombre de un perfil, se podía generar un error en un alias de CMP. La versión 6.5.1 convertirá automáticamente los alias de CMP existentes al nuevo formato, conservando el valor anterior para garantizar un tiempo de actividad completo. CMP funcionará; no se deben realizar cambios de configuración durante la actualización.
Como resultado de esto, EJBCA ya no admite los valores de configuración ra.endentityprofile=KeyId o ra.certificateprofile=KeyId, que quedaron obsoletos en 2013 (ECA-2948).
EJBCA 6.4.2 a EJBCA 6.5.0
La actualización a 6.5.0 implica los siguientes cambios:
4. Eliminación de la regla de acceso /ca_functionality/store_certificate
5. Notas sobre el tiempo de actividad de la actualización del 100 %
Restricciones clave de algoritmos en perfiles de certificados
Restricciones clave de algoritmos en perfiles de certificados
EJBCA 6.5.0 permite la configuración de restricciones de algoritmos clave en perfiles de certificado y, de forma predeterminada, cualquier tipo compatible con los permitidos actualmente.
Las longitudes de clave se preseleccionarán durante la actualización. Si permite 1024 bits, se permitirán tanto RSA como DSA, y dado que ahora es posible...
>solicitar tokens utilizando cualquier algoritmo de clave permitido de la web pública, se permitirá solicitar un almacén de claves DSA 1024 en comparación con antes, cuando solo se permitía RSAEstaba disponible a través de esta interfaz.
Cambios de configuración en el proxy CMP
Para quienes ejecutan el proxy CMP, los siguientes valores han cambiado de nombre en cmpProxy.properties:
De | A |
cmp.backend.extra.caservicecertpath | cmp.backend.caservicecertpath |
cmp.backend.extra.rutadecadenadeemisor | cmp.backend.ruta de la cadena del emisor |
cmp.backend.extra.keystorepath | cmp.backend.keystorepath |
cmp.backend.extra.keystorepwd | cmp.backend.contraseña del almacén de claves |
Los valores antiguos seguirán funcionando por el momento, pero se eliminarán en el futuro.
Número máximo de consultas de la base de datos
El recuento máximo de consultas (número máximo de objetos recuperados de la base de datos en una sola solicitud), que anteriormente eran varias constantes predefinidas, ahora se puede configurar desde la interfaz de usuario web (en la pantalla Configuración de sistemas).
Mensaje de error de CMP
Se han cambiado un par de mensajes de error para CMP.
Al enviar una solicitud con una URL que no coincide con un alias de CMP existente, se devuelve un HTTP 404 (no encontrado) en lugar de un mensaje de error CMP badRequest.
Al intentar revocar un certificado que ya ha sido revocado, se devuelve un mensaje de error CMP certRevoked en lugar de un mensaje de error CMP badRequest.
propiedad healthcheck.publisherconnections
La propiedad healthcheck.publisherconnections se documentó con un valor predeterminado falso, pero en realidad era verdadero. Esto se ha corregido y ahora es falso.
EJBCA 6.4.0 a EJBCA 6.4.2
EJBCA 6.4.2 añade un par de reglas adicionales a los auditores existentes introducidos desde la versión 6.4.0, así como a sus análogos (es decir, un administrador con permisos de edición también tendrá permisos de visualización). Esta actualización se realizará automáticamente y la versión de la base de datos se establecerá en 6.4.2.
Los cambios serán los siguientes. Todos los roles que coincidan con los de Auditores de la versión 6.4.0 recibirán el conjunto completo de reglas, mientras que los que no sean auditores se gestionarán de la siguiente manera:
Reglas a las que se accede actualmente | Reglas de acceso futuro |
/funcionalidad_del_sistema/editar_configuración_del_sistema | /funcionalidad_del_sistema/ver_configuración_del_sistema |
/funcionalidad_del_sistema/editar_usos_de_claves_extendidas_disponibles | /funcionalidad_del_sistema/ver_usos_de_claves_extendidas_disponibles |
/funcionalidad_del_sistema/editar_extensiones_de_certificado_personalizadas_disponibles | /funcionalidad_del_sistema/ver_extensiones_de_certificado_personalizadas_disponibles |
/funcionalidad_del_sistema/editar_privilegios_de_administrador | /funcionalidad_del_sistema/ver_privilegios_de_administrador |
Los auditores recibirán todas las reglas anteriores, además de:
/ra_funcionalidad/entidad_final_vista
Las páginas adicionales disponibles para el Auditor son las siguientes:
Entidades finales de búsqueda
Roles de administrador
Configuración de CMP
Configuración de SCEP
Configuración del sistema
EJBCA 6.3.2 hasta EJBCA 6.4.0
La actualización a la versión 6.4.0 requerirá algunas modificaciones menores en las reglas de acceso, que se implementarán después de la actualización. Todas estas modificaciones generan mayor granularidad, por lo que, si bien los roles tendrán acceso a todo lo que no tenían antes de la actualización, las reglas se pueden restringir manualmente después de la actualización para que el control de acceso sea más restrictivo.
Nuevas reglas de acceso para auditores
Se ha añadido un nuevo rol predeterminado llamado "Auditor", con acceso a todas las páginas, pero sin permisos para realizar cambios ni acciones. Para adaptarlo, se añadieron nuevas reglas, lo que permitió una mayor precisión en la autorización de ciertas páginas de la interfaz gráfica. Durante la actualización, todos los roles que anteriormente tenían permisos de acceso con las reglas anteriores tendrán acceso automáticamente a la nueva regla. Estos son los siguientes:
Cualquier rol que tuviera acceso a: Ahora también tendrá acceso a:
/ca_functionality/funciones_básicas/activar_ca o /ca_functionality/ver_ca
/ca_functionality/ (recursiva)
/ca_functionality/editar_perfiles_de_certificado /ca_functionality/ver_perfiles_de_certificado
/ca_funcionalidad/editar_editor /ca_funcionalidad/ver_editor
/ra_functionality/editar_perfiles_de_entidad_final /ra_functionality/ver_perfiles_de_entidad_final
/ /servicios/editar y /servicios/ver
/internalkeybinding /internalkeybinding/view (recursivo)
Las páginas que estarán disponibles para este nuevo rol son las siguientes:
Activación de CA
Estructura de CA y CRL
Perfiles de certificado Los perfiles de certificado anteriormente no eran accesibles (debido a la falta de acceso a las CA o
El acceso root se procesará solo como vista.
Autoridades de certificación Ahora se incluirán todas las CA (en lugar de solo aquellas a las que el administrador tenía acceso, pero
Los que no tengan acceso aparecerán en gris.
Perfiles de entidad final
Editores
Tokens criptográficos
Servicios
Atajos de teclado internos
XKMS ya no es compatible
La compatibilidad con XKMS se eliminó y ya no está disponible. Al actualizar a EJBCA 6.4.0, se eliminarán los almacenes de claves internos de XKMS y, al actualizarse en un clúster con un tiempo de actividad del 100 %, la opción XKMS en versiones anteriores de EJBCA también desaparecerá.
Los usos de clave extendidos y la extensión de certificado personalizado se importan a la base de datos desde los archivos de configuración previamente estáticos:
Los archivos de configuración "extendedkeyusage.properties" y "certextensions.properties" se leen automáticamente en la base de datos EJBCA durante la implementación del nuevo código. Los cambios futuros en los Usos Extendidos de Clave y las Extensiones de Certificado Personalizadas deberán realizarse a través de la GUI de Administración, en "Configuración del Sistema" -> "Usos Extendidos de Clave" y "Configuración del Sistema" -> "Extensiones de Certificado Personalizadas".
En el caso de la extensión de certificado personalizada, solo se importan a la base de datos las extensiones con 'id<ID>.used=true'. Tenga en cuenta que las extensiones relacionadas con las respuestas de OCSP no se ven afectadas. Solo se afecta la gestión del contenido de los archivos 'extendedkeyusage.properties' y 'certextensions.properties'.
Nuevas reglas de acceso para actualizar los usos de claves extendidas y las extensiones de certificados personalizados
Se han añadido nuevas reglas de acceso para añadir, eliminar o editar usos extendidos de clave y extensiones de certificado personalizadas. Durante la actualización, todos los roles que anteriormente tenían el derecho de acceso "/system_functionality/edit_systemconfiguration" tendrán acceso automático a las nuevas reglas "/system_functionality/edit_available_extended_key_usages" y "/system_functionality/edit_available_custom_certificate_extensions".
Cambios en las extensiones de certificados personalizados
Se han implementado varios cambios en la forma en que se manejan las extensiones de certificados personalizados:
Las extensiones de certificado personalizadas disponibles ya no están limitadas a solo 255 extensiones: se ha eliminado la limitación sobre la cantidad de extensiones de certificado personalizadas que EJBCA puede tener disponibles al mismo tiempo.
Las extensiones de certificado personalizadas usadas en un perfil de certificado ahora se identifican por sus OID: Antes, las extensiones de certificado personalizadas usadas en un perfil de certificado eran una lista de números que representaban los ID de las extensiones. Ahora, esto se ha cambiado a una lista de cadenas que representan los OID de las extensiones. Esto se logra añadiendo un nuevo campo que contiene los OID de las extensiones de certificado personalizadas usadas. El campo que contiene la lista de ID no se modifica, pero todas las funciones ahora hacen referencia al nuevo campo que contiene la lista de OID. De esta forma, una versión anterior de EJBCA puede seguir funcionando con el contenido de una base de datos más reciente sin interrumpir ninguna función.
Las extensiones de certificado personalizadas deben implementar la interfaz de marcador CustomCertificatExtension
EJBCA 6.3.1 hasta EJBCA 6.3.2
Dado que el VA Publisher se cambió de Community a Enterprise en EJBCA 6.3.1.1, tuvo que cambiar la clase base, por lo que requerirá una actualización de la base de datos. Para mantener el requisito de disponibilidad del 100%, siga el siguiente procedimiento:
1. Actualice EJBCA en todos los nodos. Los publicadores antiguos seguirán funcionando en los nuevos nodos, pero no se podrán editar en la GUI durante la...
procedimiento de actualización.
2. Ejecute "ant post-upgrade" en cualquiera de los nodos e ingrese "6.3.1" (esta será la versión actual de la base de datos). Esta operación
Reemplazará a todos los editores antiguos por los nuevos.
3. Verifique que los publicadores estén configurados correctamente y puedan publicar certificados y CRL.
EJBCA 6.2.x hasta EJBCA 6.3.1.1
EJBCA 6.3.1.1 es la versión Community de EJBCA 6.3. Además de incluir todos los pasos de actualización de versiones anteriores, el mayor cambio en la base de datos de EJBCA 6.3.1.1 es que el VA Publisher se ha trasladado de la Community Edition a la Enterprise Edition. Dado que la clase anterior (y el código que la soporta) ya no existe en Community Edition, una clase de marcador de posición que conserva todos los datos antiguos reemplazará a los antiguos publicadores para conservar los datos, pero publicar con esta clase no tendrá ningún efecto. Si algún usuario de Community Edition desea migrar a la Enterprise Edition, el marcador de posición será reemplazado por el nuevo VA Publisher.
La RA externa también se ha eliminado de la Edición Comunitaria en la versión 6.3.1.1. Si utiliza la Edición Comunitaria y necesita estas funciones, póngase en contacto con un representante de ventas de Primekey Solutions.
EJBCA 6.2.7 hasta EJBCA 6.3.0
EJBCA 6.3.0 introduce una nueva tabla, PeerData. Esta tabla se crea automáticamente durante la implementación en el servidor de aplicaciones. Si prefiere actualizar la base de datos manualmente, consulte src/upgrade para obtener scripts SQL específicos para su base de datos.
Se han trasladado ciertas funciones de la versión Community a la Enterprise de EJBCA, entre ellas el modo SCEP RA, el proxy CMP y los campos DN específicos del certificado EV. Si utiliza la versión Community y necesita estas funciones, póngase en contacto con un representante de ventas de Primekey Solutions.
EJBCA 6.2.7 a EJBCA 6.2.8
Se ha realizado un cambio mínimo en la gestión del perfil de entidad final "VACÍO" (predeterminado). Las versiones anteriores requerían acceso root (acceso a "/" en el árbol de reglas de administración) para usar este perfil, pero como desde hace algunas versiones generamos permisos para este perfil como cualquier otro, ahora se usan estos.
La firma de las respuestas OCSP solo se verifica para la primera respuesta creada por cada emisor tras recargar la caché de firmantes OCSP. Anteriormente, siempre se verificaba cada respuesta. (Esto sirve para detectar HSMs con fallos. La seguridad de la validación de respuestas es responsabilidad del cliente OCSP). Utilice la comprobación de estado para detectar HSMs con fallos si almacena en caché los firmantes OCSP durante un tiempo prolongado y desea detectarlos.
Se han creado reglas para el uso de la GUI con gran detalle.
Las diferencias son:
Se accede a los perfiles de entidad final a través de "/endentityprofilesrules" en lugar del obsoleto "/super_administrator".
El perfil de entidad final "VACÍO" tiene reglas de acceso como cualquier otro perfil.
Ahora se accede a la configuración del sistema a través de /system_functionality/edit_systemconfiguration en lugar de "/" en versiones anteriores
La regla /ca_functionality/edit_publishers ahora es todo lo que se requiere para acceder a la página del editor en la GUI y a todos los editores asignados.
Los permisos asignados a una CA a la que el administrador tiene acceso, o que no estén asignados a ninguna CA, aparecerán en la lista. La plantilla de rol "Administrador de CA" tiene acceso a esta regla.
Estos cambios no requieren ninguna acción durante ni después de la actualización. Dado que las reglas anteriores eran de nivel inferior o no se podían seleccionar debido a su obsolescencia, cualquier usuario con acceso a ellas también debe tener acceso a las nuevas. Dado que las nuevas reglas son más específicas que las anteriores, se presume que cualquier usuario que acceda a los recursos afectados es intencional, pero se deben realizar pruebas para cualquier rol personalizado.
EJBCA 6.2.x a EJBCA 6.2.7
Se ha modificado ligeramente el comportamiento del respondedor OCSP para mejorar el rendimiento. El estado de la CA del certificado de firma OCSP ahora solo se comprueba al recargar la caché, en lugar de cada solicitud. Si no está seguro de la duración del tiempo de espera, consulte el valor ocsp.signingCertsValidTime en ocsp.properties.
EJBCA 6.2.x a EJBCA 6.2.4
La configuración del respondedor predeterminado de OCSP se ha trasladado de ocsp.properties a la configuración global, a un nuevo caché con ID=OCSP.
El valor anterior se guardará automáticamente en la base de datos por el primer nodo actualizado. Si ocsp.properties no apuntaba a un DN de sujeto que coincidiera con una CA o una combinación de teclas de OCSP existente, el valor anterior se conservará hasta que se cree una CA o una combinación de teclas coincidente, o hasta que se seleccione una CA o una combinación de teclas válida en la interfaz gráfica.
Se ha modificado el comportamiento predeterminado del respondedor predeterminado para responder automáticamente a todas las CA importadas externamente que carecen de atajos de teclado OCSP específicos. Tenga en cuenta que esto puede causar un comportamiento inesperado si existe un atajo de teclado inactivo (debido a la revocación o vencimiento del certificado del respondedor), y que este atajo de teclado tiene un comportamiento diferente al del respondedor predeterminado con respecto a los certificados desconocidos.
EJBCA 6.1.x a EJBCA 6.1.y
Consulte el procedimiento y las notas para actualizar de 6.0.x a 6.0.x.
En EJBCA 6.1.2, se ha reescrito la gestión de la configuración de SCEP. Las configuraciones de SCEP ya no se leen desde el archivo conf/scep.properties; en su lugar, se configuran mediante la línea de comandos (ejecute './bin/ejbca.sh config scep' desde el directorio principal de EJBCA para consultar la documentación de la línea de comandos).
Si usa SCEP, debe cargar su antiguo archivo scep.properties a EJBCA después de la actualización. Puede hacerlo ejecutando el siguiente comando en el directorio de inicio de EJBCA:
./bin/ejbca.sh configuración scep archivo de carga conf/scep.properties scep
La nueva URL será: http://HOST:PORT/ejbca/publicweb/apply/scep/CONFIGURATION_ALIAS/pkiclient.exe
Si utiliza la URL: http://HOST:PORT/ejbca/publicweb/apply/scep/noca/pkiclient.exe
o la URL: http://HOST:PORT/ejbca/publicweb/apply/scep/ra/noca/pkiclient.exe
Debe establecer la propiedad 'ALIAS.includeca' en 'false' en la línea de comando ejecutando lo siguiente desde el directorio de inicio de EJBCA:
./bin/ejbca.sh config scep updatealias ALIAS includeca false
Si está utilizando RA externa, tenga en cuenta que el nombre del archivo scep.properties se ha cambiado a scepra.properties
EJBCA 6.0.x a EJBCA 6.1.x
La actualización de EJBCA 6.0 a 6.1 consiste en un simple cambio en la tabla KeyRecoveryData de la base de datos. Si el usuario de la base de datos utilizado para EJBCA tiene privilegios de modificación de tabla, la actualización se realizará automáticamente al implementar la nueva versión de EJBCA (actualización del complemento) e iniciar JBoss. Si prefiere actualizar la base de datos manualmente, consulte src/upgrade para obtener los scripts SQL de su base de datos específica.
Notas de actualización con un tiempo de actividad del 100 %
No debería haber problemas al pasar de EJBCA 6.0 a 6.1; las versiones anteriores de EJBCA se ejecutarán con las columnas de base de datos adicionales agregadas a KeyRecoveryData.
Si tenía KeyrecoveryData existente, debe establecer la nueva columna cryptoTokenId en 0 (consulte src/upgrade/600_610).
actualizar el conjunto KeyRecoveryData cryptoTokenId=0;
Desde EJBCA 6.1.0, las respuestas OCSP ya no incluyen el certificado de la CA raíz, a menos que esta sea el firmante de OCSP y esté configurada para incluirlo. Mantener las respuestas OCSP lo más pequeñas posible es una característica importante del rendimiento, y dado que el cliente debe tener el certificado raíz como de confianza, no es necesario incluirlo en la cadena.
Si recibe un error "java.lang.NoSuchMethodError" en la interfaz gráfica de administración, se debe a que JBoss (5) no limpia bien los archivos temporales. Elimine los directorios JBOSS_HOME/server/default/tmp y JBOSS_HOME/server/default/work y reinicie JBoss para que funcione.
EJBCA 5.0.x a EJBCA 6.0.x
Procedimiento básico de actualización para EJBCA
El objetivo "ant bootstrap" ha quedado obsoleto y ahora está cubierto por el objetivo "ant deploy". Se ha modificado el comportamiento de "ant deploy" y el comando anterior es equivalente a la siguiente secuencia:
despliegue de hormigas
almacén de claves de implementación de hormigas
configuración web de hormigas
(También hay un objetivo ant deployear que solo implementa un archivo ejbca.ear actualizado, excelente para actualizar o cambiar la configuración)
Para obtener más información sobre las nuevas instrucciones de implementación y los objetivos de Ant, consulte Instalación de EJBCA .
¡Primero haz una copia de seguridad de tu base de datos! Si la actualización falla, siempre puedes volver a la versión anterior.
Si está actualizando un clúster, actualice el software en todos los nodos.
Copie conf/*.properties de la instalación anterior en el directorio conf de la nueva versión.
O mejor aún, utilice la función ejbca-custom para realizar actualizaciones más fácilmente; consulte la Guía de operaciones de EJBCA
Si está utilizando la base de datos Hypersonic predeterminada en JBoss 5, ahora debe configurarla en database.properties (la base de datos de prueba predeterminada ahora es para JBoss 7/EAP6).Copie el directorio 'p12' de la instalación anterior.
Si utiliza JBoss 5.1 o una versión anterior, apague JBoss.
Ejecute el objetivo 'ant deploy' con la nueva versión.
Ejecute el objetivo 'ant deploy-keystore' con la nueva versión (no es necesario si se implementa en la misma instancia de JBoss que la versión anterior).
Ejecute el objetivo 'ant web-configure' con la nueva versión (no es necesario si se implementa en la misma instancia de JBoss que la versión anterior).
Borre los directorios temporales y de trabajo en los servidores, luego reinicie JBoss.
Si está ejecutando un clúster, ahora debe actualizar en todos los nodos del clúster.
Los nodos recién implementados deberían estar ejecutándose ahora.Reinicie JBoss para vaciar todos los cachés.
Vaya a la GUI de administración y verifique su configuración.
Si obtiene un "java.lang.NoSuchMethodError" en la GUI de administración es porque JBoss 5 no limpia muy bien los archivos temporales.
Elimine los directorios JBOSS_HOME/server/default/tmp y JBOSS_HOME/server/default/work y reinicie JBoss para que funcione.
Si está actualizando desde EJBCA 4.x, también necesita ejecutar objetivos de actualización adicionales; consulte las notas de actualización de EJBCA 4 a EJBCA 5.
Procedimiento básico de actualización para autoridades de validación
Cambios notables
Se ha eliminado la compilación de autoridad de validación externa y las implementaciones de VA externas ahora son implementaciones EJBCA completas.
Los privilegios de la base de datos en el host VA deben ser los mismos que los utilizados por la CA (todas las tablas deben existir).
Los almacenes de claves, certificados y almacenes de confianza (tanto los basados en software como en HSM) se convertirán automáticamente en el primer inicio.
(o tan pronto como la contraseña esté disponible mediante clientToolBox si ocsp.activation.doNotStorePasswordsInMemory=true) para CryptoTokens y OcspKeyBindings.
Los certificados de confianza (ocsp.signtrustdir) deben importarse en EJBCA como "CA externas", por ejemplo, utilizando el comando "bin/ejbca.sh ca importcacert".
La URL de verificación de estado ahora es la misma que para las instalaciones de CA y verificará la usabilidad de OcspKeyBindings ACTIVOS.
OcspKeyBindings y CryptoTokens aún se pueden administrar sin AdminGUI usando la CLI EJB (bin/ejbca.sh).
Los certificados de firma o renovación de claves de OCSP ya no necesitan estar presentes en la ranura HSM (migrados a la tabla CertificateData).
El uso de un CryptoToken activado manualmente reemplaza el uso de ocsp.activation.doNotStorePasswordsInMemory.
Ahora se puede configurar el comportamiento de las respuestas de OCSP (como untilNextUpdate, etc.) por OcspKeyBinding.
(La configuración específica del perfil de certificado o de la URL en ocsp.properties tiene la máxima prioridad, luego las propiedades OcspKeyBinding y, finalmente, la configuración predeterminada en ocsp.properties).
El almacén de claves de renovación de claves se migrará a un AuthenticationKeyBinding.
La gestión de *KeyBindings y CryptoTokens se auditará. Configúrela antes de la actualización para una trazabilidad adecuada a partir de ahora.
La propiedad 'ejbca.productionmode' debe establecerse en 'true' o 'false'. Las opciones 'va' u 'ocsp' ya no son compatibles.
Algunas opciones de configuración de ocsp.properties se han trasladado a web.properties (o han quedado obsoletas en este último). Debe migrar estos cambios de configuración. Recibirá una advertencia durante la compilación si utiliza estas opciones y no las ha migrado.
Uso de tokens criptográficos, donde se pueden configurar varios tokens. El respondedor ya no está limitado a una sola configuración PKCS#11 en ocsp.properties.
Uso de la vinculación de claves interna, que permite configurar pares de claves específicos que coincidan con certificados específicos en la base de datos. Esto permite una configuración flexible y sencilla de claves y certificados de respuesta de OCSP. Ya no es necesario importar el certificado de firmante de OCSP a una ranura del HSM.
Uso de la interfaz gráfica de administración. Ahora puede usar la interfaz gráfica de administración de EJBCA para administrar tokens criptográficos y enlaces de claves, lo que simplifica enormemente la configuración y administración del respondedor OCSP.
La comprobación de estado de OCSP se ha integrado en la comprobación de estado estándar de EJBCA, por lo que no se requiere una llamada independiente.
Todo esto significa que la actualización desde una versión anterior de EJBCA OCSP es un proceso. EJBCA 6 gestiona toda la actualización automáticamente e intentará importar su configuración anterior sin problemas. Para aprovechar todas las nuevas funciones, consulte la Guía de instalación de VA, la Guía de instalación de OCSP y la Guía del usuario en la documentación.
Proceso de actualización
1. Copie los archivos de configuración, database.properties, ocsp.properties y web.properties de su instalación anterior.
2. Tenga en cuenta que puede haber algunas propiedades obsoletas (j2ee.web-noconfigure). Se le notificará al respecto durante la compilación.
3. Configure el registro en conf/cesecore.properties si no desea auditar eventos de seguridad del registro en la base de datos (consulte Instalación de OCSP).
4. Construya y configure el VA EJBCA como se describe en "Instalación de VA independiente".
5. Al iniciar JBoss por primera vez, se crearán nuevas tablas de base de datos. Estas son las mismas tablas que existen en una instalación EJBCA. Si el usuario de la base de datos tiene acceso restringido, puede crear las tablas manualmente desde los scripts de base de datos en doc/sql-scripts.
6. El siguiente paso implica crear enlaces de teclas OCSP, que son objetos que representan un respondedor OCSP externo.
a. Si se permite almacenar contraseñas en memoria (ocsp.activation.doNotStorePasswordsInMemory=true en ocsp.properties), todas las asignaciones de teclas se crean automáticamente. Al iniciar JBoss por primera vez, se leerá ocsp.properties y se actualizará a tokens criptográficos y asignaciones de teclas de ocsp. Esto creará objetos en su base de datos en CryptoTokenData e InternalKeyBindingData. También se crearán las reglas de acceso iniciales; consulte "Instalación de OCSP" para obtener más información.
b. Si las contraseñas no están almacenadas en la memoria, es necesario abrir la ranura. Para ello, ejecute el comando OCSPActivate en clientToolBox; la asignación de teclas interna se creará automáticamente en la primera llamada.
7. Si necesita solicitudes firmadas y verificadas por CA específicas, debe importar esos certificados de CA como "CA externas" en EJBCA y configurar los anclajes de confianza en el enlace de claves de OCSP (use bin/ejbca.sh ca importcacert o la GUI de administración).
Publicar actualización
Una vez que todos los respondedores OCSP se hayan recreado como enlaces de claves OCSP y tokens criptográficos, se pueden eliminar las siguientes propiedades de ocsp.properties
ocsp.restringir firmas
ocsp.restringir firmas por método
ocsp.signtrustdir
ocsp.signtrustvalidtime
ocsp.keys.dir
ocsp.keys.storePassword
ocsp.keys.contraseña
ocsp.activation.doNotStorePasswordsInMemory
ocsp.p11.biblioteca compartida
ocsp.p11.sunConfigurationFile
ocsp.p11.p11contraseña
ocsp.p11.ranura
Notas de actualización con 100 % de tiempo de actividad
Actualización de CryotoTokens
El concepto CryptoToken ha ampliado el concepto de token interno de CA. Las CA ahora hacen referencia a un conjunto de claves con nombre en un CryptoToken, y la activación del servicio de CA y del CryptoToken está claramente separada. Las actualizaciones se realizan durante el primer arranque. Los nodos EJBCA más antiguos seguirán funcionando durante una actualización con un tiempo de actividad del 100 %, siempre que se hayan implementado instancias más nuevas con "db.keepinternalcakeystores" configurado como verdadero. Para una actualización con un tiempo de actividad del 100 %, o para poder revertir la actualización, configure db.keepinternalcakeystores como verdadero (el valor predeterminado es falso).
Las configuraciones relevantes para actualizaciones con un tiempo de actividad del 100 % son:
db.keepinternalcakeystores (5.0->5.2)
serialización de db.keepjboss (4.0->5.0)
app.version.effective (3.11->4.0)
Actualización del servicio extendido de CA de OCSP
El servicio para ejecutar servicios OCSP en CA internas se ha convertido en parte integral del respondedor OCSP. Por este motivo, el antiguo Servicio Extendido de CA se eliminará al iniciar un sistema de la versión 5.0 a la 6.0. Como resultado, los nodos que comparten una base de datos y que no se hayan actualizado a la versión 6.0 perderán los servicios OCSP hasta que se actualicen. Para mantener los servicios OCSP internos en funcionamiento (los servicios OCSP externos no se ven afectados) en todo el clúster durante todo el proceso de actualización, configure "ca.keepocspextendedservice" como 'true' para todos los nodos excepto el último, que finalmente eliminará el servicio de la base de datos.
- ca.keepocspextendedservice (5.0 -> 6.0)
Manejo de la configuración de CMP
En EJBCA 6.0.0, se ha reescrito la gestión de la configuración de CMP. Las configuraciones de CMP ya no se leen desde el archivo conf/cmp.properties; ahora se pueden configurar en la interfaz gráfica de usuario (GUI) del administrador o en la línea de comandos (ejecute './bin/ejbca.sh config cmp' desde el directorio principal de EJBCA para consultar la documentación de la línea de comandos). Si usa CMP, puede cargar su antiguo archivo cmp.properties ejecutando el siguiente comando en el directorio principal de EJBCA:
$ ./bin/ejbca.sh config cmp uploadfile --file conf/cmp.properties --alias cmp
En la interfaz de administración -> Configuración de CMP, verá el alias "cmp" en la lista de alias de CMP. Este alias contendrá todos sus CMP antiguos.
configuraciones (excepto una, consulte la siguiente nota) y deben usarse para administrar sus configuraciones de CMP en el futuro.
Para usuarios de CMP que usan NestedMessageContent en modo RA y EndEntityCertificate como módulo de autenticación: si ahora omiten algunas verificaciones del certificado en el campo extraCert estableciendo el parámetro de autenticación de EndEntityCertificate en '-', esto ya no será posible en EJBCA 6.0.0. En su lugar, se debe configurar una nueva variable de configuración para reflejar esta opción. Después de cargar el archivo conf/cmp.properties según las instrucciones anteriores, vaya a la interfaz de administración -> Configuraciones de CMP; en la página para editar el alias de CMP 'cmp', marque la casilla "Omitir verificaciones en el módulo de autenticación EndEntityCertificate". Para los usuarios de CMP que usan KeyUpdateRequest en modo RA, en EJBCA 6.0.0, el módulo de autenticación EndEntityCertificate debía estar configurado entre los módulos de autenticación; de lo contrario, la solicitud fallará.
En EJBCA 6.0.0, las configuraciones TCP se han trasladado del archivo conf/cmp.properties (eliminado) a conf/cmptcp.properties. Por lo tanto, si utiliza TCP (un protocolo obsoleto en EJBCA y la RFC), debe configurar sus valores de configuración TCP en el nuevo archivo. También debe cargar el archivo conf/cmp.properties según las instrucciones anteriores y cambiar el alias "cmp" a "tcp". Consulte la Guía del administrador -> CMP -> "CMP sobre TCP" y ejecute "./bin/ejbca.sh config cmp" para obtener más información.
Comandos CLI renombrados
Los comandos CLI se han actualizado para reflejar la nueva nomenclatura introducida en EJBCA 5.0. Esto implica principalmente el cambio del comando "admins" -> "roles" (para reflejar que los Grupos de Administración ahora se llaman Roles) y de los subcomandos bajo "ra", que se han renombrado para reflejar el cambio de nombre de "Usuario" a "Entidad Final" (por ejemplo, adduser -> addendentity). Los comandos antiguos han quedado obsoletos, pero siguen funcionando y podrían eliminarse por completo en una versión futura.
Asuntos varios
batchtool.properties ya no se busca en bin/, sino en conf/. Tenga en cuenta que todo el contenido de este archivo está comentado por defecto, por lo que puede eliminarse si no se ha modificado.
En EJBCA 6.0.0 se incluyen nuevas versiones de los archivos jar de BouncyCastle. Si ha estado copiando archivos ejbca/lib/bc*.jar a JBoss (jboss/server/default/lib), debe eliminar los archivos jar antiguos de JBoss y copiar los nuevos desde EJBCA.
En EJBCA 6.0.0, se modificó la API para extensiones de certificado personalizadas. Si ha creado sus propias clases Java de extensión de certificado personalizadas, debe actualizar la API con un nuevo argumento (puede ser nulo). No se produce ningún efecto si se utilizan extensiones personalizadas estándar en certextensions.properties, solo clases Java personalizadas.
En EJBCA 6.0.5, se cambió el nombre del archivo del logotipo de la interfaz web pública. Si ha personalizado su propio logotipo, debe cambiar el nombre del archivo de "logotype.png" o "ejbca_pki_by_primekey_logo.png" a "banner_ejbca-public.png".
A partir de EJBCA 6.0.0, los servicios y publicadores personalizados se detectan automáticamente mediante metadatos en los archivos JAR, y los nombres de clase ya no se pueden especificar manualmente. Si necesita usar clases personalizadas antiguas de versiones anteriores a la 6.0 (es decir, clases que no se detectan automáticamente), puede habilitar la entrada manual con la opción web.manualclasspathsenabled=true en web.properties.
La clase CliAuthenticationToken y sus clases asociadas se han trasladado del módulo CLI para ubicarse junto a las demás clases de autenticación en src. Esto significa que las solicitudes de aprobación que utilicen el CliAuthenticationToken creado en la versión 5.0.x no serán compatibles con versiones posteriores.
Las bibliotecas PKCS#11 que se presentan en la interfaz gráfica de administración se detectan automáticamente. Si tiene una biblioteca que EJBCA no detecta automáticamente, puede agregarla a la configuración. Consulte web.properties.sample para ver la configuración de detección automática de bibliotecas PKCS#11.
Las opciones de configuración de HSM se han actualizado para admitir diferentes tipos de referencia de ranura (ID de ranura, índice o etiqueta).
Consulte la Guía del administrador, databaseprotection.properties.sample, ocsp.properties.sample y catoken.properties.sample para obtener información y ejemplos sobre cómo actualizar la configuración actual de PKCS#11 en estos archivos. La configuración en la interfaz gráfica de usuario del administrador debería actualizarse automáticamente.
Si utiliza la base de datos Hypersonic predeterminada en JBoss 5 para realizar pruebas, deberá configurarla en database.properties. La base de datos de prueba predeterminada (cuando no se configura database.properties) ahora es H2 para JBoss 7/EAP6.
EJBCA 4.0.x a EJBCA 5.0.x
Notas de actualización con un tiempo de actividad del 100 %
Para algunas clases serializadas, la serialización se ha cambiado a un formato portátil. Para garantizar una actualización con un tiempo de actividad del 100% o la posibilidad de cancelar la actualización, configure db.keepjbossserialization como verdadero (el valor predeterminado es falso). Una vez actualizados todos los nodos, puede volver a configurar db.keepjbossserialization como falso.
La compatibilidad con el antiguo LogEntryData se ha eliminado en EJBCA 5.0 y se ha reemplazado por el nuevo AuditRecordData. Si necesita registros de auditoría antiguos, exporte los registros antes de actualizar. También existe una herramienta para exportarlos después de la actualización. La nueva función de registro de auditoría permite proteger los registros de auditoría y, al mismo tiempo, es compatible con clústeres.
EJBCA 5.0 introduce un nuevo mecanismo de control de acceso que ofrece más funcionalidad y operaciones más definidas. Algunas reglas de acceso antiguas, como la del superadministrador, han cambiado y deben modificarse después de la actualización. Se recomienda verificar los roles y reglas de acceso después de una actualización.
¡Primero haz una copia de seguridad de tu base de datos! Si la actualización falla, siempre puedes volver a la versión anterior. Si estás actualizando un clúster, actualiza el software en todos los nodos.
1. Copie conf/*.properties de la instalación anterior en el directorio conf de la nueva versión.
O mejor aún, utilice la función ejbca-custom para realizar actualizaciones más fácilmente, consulte la Guía del usuario.
2. Copie el directorio 'p12' de la instalación anterior.
3. Cierre JBoss y realice un 'bootstrap ant' con la nueva versión.
4. Inicie JBoss.
5. Emita el comando 'ant upgrade' desde EJBCA_HOME.
Esto actualizará las reglas de acceso a reglas que sean compatibles con el nuevo sistema de control de acceso.
6. Si está ejecutando un clúster, ahora debe actualizar (arranque ant) en todos los nodos del clúster.
Los nodos recién implementados deberían estar ejecutándose ahora.
7. Realice una 'actualización posterior de hormigas' en uno de los nodos.
Esto realizará las actualizaciones necesarias de la base de datos.
En algunos servidores de aplicaciones es posible que tengas que actualizar la base de datos manualmente, consulta a continuación.
Esto también actualizará los objetos CertificateProfile y los posibles objetos CA en la base de datos.
Después de esta actualización, es posible que no sea posible volver a la versión EJBCA 4.0.x.
8. Detenga JBoss, borre los directorios tmp y work en los servidores, luego inicie JBoss nuevamente para vaciar todos los cachés.
9. Vaya a la GUI de administración y verifique su configuración.
La actualización del esquema de la base de datos normalmente se realiza de manera automática cuando ejecuta 'ant post-upgrade'.
Sin embargo, algunos servidores de aplicaciones no le permitirán realizar la implementación a menos que la base de datos esté sincronizada (o su usuario de base de datos puede no tener privilegios para actualizaciones de esquema), por lo que es posible que tenga que ejecutar los comandos SQL manualmente.
Consulte src/upgrade/400_500 para encontrar los archivos sql correctos para su base de datos.
Una nota práctica es que al actualizar desde EJBCA 4.0 no puede usar la CLI en EJBCA 5.0 antes de haber terminado de migrar todos sus nodos 4.0 y ejecutar la actualización posterior.
Si necesita degradar EJBCA a 4.0.x nuevamente después de una 'actualización posterior a la hormiga' completada, debe volver a agregar la columna de base de datos eliminada (caId en AdminEntityData, el valor 0 está bien) en la base de datos.
Debería ser posible volver a la versión 4.0.4 después de una "actualización posterior a la hormiga" en EJBCA 5.0.
Debería poder actualizar desde EJBCA 3.11.x directamente a 5.0.x, siguiendo las mismas instrucciones mencionadas anteriormente (aunque esta actualización no ha sido probada exhaustivamente).
Algunas opciones de configuración de ejbca.properties se han trasladado a cesecore.properties. Debe migrar estos cambios de configuración.
Se le advertirá durante la compilación si está utilizando estas opciones y no las ha migrado.
Si obtiene un "java.lang.NoSuchMethodError" en la GUI de administración es porque JBoss no limpia muy bien los archivos temporales.
Elimine los directorios JBOSS_HOME/server/default/tmp y JBOSS_HOME/server/default/work y reinicie JBoss para que funcione.
Es posible que veas roles de administrador "nuevos" después de la actualización.
PREDETERMINADO: Este rol se puede eliminar de forma segura. Lo usaba internamente EJBCA.
Usuarios web públicos: este rol se puede eliminar de forma segura. EJBCA lo usaba internamente.
Rol de superadministrador: Este rol contiene el usuario de la CLI ejbca. Si elimina los permisos del usuario ejbca, no podrá usar la CLI.
Nota para la actualización a 5.0.6
En EJBCA 5.0.6 se incluyen nuevas versiones de los archivos jar de BouncyCastle. Si ha estado copiando archivos ejbca/lib/bc*.jar a JBoss (jboss/server/default/lib), debe eliminar los archivos jar antiguos de JBoss y copiar los nuevos desde EJBCA.
EJBCA 3.11.x a EJBCA 4.0.x
Si instaló desde cero o actualizó a EJBCA 3.11.0 o EJBCA 3.11.1 en MySQL, comience por leer la siguiente sección antes de continuar.
Se ha eliminado la compatibilidad con ProtectedLog, obsoleto en EJBCA 3.10.0. Si utiliza esta función, exporte los registros antes de actualizar. Si los datos de estas tablas se almacenan de forma segura en otro lugar o si nunca ha utilizado esta función, puede eliminar estas tablas e índices.
Se ha eliminado la compatibilidad con la protección de tablas (configurada en proptecion.properties), que quedó obsoleta en EJBCA 3.11. Si no tiene datos en estas tablas, puede eliminar los índices y las tablas.
EJBCA 4.0 requiere un servidor de aplicaciones compatible con JEE5. Para JBoss, esto significa al menos JBoss 5.1.x.
Para obtener detalles sobre cómo debe configurarse el servidor de aplicaciones, consulte el documento de instalación.
Notas para actualizaciones en línea
1. Si estaba ejecutando una versión anterior de EJBCA en un JBoss más antiguo (se recomendaba 4.2.3 para EJBCA 3.x), *y* necesita hacer una actualización en línea (actualizar un nodo del clúster mientras otro está en ejecución), primero debe actualizar su clúster para que se ejecute en JBoss 5.1.x antes de actualizar cualquiera de los nodos del clúster a EJBCA 4.
2. Configure "app.version.effective=3.11.x" en conf/ejbca.properties para todos los nodos que implemente con EJBCA 4.0.x, excepto el último. Comente la propiedad y vuelva a implementar los demás nodos. Esto garantizará que la serialización de JBoss siga funcionando para los nodos EJBCA 3.11.x implementados durante la migración.
Los valores de "customAvailableAccessRules" y "RNGAlgorithm" (generador de números aleatorios) ahora se pueden configurar desde conf/ejbca.properties en lugar de leerse a través del ENC.
La propiedad 'database.name' en database.properties cambió de mssql2000 a mssql para MS-SQL Server.
La propiedad 'database.url' en database.properties ya no necesita escape XML para caracteres '&'.
La propiedad 'ocsp-database.url' en ocsp.properties ya no necesita escape XML para caracteres '&'.
¡Primero haz una copia de seguridad de tu base de datos! Si la actualización falla, siempre puedes volver a la versión anterior.
Si está actualizando un clúster, actualice el software en todos los nodos.
1. Copie conf/*.properties de la instalación anterior en el directorio conf de la nueva versión.
O mejor aún, utilice la función ejbca-custom para realizar actualizaciones más fácilmente, consulte la Guía del usuario.
2. Copie el directorio 'p12' de la instalación anterior.
3. Cierre JBoss y realice un 'bootstrap ant' con la nueva versión.
4. Inicie JBoss.
5. Si está actualizando en JBoss, ejecute "ant post-upgrade" en uno de los nodos. Esto convertirá todos
Los objetos serializados de JBoss se convierten en objetos serializados de Java normales y le permiten cambiar
servidor de aplicaciones en el futuro.
6. Reinicie JBoss nuevamente para vaciar todos los cachés.
7. Vaya a la GUI de administración y verifique su configuración.
Una novedad de EJBCA 4.0 es que contamos con un esquema de base de datos bien definido, funcionalmente igual para todas las bases de datos compatibles. Puede verificar que su esquema de base de datos sea correcto comparándolo con el script de creación de tablas SQL para su base de datos ('doc/sql-scripts/create-tables-ejbca4-{database name}.sql').
Algunos métodos obsoletos se han eliminado en la versión 4.0. Por ejemplo, en la API de publicación. Si usaste estos métodos para crear publicaciones personalizadas, debes actualizar tu código para que coincida con las nuevas interfaces. Para facilitarlo, solo hay nuevos parámetros que no son necesarios.
EJBCA 3.11.0 o 3.11.1 a EJBCA 3.11.x
Lea atentamente RELEASE_NOTES para ver si algún cambio particular podría afectar su actualización.
Normalmente, las actualizaciones dentro de una versión principal son actualizaciones de complementos.
Copie conf/*.properties de la instalación anterior (si no utiliza ejbca-custom).
Fusiona los cambios (si hay alguno) de *.properties.sample en tu *.properties.
Copie el directorio 'p12' de la instalación anterior y realice 'ant deploy' con la nueva versión.
Tenga en cuenta la posibilidad de utilizar el directorio 'ejbca-custom' desde EJBCA 3.5.x, esto puede simplificar las actualizaciones.
Hay un problema que solo afecta a las instalaciones actualizadas o recién instaladas en EJBCA 3.11.0.
La asignación de base de datos para KeyRecoveryData.certSN en _MySQL_ en 3.11.0 era incorrecta y se puede corregir ejecutando:
ALTER TABLE KeyRecoveryData MODIFY certSN varchar(80) binario NO NULO PREDETERMINADO '';
La asignación de base de datos para UserData.cardNumber en el script de creación de tabla en _MySQL_ en 3.11.0 y
Las notas de ACTUALIZACIÓN en 3.11.1 eran incorrectas y se pueden corregir ejecutando:
ALTER TABLE UserData MODIFY cardNumber varchar(250) binario NULL PREDETERMINADO NULL;
La asignación de base de datos para ServiceData.nextRunTimeStamp y runTimeStamp era inconsistente en _Sybase_ en 3.11.0 y se puede corregir ejecutando:
ALTER TABLE ServiceData MODIFY nextRunTimeStamp DECIMAL(20,0) PREDETERMINADO 0 NO NULO;
ALTER TABLE ServiceData MODIFY runTimeStamp DECIMAL(20,0) PREDETERMINADO 0 NO NULO;
ALTER TABLE ServiceData MODIFY runTimeStamp DECIMAL(20,0) PREDETERMINADO 0 NO NULO;
EJBCA 3.10.x a EJBCA 3.11.x
¡Primero haz una copia de seguridad de tu base de datos! Si la actualización falla, siempre puedes volver a la versión anterior.
Si está actualizando un clúster, debe ejecutar el proceso de actualización con solo un nodo en ejecución y luego simplemente actualizar el software en los otros nodos.
1. Copie conf/*.properties de la instalación anterior en el directorio conf de la nueva versión.
O mejor aún, utilice la función ejbca-custom para realizar actualizaciones más fácilmente, consulte la Guía del usuario.
2. Copie el directorio 'p12' de la instalación anterior.
3. Cierre JBoss y realice un 'bootstrap ant' con la nueva versión.
4. Inicie JBoss. Es posible que se produzcan errores durante el inicio debido a que la base de datos aún no se ha actualizado.
5. Ejecute el comando 'ant upgrade' desde EJBCA_HOME. Esto realizará las actualizaciones necesarias de la base de datos.
Nota: En algunos servidores de aplicaciones es posible que tengas que actualizar la base de datos manualmente, consulta a continuación.
6. Realice una 'actualización posterior a la actualización' para asegurarse de que las nuevas columnas de la base de datos en la tabla ServiceData estén completas.
y agregue una nueva columna de base de datos a PublisherQueueData.
7. Reinicie JBoss nuevamente para vaciar todos los cachés.
8. Vaya a la GUI de administración y verifique su configuración.
La actualización de la base de datos normalmente se realiza automáticamente al ejecutar "ant upgrade" y "ant post-upgrade". Sin embargo, algunos servidores de aplicaciones no permiten la implementación a menos que la base de datos esté sincronizada, por lo que podría tener que ejecutar los comandos SQL manualmente. Consulte src/upgrade/310_311 para encontrar los archivos SQL correctos para su base de datos.
Debería poder actualizar de EJBCA 3.2.x directamente a 3.11.x siguiendo las mismas instrucciones anteriores (aunque esta actualización no se ha probado exhaustivamente). Consulte también las instrucciones a continuación para obtener información sobre problemas adicionales al actualizar desde una versión mucho más antigua.
Esto es muy importante, dependiendo de la versión de su base de datos es posible que tenga que realizar algunos pasos adicionales para algunas de las actualizaciones.*
EJBCA 3.9.x a EJBCA 3.10.x
¡Primero haz una copia de seguridad de tu base de datos! Si la actualización falla, siempre puedes volver a la versión anterior.
Si está actualizando un clúster, debe ejecutar el proceso de actualización con solo un nodo en ejecución y luego simplemente actualizar el software en los otros nodos.
1. Copie conf/*.properties de la instalación anterior en el directorio conf de la nueva versión.
O mejor aún, utilice la función ejbca-custom para realizar actualizaciones más fácilmente, consulte la Guía del usuario.
2. Copie el directorio 'p12' de la instalación anterior.
3. Cierre JBoss y realice un 'bootstrap ant' con la nueva versión.
4. Inicie JBoss. Es posible que se produzcan errores durante el inicio debido a que la base de datos aún no se ha actualizado.
5. Ejecute el comando 'ant upgrade' desde EJBCA_HOME. Esto realizará las actualizaciones necesarias de la base de datos.
En algunos servidores de aplicaciones es posible que tengas que actualizar la base de datos manualmente, consulta a continuación.
6. Reinicie JBoss nuevamente para vaciar todos los cachés.
7. Vaya a la GUI de administración y verifique su configuración.
8. Ejecute 'ant post-upgrade' si desea que "Aplicar claves públicas únicas" se verifique con el certificado antiguo (ver a continuación).
En EJBCA 3.10, se ha eliminado código no utilizado relacionado con la propiedad "protection.keyref" en conf/protection.properties. Esto también implica un pequeño cambio en la base de datos, donde se elimina la columna no utilizada TableProtectData.keyRef. Para ver qué cambios estructurales se han realizado en la base de datos, puede encontrar los comandos SQL correspondientes en src/upgrade/39_310/39_310-upgrade-<<database name>>.sql.
Las aprobaciones pendientes durante el proceso de actualización se actualizarán automáticamente. Se trata de objetos Java y no se pueden actualizar manualmente mediante SQL personalizado. Si necesita realizar una actualización manual de SQL, debe procesar todas las aprobaciones pendientes antes de la actualización.
En esta versión también se corregirá una corrección rápida para la tabla LogEntryData, que se difundió en 2005. La columna "comment" (o "comment_" en Oracle) cambiará de nombre a "logComment" en todas las bases de datos. Dado que las versiones de DB2 anteriores a la 9.7 no pueden renombrar columnas, se requiere una operación de actualización masiva en esta base de datos. Los usuarios de DB2 9.7 o superior pueden modificar src/upgrade/39_310/39_310-upgrade-db2.sql para usar "ALTER TABLE LogEntryData RENAME COLUMN comment TO logComment;" en su lugar. Para las demás bases de datos, este cambio de nombre se gestionará automáticamente mediante "ant upgrade". Tenga en cuenta que el registro en OldLogDevice no funcionará durante esta actualización.
La actualización de la base de datos normalmente se realiza de manera automática cuando ejecuta 'ant upgrade'.
Sin embargo, algunos servidores de aplicaciones no le permitirán realizar la implementación a menos que la base de datos esté sincronizada, por lo que es posible que tenga que ejecutar los comandos SQL manualmente.
El ProtectedLogDevice ha quedado obsoleto debido a su difícil configuración y su extrema ineficiencia. Actualmente se planea crear un LogDevice que priorice el no repudio en lugar de la detección de entradas de registro faltantes.
La opción de usar un almacén de claves programable independiente para el respondedor OCSP interno ya no está disponible. La actualización eliminará el almacén de claves programable y las solicitudes OCSP se firmarán directamente mediante el certificado de firma de la CA (actualmente, el comportamiento predeterminado). Las instalaciones externas de OCSP no se verán afectadas.
Para mejorar las pruebas, se ha añadido una nueva opción de configuración que permite cambiar las propiedades utilizadas mediante acceso remoto a EJB usando conf/ejbca.properties#ejbca.productionmode. La configuración predeterminada no permite cambios, pero algunas pruebas del sistema de desarrollo fallarán hasta que se permita.
El módulo de RA externa ahora forma parte del paquete principal de EJBCA y utiliza JPA para la persistencia. Las fuentes de datos utilizadas por los trabajadores se configuran en conf/externalra.properties. Las propiedades de cada trabajador se configuran en Servicios, en la interfaz gráfica de administración. Además, la aplicación externa de RA SCEP ahora se compila a partir del paquete principal y se configura en conf/scep.properties. La documentación está disponible como parte del documento generado. La API no ha cambiado y el cliente anterior debería seguir funcionando, pero los trabajadores de RA externa en EJBCA deben reconfigurarse.
Tenga en cuenta que esta versión incluye un cambio inevitable en la API para las extensiones personalizadas, ya que la clave de CA utilizada para firmar certificados no tiene que ser la misma que la clave de CA activa. Si ha creado clases Java para extensiones personalizadas, debe agregar PublicKey caPublicKey a la lista de parámetros del método getValue. No es necesario gestionar el valor.
Se realizan dos comprobaciones más antes de agregar un certificado. Consulte "Aplicar claves públicas únicas" y "Aplicar DN único" .
Estas comprobaciones están habilitadas en todas las CA existentes antes de la actualización. No debería ser un problema tenerlas habilitadas (los usuarios no suelen compartir las mismas claves o DN de sujeto) en la mayoría de las instalaciones. Sin embargo, si sabe que sus usuarios comparten DN de sujeto o claves, podría deshabilitarlas.
Al ejecutar la actualización ant, se añade una nueva columna en la base de datos (subjectKeyId) para "Aplicar claves públicas únicas". Para comparar la clave pública de los nuevos certificados con los certificados emitidos antes de la actualización, es necesario configurar esta columna (después de la actualización, todas las filas de la columna son nulas). La columna se configura mediante la actualización ant (ver paso 8). Tenga en cuenta que la actualización ant puede tardar algunos minutos si hay muchos certificados en la base de datos. Después de la actualización, se deben aplicar dos nuevos índices para aplicar la unicidad:
crear índice certificatedata_idx9 en CertificateData(subjectKeyId,issuerDN);
crear índice certificatedata_idx10 en CertificateData(subjectDN,issuerDN);
Para poder usar la herramienta de monitoreo de OCSP, la columna 'subjectKeyId' debe agregarse a los respondedores externos de OCSP, pero no es necesario rellenarla. Consulte src/upgrade/39_310/39_310-upgrade-<<database name>>.sql para conocer la sintaxis exacta que debe usar para su base de datos de OCSP.
Debería poder actualizar de EJBCA 3.2.x directamente a 3.10.x siguiendo las mismas instrucciones anteriores (aunque esta actualización no se ha probado exhaustivamente). Consulte también las instrucciones a continuación para obtener información sobre problemas adicionales al actualizar desde una versión mucho más antigua.
Si utiliza bases de datos, en concreto una versión anterior de Derby, es posible que tenga que actualizarla manualmente. Consulte src/upgrade/39_310/39_310-upgrade-derby.sql.
EJBCA 3.8.x a EJBCA 3.9.x
¡Primero haz una copia de seguridad de tu base de datos! Si la actualización falla, siempre puedes volver a la versión anterior.
Si está actualizando un clúster, debe ejecutar el proceso de actualización con solo un nodo en ejecución y luego simplemente actualizar el software en los otros nodos.
1. Copie conf/*.properties de la instalación anterior en el directorio conf de la nueva versión.
O mejor aún, utilice la función ejbca-custom para realizar actualizaciones más fácilmente, consulte la Guía del usuario.
2. Copie el directorio 'p12' de la instalación anterior.
3. Cierre JBoss y realice un 'bootstrap ant' con la nueva versión.
4. Inicie JBoss. Verá algunos errores durante el inicio debido a que la base de datos aún no está actualizada.
5. Ejecute el comando 'ant upgrade' desde EJBCA_HOME. Esto realizará las actualizaciones necesarias de la base de datos.
En algunos servidores de aplicaciones es posible que tengas que actualizar la base de datos manualmente, consulta a continuación.
6. Reinicie JBoss nuevamente para vaciar todos los cachés.
7. Vaya a la GUI de administración y verifique la configuración.
En EJBCA 3.9 hay nuevas posibilidades para filtrar certificados por certificateProfileId y etiquetas.
Esto requiere un pequeño cambio en la base de datos. Para ver qué cambios estructurales se han realizado, puede encontrar los comandos SQL correspondientes en src/upgrade/38_39/38_39-upgrade-<<nombre de la base de datos>>.sql.
La actualización de la base de datos normalmente se realiza de manera automática cuando ejecuta 'ant upgrade'.
Algunos servidores de aplicaciones no permiten la implementación a menos que la base de datos esté sincronizada, por lo que podría ser necesario ejecutar los comandos SQL manualmente. El valor predeterminado del certificadoProfileId para cada nuevo CertificateData es 0.
Si desea asignar el último certificadoProfileId utilizado para el mismo usuario, puede ejecutarlo manualmente
ACTUALIZAR CertificateData ESTABLECER certificateProfileId=(SELECCIONAR certificateProfileId DE UserData
DONDE CertificateData.username=UserData.username);
ACTUALIZAR CertificateData ESTABLECER certificateProfileId=0 donde certificateProfileId es nulo;
Pero esto tomará un tiempo *muy* largo para una población grande.
EJBCA 3.9 también incluye una nueva tabla en la base de datos. Si usa JBoss, esta se crea automáticamente. Si usa otro servidor de aplicaciones, cree la tabla en su base de datos mediante la instrucción de creación de la tabla PublisherQueueData desde uno de los scripts de creación de tablas en doc/howto.
Debería poder actualizar de EJBCA 3.2.x directamente a 3.9.x siguiendo las mismas instrucciones anteriores (aunque esta actualización no se ha probado exhaustivamente). Consulte también las instrucciones a continuación para obtener información sobre problemas adicionales al actualizar desde una versión mucho más antigua.
Si está utilizando la RA externa, debe actualizar a ExtRA 3.9 y seguir las instrucciones de actualización en el paquete ExtRA.
Si ha cambiado el nombre de usuario 'tomcat' para el certificado del servidor SSL de JBoss, debe verificar el perfil de certificado utilizado.
Esto se debe a que el antiguo perfil de certificado ENDUSER ya no se puede utilizar para certificados de servidor SSL.
El SQL de actualización correspondiente en el script de actualización normal es:
actualizar el conjunto UserData certificateProfileId=9 donde username='tomcat' y certificateProfileId=1;
Si está utilizando un respondedor OCSP externo que utiliza la publicación de EJBCA desde EJBCA al respondedor, debe actualizar la tabla de base de datos de respondedores CertificateData utilizando los comandos SQL anteriores.
Si usa JBoss 5.x, no olvide copiar los nuevos archivos jar de BC desde EJBCA_HOME/lib/bc*.jar a JBOSS_HOME/server/default/lib, reemplazando los antiguos que copió allí desde la versión anterior de EJBCA.
EJBCA 3.7.x a EJBCA 3.8.x
Tenga en cuenta que si usa JBoss, necesita JBoss 4.2.x o posterior para ejecutar EJBCA 3.8.x.
A partir de EJBCA 3.8.0, es posible combinar administradores de diferentes CA en el mismo grupo de administradores. Esta mejora requiere un pequeño cambio en la base de datos.
Se ha eliminado la bandera "Administrador" en las entidades finales, por lo que si coincide con administradores en CN y usa esto para distinguir entre administradores y no administradores, debe cambiar a usar el número de serie del certificado u otro identificador único en su lugar.
¡Primero haz una copia de seguridad de tu base de datos! Si la actualización falla, siempre puedes volver a la versión anterior.
Si está actualizando un clúster, debe ejecutar el proceso de actualización con solo un nodo en ejecución y luego simplemente actualizar el software en los otros nodos.
1. Copie conf/*.properties de la instalación anterior en el directorio conf de la nueva versión.
O mejor aún, utilice la función ejbca-custom para realizar actualizaciones más fácilmente, consulte la Guía del usuario.
2. Fusiona los cambios de *.properties.sample en tus archivos *.properties.
3. Copie el directorio 'p12' de la instalación anterior.
4. Cierre JBoss y ejecute 'ant deploy' con la nueva versión.
5. Inicie JBoss. Podrían aparecer algunos errores durante el inicio debido a que la base de datos aún no está actualizada.
6. Ejecute el comando 'ant upgrade' desde EJBCA_HOME. Esto realizará las actualizaciones necesarias de la base de datos.
En algunos servidores de aplicaciones es posible que tengas que actualizar la base de datos manualmente, consulta a continuación.
7. Vaya a la GUI de administración y verifique su configuración.
8. Reinicie JBoss nuevamente para vaciar todos los cachés.
Se requiere Ant Upgrade para realizar los cambios en la base de datos en el módulo de autorización. Para ver qué cambios estructurales se han realizado, puede encontrar los comandos SQL correspondientes en src/upgrade/37_38/37_38-upgrade-<<nombre de la base de datos>>.sql. Tenga en cuenta que Ant Upgrade no solo ejecuta estas líneas SQL.
Debería poder actualizar de EJBCA 3.1.x directamente a 3.8.x siguiendo las mismas instrucciones anteriores (aunque esta actualización no se ha probado exhaustivamente). Consulte también las instrucciones a continuación para obtener información sobre problemas adicionales al actualizar desde una versión mucho más antigua.
Si no se incluye una opción de actualización para su base de datos, consulte src/upgrade/37_38, donde se encuentran los scripts SQL de actualización. Con gusto incluiremos scripts de actualización para otras bases de datos.
EJBCA 3.6.x a EJBCA 3.7.x
La actualización de EJBCA 3.6.x a 3.7.x es una actualización de complemento.
Si está actualizando un clúster, debe ejecutar el proceso de actualización con solo un nodo en ejecución y luego simplemente actualizar el software en los otros nodos.
1. Copie conf/*.properties de la instalación anterior en el directorio conf de la nueva versión.
O mejor aún, utilice la función ejbca-custom para realizar actualizaciones más fácilmente, consulte la Guía del usuario.
2. Copie el directorio 'p12' de la instalación anterior.
3. Cierre JBoss y realice un 'bootstrap ant' con la nueva versión.
4. Inicie JBoss.
5. Vaya a la GUI de administración y verifique su configuración.
Debería poder actualizar desde EJBCA 3.1.x directamente a 3.7.x, siguiendo las mismas instrucciones anteriores, pero respondiendo sí a la segunda pregunta (aunque esta actualización no está probada exhaustivamente).
Consulte también las instrucciones a continuación para obtener información sobre problemas adicionales al actualizar desde una versión mucho más antigua.
Si está utilizando PrimeCardHSM, debe actualizar a una nueva versión, que coincida con EJBCA 3.7.
EJBCA 3.5.x a EJBCA 3.6.x
¡Primero haz una copia de seguridad de tu base de datos! Si la actualización falla, siempre puedes volver a la versión anterior.
La actualización de EJBCA 3.5.x a EJBCA 3.6.x requiere un pequeño cambio en la base de datos.
Si está actualizando un clúster, debe ejecutar el proceso de actualización con solo un nodo en ejecución y luego simplemente actualizar el software en los otros nodos.
1. Copie conf/*.properties de la instalación anterior en el directorio conf de la nueva versión.
O mejor aún, utilice la función ejbca-custom para realizar actualizaciones más fácilmente, consulte la Guía del usuario.
2. Fusiona los cambios de *.properties.sample en tus archivos *.properties.
3. Copie el directorio 'p12' de la instalación anterior.
4. Cierre JBoss y realice un 'ant bootstrap' con la nueva versión.
5. Inicie JBoss. Podrían aparecer algunos errores durante el inicio debido a que la base de datos aún no está actualizada.
6. Ejecute el comando 'ant upgrade' desde EJBCA_HOME. Esto realizará las actualizaciones necesarias de la base de datos.
Si está actualizando desde EJBCA 3.4 o 3.5, responda "no" a la segunda y tercera pregunta.
En algunos servidores de aplicaciones es posible que tengas que actualizar la base de datos manualmente, consulta a continuación.
7. Vaya a la GUI de administración y verifique su configuración.
8. Reinicie JBoss nuevamente para vaciar todos los cachés.
Si no desea realizar el paso 6 anterior (aunque se recomienda hacerlo) y en su lugar desea realizar la actualización de la base de datos manualmente, puede simplemente emitir el siguiente comando sql:
MySQL:
alterar tabla CRLData agregar deltaCRLIndicator int(11) NOT NULL DEFAULT -1;
PostgreSQL:
alterar tabla CRLData agregar deltaCRLIndicator INT;
actualizar el conjunto CRLData deltaCRLIndicator = -1;
alterar tabla CRLData alterar columna deltaCRLIndicator establecer no nulo;
alterar tabla CRLData alterar columna deltaCRLIndicator establecer predeterminado -1;
Oráculo:
alterar tabla CRLData agregar deltaCRLIndicator NUMBER(10) predeterminado -1;
Si utiliza un servidor de aplicaciones distinto de JBoss, deberá crear manualmente las tablas en la base de datos. Cree las tablas ProtectedLogData, ProtectedLogExportData y ProtectedLogTokenData desde uno de los scripts de base de datos en doc/howto/create-tables-xxx.sql.
Debería poder actualizar desde EJBCA 3.1.x directamente a 3.6.x, siguiendo las mismas instrucciones anteriores, pero respondiendo sí a la segunda pregunta (aunque esta actualización no está probada exhaustivamente).
Consulte también las instrucciones a continuación para obtener información sobre problemas adicionales al actualizar desde una versión mucho más antigua.
Si no se incluye una opción de actualización para su base de datos, consulte src/upgrade/35_36, donde se encuentran los scripts SQL de actualización. Con gusto incluiremos scripts de actualización para otras bases de datos.
El servicio de creación de CRL de JBoss Mbean se ha eliminado en EJBCA 3.6. Se ha reemplazado por el Servicio de Actualización de CRL, mucho más sencillo y portátil, que se configura en la interfaz gráfica de usuario (GUI) del administrador. Consulte la Guía del usuario sobre la creación de CRL para obtener más información.
Si está utilizando PrimeCardHSM, debe actualizar a una nueva versión, que coincida con EJBCA 3.6.
Nota. En EJBCA 3.6, modificamos el uso de mayúsculas y minúsculas en algunas columnas de la base de datos para lograr compatibilidad total con Sybase. Esto no afectará a otras bases de datos (en ese caso, ya habría tenido problemas), pero conviene saberlo.
Los casos de las columnas cambiaron para la mayoría de las columnas en ApprovalData, para cAId en LogEntryData y para cAId en ProtectedLogData.
EJBCA 3.4.x a EJBCA 3.5.x
Consulte las Notas de la versión para obtener detalles entre determinadas versiones.
EJBCA 3.5 es una actualización de complemento de EJBCA 3.4.x. Sin embargo, aún se requieren algunos pasos para la actualización.
Simplemente copie conf/*.properties de la instalación anterior.
Fusiona los cambios (si hay alguno) de *.properties.sample en tu *.properties.
Copie el directorio 'p12' de la instalación anterior y realice 'ant deploy' con la nueva versión.
La nueva instalación sin raíz en sistemas Linux hace que sea mucho más fácil tener control de su almacén de confianza de Java (qué CA están permitidas para los certificados de administrador) tanto en Linux como en Windows.
Debes realizar estos pasos durante la actualización tanto en Linux como en Windows:
- copiar $JAVA_HOME/jre/lib/security/cacerts $EJBCA_HOME/p12/truststore.jks
- limpieza de hormigas; despliegue de hormigas
En EJBCA 3.5, cuando ejecuta el comando 'ant javatruststore' o 'ant - Dca.name =MyCAName javatruststore', ahora es el archivo $EJBCA_HOME/p12/truststore.jks el que se actualizará y se copiará a $JBOSS_HOME/server/default/conf/keystore.
También deberías leer sobre el nuevo directorio de fusión externo "ejbca-custom", donde puedes recopilar todos tus archivos. Consulta "Gestión de cambios en un árbol independiente" en la Guía del usuario.Hay algunos cambios en los nombres de los parámetros ejbca.properties y web.properties. Sin embargo, estos parámetros solo se usan al instalar EJBCA desde cero. Si planea hacerlo con archivos de configuración antiguos, debería fusionar los cambios de ejbca.properties.sample y web.properties.sample. No se preocupe si los olvida, ya que se le solicitarán los valores.
Debería poder actualizar desde EJBCA 3.1.x directamente a 3.5.x, siguiendo las mismas instrucciones para la actualización de la base de datos que para EJBCA 3.4.
EJBCA 3.3.x a EJBCA 3.4.x
¡Primero haz una copia de seguridad de tu base de datos! Si la actualización falla, siempre puedes volver a la versión anterior.
La actualización de EJBCA 3.3.x a EJBCA 3.4.x requiere un pequeño cambio en la base de datos.
Si está actualizando un clúster, debe ejecutar el proceso de actualización con solo un nodo en ejecución y luego simplemente actualizar el software en los otros nodos.
1. Copie ejbca.properties de la instalación anterior en el directorio conf de la nueva versión.
O mejor aún, divida su archivo ejbca.properties para que coincida con la nueva estructura de configuración mejorada.
2. Fusiona los cambios de *.properties.sample en tus archivos *.properties.
3. Copie el directorio 'p12' de la instalación anterior.
4. Cierre JBoss y ejecute 'ant deploy' con la nueva versión.
5. Inicie JBoss. Verá algunos errores durante el inicio debido a que la base de datos aún no está actualizada.
6. Ejecute el comando 'ant upgrade' desde EJBCA_HOME. Esto realizará las actualizaciones necesarias de la base de datos.
Si está actualizando desde EJBCA 3.2 o 3.3, responda "no" a la segunda pregunta.
En weblogic debes actualizar la base de datos manualmente, consulta a continuación.
7. Vaya a la GUI de administración y verifique su configuración, especialmente verifique la codificación DN en 'Editar autoridades de certificación' como se indica a continuación.
8. Reinicie JBoss nuevamente para vaciar todos los cachés.
Si no desea realizar el paso 6 anterior (aunque se recomienda hacerlo) y en su lugar desea realizar la actualización de la base de datos manualmente, puede simplemente emitir el siguiente comando sql:
MySQL:
modificar la tabla CAData agregar updateTime bigint NOT NULL DEFAULT 0;
PostgreSQL:
modificar la tabla CAData agregar updateTime INT8;
actualizar conjunto de datos updateTime = 0;
alterar tabla cadata alterar columna updateTime establecer no nulo;
alterar tabla cadata alterar columna updateTime establecer predeterminado 0;
Oráculo:
modificar la tabla CAData agregar updateTime NÚMERO (19) predeterminado 0;
Dado que la codificación DN predeterminada cambió a UTF8, existe una opción en la configuración de la CA (Editar autoridades de certificación) llamada "Usar codificación PrintableString en DN". Al marcar esta casilla, se utiliza el comportamiento anterior, utilizando PrintableString como codificación predeterminada. El proceso de actualización intenta determinar cómo se debe configurar este valor (al actualizar una CA antigua, normalmente se desea mantener el comportamiento anterior). Tras la actualización, revise la configuración de su CA para verificar que la opción esté configurada correctamente.
Si desea utilizar el servicio XKMS o el servicio CMS (firma de registros), después de actualizar, acceda a la interfaz gráfica de usuario (GUI) y pulse el botón "Republicar certificados de CA" para todas las CA. De lo contrario, no podrá revocar los certificados emitidos para estos servicios ni verlos en la GUI.
Debería poder actualizar de EJBCA 3.1.x directamente a 3.4.x, siguiendo las mismas instrucciones anteriores, pero respondiendo sí a la segunda pregunta.
EJBCA 3.2.x a EJBCA 3.3.x
La actualización de EJBCA 3.2.x a EJBCA 3.3.x es una actualización de complemento, porque no hay cambios en la base de datos o los cambios en la base de datos son solo tablas nuevas y no modificadas.
Aún así deberías seguir estos consejos:
¡Primero haz una copia de seguridad de tu base de datos! Si la actualización falla, siempre puedes volver a la versión anterior.
Simplemente mantenga/copie ejbca.properties de la instalación anterior.
Fusionar los cambios de ejbca.properties.sample en ejbca.properties.
Copie el directorio 'p12' de la instalación anterior y 'ant deploy' (o deploywithjbossservice) este nuevo.
Debería poder actualizar desde EJBCA 3.1.x directamente a 3.3.x, siguiendo las mismas instrucciones que cuando actualizó de 3.1.x a 3.2.x (aunque no probado).
Si está utilizando Eracom HSM, tenga en cuenta que los nombres de propiedad han cambiado para determinar qué clave se utiliza.
Después de actualizar EJBCA, debe ingresar a la configuración de CA y actualizar sus propiedades HSM.
Los nombres de propiedad ahora son los mismos para todos los diferentes HSM.
EJBCA 3.1.x a EJBCA 3.2
Esta actualización ya no es compatible con EJBCA 3.9.x. Si necesita actualizar desde aquí, utilice la última versión de EJBCA de la rama 3.8 como primer paso.