El punto 1 anterior se explica por sí mismo. Para determinar si se aplica el punto 2 anterior, primero obtenga la lista de hosts de confianza en DD:
# adminaccess trust show
Para cada uno de los hosts con los que confía este, compruebe su historial de actualizaciones para ver si alguno se instaló con DDOS 5.4 (o anterior) o DDMC 1.1 (o anterior):
# historial de actualización del sistema
Es probable que los sistemas instalados con cualquiera de las versiones anteriores hayan tenido un certificado autofirmado de CA generado en la instalación con claves públicas de solo 1024 bits de longitud, que JDK ya no acepta después de la actualización a DDOS/DDMC 7.1. Una posible manera de saber si estos hosts tienen certificados con claves públicas pequeñas es abrirles la GUI y comprobar los detalles del certificado desde un navegador (la forma de hacerlo varía ligeramente según los navegadores).
Para confirmar el elemento 3 (si los registros de fallas de la GUI de DD son para este problema específico), ejecute el siguiente comando para abrir el archivo de registro "em.info":
# depuración de vista de registro/sm/em.info
Y busque (use una barra diagonal) para buscar estos registros ("..." Indica que algunos registros no se muestran a continuación por razones de brevedad):
+-----+-----+-----+ (RE)INICIO DEL SISTEMA +-----+-----+-----+
...
26 Feb 2021 10:33:04,172 INFO [principal] Estableciendo el nombre de la cookie de sesión en 'JSESSIONID-ddem___HTTPS'26
Feb 2021 10:33:04,172 INFO [principal] Estableciendo el nombre de la cookie xsrf en 'DD_SSO_TOKEN___HTTPS'26
Feb 2021 10:33:04,382 INFO [principal] Inyectando la fábrica X.509 del proveedor SUN para solucionar problemas
de validación...
26 Feb 2021 10:33:05,093 INFO [principal] Reinicialización de los certificados entre el cliente y el servidor
26 Feb 2021 10:33:05,093 INFO [principal] Volviendo a cargar los almacenes de certificados para el sistema
26 de febrero de 2021 10:33:05,097 INFO [principal] Terminó de volver a cargar los almacenes
de certificados26 de febrero de 2021 10:33:05,097 ERROR [principal] Excepción durante la ejecución del comando: javax.net.ssl.SSLException - Error al crear secreto premaestro. , volverá a intentarlo, Intento# 1
26 Feb 2021 10:33:05,243 INFO [main] Reinicialización de los certificados entre el cliente y el servidor
26 Feb 2021 10:33:05,243 INFO [main] Volviendo a cargar los almacenes de certificados para el sistema
26 Feb 2021 10:33:05,246 INFO [main] Finalizó la recarga de los almacenes de certificados
Esto indicaría que algunos de los certificados que este DD ha importado como de confianza tienen una clave corta y, por lo tanto, la GUI no se puede iniciar.
A pesar de que DDOS 7.1 o posterior continuará fallando al cargar la GUI cuando se presenten certificados con claves públicas pequeñas, el problema se resolvió en el código para las versiones DDOS 6.2.1.40 y posteriores, y DDOS 7.2.0.50 y posteriores, de modo que si al actualizar a cualquiera de estas versiones el certificado de CA local tiene una clave pública pequeña, El certificado se volverá a generar con una clave más larga.
Teniendo en cuenta que, en el momento de escribir este artículo (agosto de 2022), ya no se admiten versiones que no sean DDOS 6.2.1.x (solo para hardware DD2200 y DD250) y DDOS 7.x, no se proporciona una solución alternativa, aunque para los DD infractores, puede intentar volver a generar el certificado de host y CA con claves más largas, y luego eliminar y volver a agregar la confianza entre los dispositivos afectados:
# adminaccess trust del host dd-trusted-1 type mutual
# adminaccess certificate generate self-signed-cert regenerate-ca
# adminaccess trust add host dd-trusted-1 type mutual