Actualización de EJBCA
Esta sección proporciona información sobre cómo actualizar desde su versión actual a una versión posterior de EJBCA y la tabla de rutas de actualización a continuación lo ayuda a determinar la ruta de actualización más eficiente.
Consulte también las Notas de actualización de EJBCA para la versión a la que planea actualizar (y cualquier versión intermedia).
Instrucciones de actualización
Al actualizar o cambiar una opción de configuración en un archivo de propiedades, no es necesario reinstalar completamente EJBCA ni reconfigurar el servidor de aplicaciones. En su lugar, implemente una nueva aplicación EJBCA (ejbca.ear) en el servidor de aplicaciones mediante el comando ant deployear .
Realice siempre una copia de seguridad de la base de datos antes de actualizar. La base de datos contiene todos los datos de la CA y, si necesita revertir una actualización, puede restaurar la copia de seguridad de la base de datos. Para obtener información sobre cómo realizar una copia de seguridad y restaurar una instalación de EJBCA, consulte Copia de seguridad y restauración .
Siga los pasos a continuación para actualizar de una versión de EJBCA a una nueva versión.
Copie conf/*.properties de la instalación anterior.
Este paso no es necesario si está utilizando un directorio ejbca-custom (consulte ejbca-custom a continuación).Fusiona los cambios (si hay alguno) de *.properties.sample en tu *.properties .
Copie el contenido del directorio p12 de la instalación anterior y ejecute el siguiente comando con la nueva versión:
$ ant deployearTenga en cuenta que el comando deployear implementa un nuevo ejbca.ear en el servidor de aplicaciones, sin realizar el mismo trabajo de configuración que el comando deploy. dominio.
Wildfly 24 y versiones posteriores admiten el tipo de almacén de claves PKCS12 (archivos .p12).
Para continuar usando el formato JKS, configure el tipo de almacén de claves JKS y el nombre de archivo en la configuración de TLS.
Para cambiar al formato PKCS12, cambie el tipo de almacén de claves para la entidad final "tomcat" (usando la UI de EJBCA RA, por ejemplo), renueve el almacén de claves y configure lo siguiente en el archivo de configuración de EJBCA web.properties: httpsserver.tokentype=P12.
Si ha cambiado el servidor de aplicaciones (una nueva versión o simplemente descomprimió una nueva instalación del mismo), debe ejecutar el siguiente comando adicional para copiar los almacenes de claves TLS al nuevo servidor:
$ ant deploy-keystoreTambién debe configurar TLS para su servidor de aplicaciones. Consulte las instrucciones de instalación específicas del servidor de aplicaciones, por ejemplo, para WildFly en servidores de aplicaciones .
Todas las actualizaciones de bases de datos requieren los privilegios CREATE y ALTER TABLE, además de los privilegios habituales SELECT, UPDATE, INSERT y DELETE. El código SQL ejecutado por las actualizaciones de bases de datos está disponible en src/upgrade/<oldversion>_<newversion>/<oldversion>_<newversion>-upgrade-<database> .sql. Por ejemplo, src/upgrade/700_710/700_710-upgrade-oracle.sql . Para MariaDB, utilice los scripts de actualización *.mysql.sql .
ejbca-personalizado
Para facilitar las actualizaciones y conservar sus configuraciones personales de una versión a otra, puede almacenar sus modificaciones de EJBCA en la carpeta ejbca-custom . Sus modificaciones sobrescribirán automáticamente cualquier archivo existente en el directorio EJBCA_HOME antes de ejecutar un comando ant . Para más información, consulte Modificación de EJBCA .
Rutas de actualización
Utilice la siguiente tabla para determinar la ruta de actualización más eficiente desde su versión actual a las versiones posteriores de EJBCA y consulte la sección Notas a continuación para obtener más detalles.
Consulte también las Notas de actualización de EJBCA para la versión a la que planea actualizar (y cualquier versión intermedia).
Tu versión | Ruta de actualización recomendada | Pasos de actualización |
4.0.15 o anterior en JDK6 o anterior | Actualice a 4.0.16 y luego actualice a 6.3.2.6 . |
|
4.0.16 a 5.0.11 en JDK6 o anterior | Actualice a 6.3.2.6 y luego actualice a la última versión de EJBCA. |
|
5.0.12 a 6.3.x | Actualice a la última versión de EJBCA. |
|
6.4.0 o posterior | Actualice a la última versión de EJBCA. |
|
Notas
Versión intermedia EJBCA 6.3.2.6
La versión intermedia EJBCA 6.3.2.6 , lanzada el 1 de diciembre de 2017, maneja los pasos de actualización intermedios al actualizar una versión anterior a 5.0.12 a una versión EJBCA posterior.
Hasta la versión 6.3.2.6 inclusive, EJBCA se puede ejecutar en JBoss 5.1, mientras que las versiones superiores de EJBCA requieren Java 8 y WildFly.
Solicitud de aprobación después de la actualización a EJBCA 6
Si utiliza aprobaciones y actualiza a EJBCA 6, tenga en cuenta que existe un problema que impide que las solicitudes de aprobación creadas en EJBCA 5.x o versiones anteriores se muestren después de la actualización. Para obtener más información, consulte ECA-8831 .
La tecnología avanza
Para superar estos avances tecnológicos es necesario no solo actualizar EJBCA, sino también el software subyacente, como el JDK y el servidor de aplicaciones.
EJBCA 6.4.0: JDK6 → JDK7 : Fin del soporte para la versión de ejecución heredada JDK6 y transición a JDK7.
EJBCA 6.4.0: JEE5 → JEE6 : Con la migración a la versión de ejecución JDK7, ya no se puede implementar en servidores de aplicaciones basados en JDK6, como las versiones 4 y 5 de JBoss. La última versión que aún puede ejecutarse en JDK6 es la versión intermedia EJBCA 6.3.2.6. Por lo tanto, EJBCA 6.3.2.6 y anteriores pueden ejecutarse en el servidor JBoss 5.1.0.GA (JEE5), mientras que las versiones posteriores requieren una actualización del JDK y del servidor de aplicaciones. Se recomiendan JDK8 y JBoss EAP 7 o WildFly 10.
EJBCA 7.0.0: JDK7 → JDK8: Fin del soporte para la versión de ejecución heredada JDK7 y migración a JDK8
EJBCA 7.0.0: JEE6 → JEE7: Con el fin del soporte para JDK7, también cesa el soporte para servidores de aplicaciones que dependen de JEE6. La versión mínima compatible de JBoss es EAP7/Wildfly 10.
Cambios en el proceso de actualización
A partir de EJBCA 4.0 , se admite el tiempo de actividad completo durante las actualizaciones para instalaciones en clúster, mediante los pasos del proceso de actualización y posteriores a la actualización :
actualizar : realiza los pasos necesarios para actualizar el primer nodo para que pueda funcionar una vez que vuelva a estar en línea.
post-actualización : realiza los pasos de actualización restantes (como la limpieza) que solo se pueden realizar una vez que todos los nodos estén ejecutando el código más reciente.
A partir de EJBCA 6.4.0 , la versión de la base de datos se rastrea internamente, lo que hace que la actualización se ejecute automáticamente desde la primera ejecución del código actualizado, lo que facilita la actualización. comando redundante.
A partir de EJBCA 6.8.0 , puede realizar actualizaciones posteriores desde la página web de administración. Cuando se requiere una actualización posterior, seleccione la opción " Actualización del sistema" del menú Configuración del sistema. está disponible.