Qué importa primero: La conexión de salida HTTPS llegó a un servidor, pero la validación del certificado falló. La causa puede ser un certificado caducado, faltando el nombre de servidor intermedio, incorrecto, paquete CA obsoleto o tráfico interceptado.
Qué indica realmente este síntoma
Esto es un fallo de confianza, no un tiempo de espera de red genérico. Desactivar sslverify hace que la advertencia desaparezca eliminando la protección que impide las respuestas del hombre en el medio.
Recopila pruebas antes de cambiar nada
- Registrar el nombre del servidor de destino y el error completo del certificado.
- Inspecciona la cadena de certificados desde el servidor WordPress, no solo un navegador.
- Comprueba la fecha del servidor, el paquete CA y las versiones OpenSSL/cURL.
- Confirmar que ningún proxy o aparato de seguridad está sustituyendo a su propio certificado.
Causas más habituales
- Cadena remota incompleta: El origen no sirve al certificado intermedio necesario para llegar a una raíz de confianza.
- Certificado caducado o desfasado: El certificado está fuera de su período de validez o no cubre el nombre de servidor solicitado.
- Almacén de CA anticuado: La imagen o sistema operativo servidoring carece de un paquete de confianza actual.
- Intercepción TLS: Un proxy presenta un certificado privado en el que el servidor no confía.
Secuencia segura de diagnóstico y reparación
- Repare la cadena de certificados en el servicio remoto cuando lo controle.
- Actualice los certificados CA del sistema operativo y reinicie el servicio PHP pertinente.
- Usa el nombre de servidor correcto y elimine redireccionamientos a servidors no cubiertos por el certificado.
- Volver a probar con la verificación habilitada y documentar cualquier instalación privada de CA requerida.
Cómo distinguir entre las causas probables
No trates Cadena remota incompleta y Certificado caducado o desfasado como causas equivalentes. El origen no sirve al certificado intermedio necesario para llegar a una raíz de confianza. En cambio, el certificado está fuera de su período de validez o no cubre el nombre de servidor solicitado. Para distinguirlas, usa estas dos comprobaciones: Registrar el nombre del servidor de destino y el error completo del certificado; y inspecciona la cadena de certificados desde el servidor WordPress, no solo un navegador. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Repare la cadena de certificados en el servicio remoto cuando lo controle— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
Nunca envíe un filtro permanente que establazca sslverify a false. Expone actualizaciones, licencias, webhooks y tráfico API a manipulación.
Cómo verificar la reparación
- El servidor valida la cadena completa con el nombre de servidor previsto.
- WordPress realiza la solicitud de salida con la verificación SSL habilitada.
- No queda ningúna advertencia de certificado en Site Health o en el plugin logs.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.