PowerProtect: DP e IDPA: El análisis de seguridad detecta que el CN del sujeto del certificado de ACM X.509 no coincide con el nombre de la entidad
Resumen: Dispositivos de protección de datos PowerProtect y Integrated Data Protection Appliance (IDPA): El análisis de vulnerabilidades de seguridad detectó que el nombre común del firmante (CN) del certificado SSL de ACM no coincide con el nombre de host. ...
Síntomas
La siguiente vulnerabilidad podría detectarse en Appliance Configuration Manager (ACM) para todas las versiones de IDPA en o anteriores a 2.7.7:
| Título de la vulnerabilidad | Puntuación CVSS2 | Componente | A prueba de vulnerabilidades | Puerto | Protocolo | Recomendación |
| El CN del sujeto del certificado X.509 no coincide con el nombre de la entidad. | 7.1 | ACM | El nombre común del sujeto que se encuentra en el certificado X.509 no coincide con el destino del escaneo: El asunto CN localhost.localdom no coincide con el nombre del sistema de nombres de dominio (DNS) especificado en el sitio. El asunto CN localhost.localdom no se pudo resolver en una dirección IP mediante la búsqueda de DNS. | 8543 | TCP | Corrija el campo Nombre común (CN) del sujeto en el certificado. |
Causa
Figura 1: El certificado de ACM predeterminado muestra que el CN predeterminado es localhost.localdom.
Además, se puede encontrar la misma información en la salida de la línea de comandos:
# echo -n | openssl s_client -showcerts -connect localhost:8543 CONNECTED(00000003) depth=0 C = US, ST = California, L = Irvine, O = EMC, OU = Avamar, CN = localhost.localdom verify error:num=18:self signed certificate verify return:1 depth=0 C = US, ST = California, L = Irvine, O = EMC, OU = Avamar, CN = localhost.localdom verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Irvine/O=EMC/OU=Avamar/CN=localhost.localdom i:/C=US/ST=California/L=Irvine/O=EMC/OU=Avamar/CN=localhost.localdom --- skipped the remaining part ---
Resolución
./goidpa appliance cert-fix
A continuación, se muestra el procedimiento manual si la corrección automatizada de goidpa no funciona.
Este es el procedimiento para generar un nuevo certificado autofirmado para ACM:
1. Acceda mediante el protocolo SSH a ACM como usuario raíz
2. Cambie el directorio a /tmp:
cd /tmp
3. Descargue el script adjunto a este artículo y cárguelo en el directorio /tmp del ACM.
4. Extraiga el archivo de script del archivo .zip:
unzip KB000227601_ACM_cert_with_entity_name_as_hostname_csp_en_US_1.zip
5. Cambie el permiso del archivo de script a 755:
chmod 755 KB000227601_ACM_cert_with_entity_name_as_hostname.sh
6. Ejecute el script para reemplazar el certificado de ACM:
./KB000227601_ACM_cert_with_entity_name_as_hostname.sh
7. Inicie sesión en la interfaz de usuario web de ACM para verificar si se inicia correctamente.
A continuación, se muestra un ejemplo:
El CN del certificado de ACM se establece en "localhost.localdom" antes de ejecutar la solución alternativa:
Figura 2: En la línea de comandos, muestra que el CN predeterminado del certificado de ACM es localhost.localdom.
Un ejemplo del resumen y el resultado en esta máquina de laboratorio:
Figura 3: Ejemplo de cómo generar un nuevo certificado autofirmado mediante el script proporcionado. 
Figura 4: El CN del certificado coincide con el nombre de la máquina.
Información adicional
En caso de que después de aplicar el script para volver a generar un nuevo certificado de ACM, la interfaz del usuario de ACM no se pueda iniciar. 
Figura 5: La interfaz del usuario de ACM no se pudo iniciar después de ejecutar el script para actualizar el certificado.
En el estado de dataprotection_webapp, se encontraron los siguientes errores de entorno de JAVA_HOME:
idpa-acm:~ # systemctl status dataprotection_webapp
● dataprotection_webapp.service - SYSV: Apache Tomcat init script
Loaded: loaded (/etc/init.d/dataprotection_webapp; bad; vendor preset: disabled)
Active: active (exited) since Tue 2024-09-17 14:16:08 AEST; 1min 47s ago
Docs: man:systemd-sysv-generator(8)
Process: 23102 ExecStop=/etc/init.d/dataprotection_webapp stop (code=exited, status=0/SUCCESS)
Process: 23271 ExecStart=/etc/init.d/dataprotection_webapp start (code=exited, status=0/SUCCESS)
Sep 17 14:16:07 idpa-acm systemd[1]: Starting SYSV: Apache Tomcat init script...
Sep 17 14:16:08 idpa-acm dataprotection_webapp[23271]: Starting tomcat
Sep 17 14:16:08 idpa-acm su[23298]: (to idpauser) root on none
Sep 17 14:16:08 idpa-acm su[23298]: pam_unix(su:session): session opened for user idpauser by (uid=0)
Sep 17 14:16:08 idpa-acm dataprotection_webapp[23271]: The JAVA_HOME environment variable is not defined correctly
Sep 17 14:16:08 idpa-acm dataprotection_webapp[23271]: JAVA_HOME=/usr/lib64/jvm/jre-11-openjdk
Sep 17 14:16:08 idpa-acm dataprotection_webapp[23271]: This environment variable is needed to run this program
Sep 17 14:16:08 idpa-acm dataprotection_webapp[23271]: NB: JAVA_HOME should point to a JDK not a JRE
Sep 17 14:16:08 idpa-acm dataprotection_webapp[23271]: Tomcat is not running
Sep 17 14:16:08 idpa-acm systemd[1]: Started SYSV: Apache Tomcat init script.
idpa-acm:~ #
El problema se producía cuando el parámetro JAVA_HOME se configuraba en /etc/environment:
idpa-acm:/ # cat /etc/environment
#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on seperate lines
#
JAVA_HOME=/usr/lib64/jvm/jre-11-openjdk
idpa-acm:/ #
La resolución sería:
1. Quite el JAVA_HOME del parámetro del parámetro /etc/environment
idpa-acm:/ # cat /etc/environment # # This file is parsed by pam_env module # # Syntax: simple "KEY=VAL" pairs on seperate lines # idpa-acm:/ #
2. Reinicie el dataprotection_webapp .
idpa-acm:/ # systemctl restart dataprotection_webapp
idpa-acm:/ # systemctl status dataprotection_webapp
● dataprotection_webapp.service - SYSV: Apache Tomcat init script
Loaded: loaded (/etc/init.d/dataprotection_webapp; bad; vendor preset: disabled)
Active: active (exited) since Tue 2024-09-17 14:31:19 AEST; 7s ago
Docs: man:systemd-sysv-generator(8)
Process: 24185 ExecStop=/etc/init.d/dataprotection_webapp stop (code=exited, status=0/SUCCESS)
Process: 24194 ExecStart=/etc/init.d/dataprotection_webapp start (code=exited, status=0/SUCCESS)
Sep 17 14:31:18 idpa-acm systemd[1]: Starting SYSV: Apache Tomcat init script...
Sep 17 14:31:18 idpa-acm dataprotection_webapp[24194]: rm: cannot remove '/usr/local/dataprotection/tomcat/work/Catalina': No such file or directory
Sep 17 14:31:18 idpa-acm dataprotection_webapp[24194]: rm: cannot remove '/usr/local/dataprotection/tomcat/webapps/dataprotection': No such file or directory
Sep 17 14:31:18 idpa-acm dataprotection_webapp[24194]: Starting tomcat
Sep 17 14:31:18 idpa-acm su[24213]: (to idpauser) root on none
Sep 17 14:31:18 idpa-acm su[24213]: pam_unix(su:session): session opened for user idpauser by (uid=0)
Sep 17 14:31:18 idpa-acm dataprotection_webapp[24194]: Tomcat started.
Sep 17 14:31:19 idpa-acm dataprotection_webapp[24194]: Tomcat is running with pid: 24225
Sep 17 14:31:19 idpa-acm systemd[1]: Started SYSV: Apache Tomcat init script.
idpa-acm:/ #
A continuación, la interfaz del usuario de ACM se debe reanudar a la normalidad.
Figura 6: El servicio de interfaz del usuario de ACM vuelve a la normalidad.
Para la misma vulnerabilidad detectada en Avamar para el puerto 9443:
Se puede detectar la siguiente vulnerabilidad en Avamar en todas las versiones de IDPA en 2.7.7 o anteriores:
| Título de la vulnerabilidad | Puntuación CVSS2 | Componentes | A prueba de vulnerabilidades | Puerto | Protocolo | Recomendación |
| El CN del sujeto del certificado X.509 no coincide con el nombre de la entidad. | 7.1 | Avamar | El nombre común del sujeto que se encuentra en el certificado X.509 no coincide con el destino del escaneo: El administrador de CN en cuestión no coincide con el nombre DNS especificado en el sitio. | 9443 | TCP | Corrija el campo Nombre común (CN) del sujeto en el certificado. |
La resolución se puede encontrar en PowerProtect: Serie DP e IDPA: Vulnerabilidad "X.509 Certificate Subject CN Does Not Match the Entity Name" para Avamar Server Port 9443.
Para la misma vulnerabilidad detectada en el proxy de Avamar para los puertos 443 y 5480:
Se podía detectar la siguiente vulnerabilidad en el proxy de Avamar para todas las versiones de IDPA en o anteriores a 2.7.6:
| Título de la vulnerabilidad | Puntuación CVSS2 | Componentes | A prueba de vulnerabilidades | Puerto | Protocolo | Recomendación |
| El CN del sujeto del certificado X.509 no coincide con el nombre de la entidad. | 7.1 | Avamar Proxy | El nombre común del sujeto que se encuentra en el certificado X.509 no coincide con el destino del escaneo: El administrador de CN en cuestión no coincide con el nombre DNS especificado en el sitio. | 5480 / 443 | TCP | Corrija el campo Nombre común (CN) del sujeto en el certificado. |
El problema se resolvió en Avamar Proxy versión 19.10. Actualice a IDPA versión 2.7.7 e incluya Avamar versión 19.10.
La solución alternativa para IDPA 2.7.6 o una versión anterior se puede encontrar en la Guía del usuario de Dell Avamar para VMware 19.9. El procedimiento se encuentra en la sección "Import custom certificate in Avamar VMware Image Backup Proxy". También está Avamar: Cómo reemplazar el certificado de Avamar VMware Image Backup Proxy(requiere autenticación en el portal de soporte de Dell).