# SSLPeerUnverifiedException en Oracle Enterprise Manager tras renovación de certificados en OLVM

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:

```plaintext
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.

1.  Verificación del certificado real en el servidor:
    
    ```plaintext
    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)
    ```
    
2.  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:
    
    ```plaintext
    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:

```plaintext
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:

```plaintext
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:

```plaintext
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:

```plaintext
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!