Un certificado caducado y una cadena incompleta pueden parecer el mismo fallo en el navegador, pero se reparan de forma distinta. Identifica primero qué endpoint TLS recibe al visitante —CDN, balanceador u origen— y revisa la cadena que presenta antes de tocar URLs o redirects de WordPress.
Identifica el endpoint del certificado
Resuelve el hostname e inspecciona emisor, SAN, caducidad y cadena completa en el endpoint público. No asumas que el certificado del origen es el que ve el navegador.
Distingue caducidad de cadena incompleta
Un leaf caducado necesita renovación; un intermediate ausente necesita bundle/orden correcto. Reemitir no arregla un servidor que sirve el fichero de cadena equivocado.
Revisa por separado CDN y origen
Con reverse proxy, TLS del edge y TLS del origen son dos contratos. Confirma el modo elegido y si el certificado de origen es válido para él.
Renueva sin cambiar URLs de la aplicación
Renovar el certificado normalmente no exige cambiar home/site URL de WordPress. Mezclar ambas cosas es una vía frecuente a bucles.
Audita redirects cuando TLS funcione
Cuando HTTPS ya termine bien, deja HTTP→HTTPS en una capa autoritativa. Proxy, servidor y WordPress apilados pueden hacer loop.
Verifica la ruta completa
Prueba apex/www, páginas, admin y API. Confirma que ningún hostname sirve un certificado viejo y monitoriza la próxima caducidad.
Antes de cambiar DNS durante un incidente de certificado, usa la checklist de migración DNS; si HTTPS llega a un upstream roto, sigue con el diagnóstico 502.