SSLPeerUnverifiedException en Oracle Enterprise Manager tras renovación de certificados en OLVM
Mi nombre es Carla y me defino como una apasionada de conocer, compartir ideas, divertirme y aprender todo lo relacionado con Oracle.
Alegre y creativa, con un alto grado de autoexigencia, que busca, incluso sin querer, una forma diferente de ver un mismo problema o solución. Defensora del trabajo en equipo en todas las facetas de la vida y de disfrutar todo lo que haces, siempre con humildad.
Actualmente cuento con más de 15 años de experiencia como administradora de Oracle, habiendo ocupado previamente posiciones como desarrolladora en la rama de Inteligencia de Negocios. Fue en ese momento que me di cuenta de que no quería centrarme en el desarrollo, sino participar en todas las capas que involucraban los datos, desde el despliegue de la base de datos hasta su explotación final.
Siempre estoy dispuesta a ayudar y compartir conocimientos. Creo firmemente que con la tecnología hay que divertirse y no verla como una competencia. La persona con la que tienes que ser el mejor es contigo mismo.
En infraestructuras donde monitorizamos entornos de Oracle Linux Virtualization Manager (OLVM) mediante Oracle Enterprise Manager (OEM) Cloud Control, la seguridad es un pilar fundamental. Recientemente, tras una renovación de certificados PKI en el motor de OLVM, nos encontramos con un problema común pero crítico: el estado del target pasó a METRIC ERROR.
Aquí detallo el proceso de diagnóstico y la solución aplicada.
El Síntoma
En la consola de Cloud Control, el target de OLVM mostraba errores en la recolección de métricas. Al revisar el log del agente (gcagent_sdk.trc), identificamos la causa raíz:
ERROR - Failed to send request
WARN - Error creating OLV Manager connection [Failed to send request]
org.ovirt.engine.sdk4.Error: Failed to send request
...
Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Este error indica que el Agente de Oracle no confía en el certificado que el Manager de OLVM le está presentando durante el apretón de manos (handshake) TLS.
Diagnóstico: El choque de "Fingerprints"
Para entender qué estaba pasando, comparamos el certificado que el servidor servía por el puerto 443 frente a lo que el Agente tenía almacenado en su keystore interno.
Verificación del certificado real en el servidor:
echo | openssl s_client -connect olvm-mgr.dominio.local:443 2>/dev/null | openssl x509 -noout -fingerprint -sha1 # Resultado: SHA1 Fingerprint=FB:38:FD:80... (Certificado nuevo de 2026)Verificación de la confianza en el Agente de Oracle. Consultamos el almacén AgentTrust.jks del agente buscando el alias configurado para la monitorización de OLVM:
keytool -list -keystore AgentTrust.jks -alias olvm_target_alias # Resultado: Fingerprint (SHA1): 5C:D2:37:5C... (Certificado antiguo de 2025)
Conclusión: El Agente intentaba validar la conexión usando una huella digital de abril de 2025, pero el servidor renovó sus certificados en marzo de 2026.
La confianza se había roto.
La Solución: Actualización de la cadena de confianza
Para solucionar esto, no basta con descargar el certificado; hay que integrarlo correctamente en el flujo de trabajo de Enterprise Manager.
Paso 1: Exportar el nuevo certificado
Extrajimos el certificado público actual del servidor OLVM:
openssl s_client -connect olvm-mgr.dominio.local:443 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > olvm_new_2026.pem
Paso 2: Importar al Keystore del Agente
En lugar de usar keytool directamente, utilizamos la utilidad emctl del agente, que asegura que la integración sea compatible con los estándares de OEM:
emctl secure add_trust_cert_to_jks -trust_certs_loc /path/to/olvm_new_2026.pem -alias olvm-mgr.dominio.local
Paso 3: Limpieza de estado y reinicio
Para forzar al agente a descartar cualquier caché de métricas erróneas y cargar el nuevo almacén de llaves, ejecutamos:
emctl stop agent
emctl clearstate agent # Limpia el estado acumulado
emctl start agent
Verificación Final
Tras el reinicio, monitorizamos de nuevo el log gcagent_sdk.trc. El cambio de estado fue inmediato:
INFO - Connected to OLV Manager.
INFO - Number of event filtered in = 0
El mensaje "Connected to OLV Manager" confirmó que el handshake SSL se realizó correctamente con el nuevo certificado.
Espero que este artículo sea útil para quienes se peleen con certificados y monitorización de Oracle. ¡Hasta la próxima!
