¿No sabe por qué el sitio muestra errores SSL tras una actualización de WordPress o de un plugin? ¿Aparece "NET::ERR_CERT_AUTHORITY_INVALID", contenido mixto o errores cURL al ejecutar tareas programadas? Esta guía práctica y técnica resuelve exactamente por qué fallan los certificados SSL/HTTPS después de cambios en WordPress y cómo arreglarlo paso a paso, con comandos reproducibles, comprobaciones y soluciones para Apache y Nginx.
Puntos clave: lo que debes saber en 1 minuto
- Causa principal: tras cambios en WordPress, lo que suele fallar es la cadena de certificados o la configuración de redirecciones que impide la validación completa del certificado.
- Prueba prioritaria: ejecutar curl -Iv https://tu-dominio y openssl s_client -connect para identificar errores de cadena o certificados caducados.
- Let's Encrypt vs comercial: Let's Encrypt funciona bien si se renueva automáticamente; los comerciales requieren comprobar la cadena intermedia y SANs. Ambos deben sincronizarse con CDN/APIs.
- HSTS: activar HSTS es seguro solo cuando el sitio y todas las subrutas están 100% en HTTPS; activarlo prematuramente puede bloquear recuperaciones.
- Checklist post-cambio: renovar certificado, comprobar cadena, limpiar cache/CDN, corregir mixed content y revisar webhooks/API de terceros.
Por qué falla al actualizar certificados SSL/HTTPS tras cambios en WP: flujo de diagnóstico rápido
- Verificar errores visibles en navegador: tipo de error y código (p.ej. certificado caducado, autoridad no válida, mismatch de nombre).
- Probar conexión TLS desde servidor y desde cliente: openssl s_client -showcerts -servername dominio -connect dominio:443 + curl -Iv https://dominio.
- Revisar configuración del servidor (Nginx/Apache): certificado, clave, chain file, rutas y permisos.
- Revisar cambios en WordPress: siteurl/home, plugins de seguridad/redirección (p.ej. Really Simple SSL), CDN/Cloudflare.
- Comprobar APIs externas y webhooks que usan cURL y pueden fallar con cURL error 60.
Comandos básicos reproducibles
- Comprobar certificado desde shell:
openssl s_client -showcerts -servername ejemplo.com -connect ejemplo.com:443
- Comprobar con curl (detectar certificado y redirecciones):
curl -Iv https://ejemplo.com
- Verificar cURL PHP (desde servidor):
php -r "var_dump(curl_version());"
php -r "echo file_get_contents('https://ejemplo.com');"
- Buscar entradas siteurl/home en base de datos (WP-CLI):
wp option get siteurl
wp option get home
Me conviene renovar SSL manualmente tras actualizar WordPress?
Renovar manualmente es recomendable cuando la instalación no usa automatización o cuando hubo cambios en dominio, SANs o cadena intermedia. Si el hosting ofrece renovación automática (ACME/Let’s Encrypt renovadas por Certbot, ACME client del panel), normalmente no hace falta. Sin embargo, tras actualizar WordPress o plugins, conviene forzar comprobaciones manuales para validar la cadena y las redirecciones.
Cuándo renovar manualmente: criterios claros
- Cambio de dominio o migración (www ↔ no‑www, http ↔ https).
- Añadido/eliminado de subdominios o SANs en certificado comercial.
- Error persistente de certificate chain o untrusted root tras reiniciar servicios.
- Operaciones con CDN/APIs que requieren subir certificado manualmente (p.ej. Cloudflare en modo ‘Full (strict)’ y certificados privados).
Pasos para renovar manualmente
- Emitir/renovar certificado (Certbot / panel del proveedor / CA comercial).
- Subir certificado, clave y archivo de cadena intermedia al servidor.
- Reiniciar Nginx/Apache y comprobar con OpenSSL.
- Vaciar cache del servidor y CDN; probar desde red externa y móvil.
Let's Encrypt vs certificado comercial tras cambios en WordPress: comparativa práctica
A continuación, una tabla comparativa directa y accionable para decidir tras un cambio de WordPress.
| Característica |
Let's Encrypt |
Certificado comercial |
| Coste directo |
Gratis, renovación cada 90 días |
De moderado a alto (según tipo y SANs) |
| Cadena/intermediate |
CA pública confiable, pero algunos clientes antiguos fallan |
Suele incluir intermediates provistos; prioridad comercial para cadenas largas |
| Renovación |
Automatizable (Certbot/ACME) |
Manual o mediante proveedor; caduca 1–3 años |
| Soporte multipunto |
Soporta SANs, wildcard con DNS-01 |
Mejor para garantías, EV y cobertura multi‑dominio |
Recomendación práctica
- Si la infraestructura soporta automatización y no se necesita EV o garantías legales: Let's Encrypt es suficiente.
- Para tiendas, marketplaces o empresas con requisitos contractuales: certificado comercial puede justificar el coste, siempre que la cadena intermedia se configure correctamente tras cualquier cambio en WordPress.
¿Vale la pena activar HSTS después de actualizar HTTPS? riesgos y pasos seguros
Activar HSTS obliga a navegadores a usar HTTPS y puede mejorar seguridad. Sin embargo, si se activa inmediatamente tras un cambio y hay errores de certificado o subdominios sin HTTPS, el sitio quedará inaccesible para usuarios que ya recibieron el header.
Buenas prácticas antes de activar HSTS
- Confirmar que todas las rutas y subdominios funcionan en HTTPS.
- Comprobar APIs, webhooks y servicios externos que consumen recursos (p.ej. pasarelas de pago) funcionando con certificados válidos.
- No añadir la directiva includeSubDomains hasta verificar subdominios.
- Empezar con max-age pequeño (p.ej. 3600) y aumentar progresivamente.
add_header Strict-Transport-Security "max-age=3600; includeSubDomains; preload" always;
sólo usar preload después de haber cumplido requisitos de https://hstspreload.org/.
Errores comunes al cambiar la cadena de certificados tras actualizar plugins (y cómo resolverlos)
Actualizar plugins de seguridad o de SSL puede provocar que el servidor sirva una cadena incompleta (falta de intermediate CA) o la clave incorrecta. Esto produce errores en navegadores y en llamadas con cURL (error 60).
Síntomas frecuentes
- Navegador: "La conexión no es privada" o "NET::ERR_CERT_AUTHORITY_INVALID".
- cURL: "SSL certificate problem: unable to get local issuer certificate" o cURL error 60.
- Cron jobs o llamadas REST: fallos en Webhooks y sincronizaciones.
Cómo reparar la cadena de certificados (paso a paso)
- Obtener certificados desde la CA: certificado (cert.pem) + certificado intermedio (chain.pem).
- Crear un archivo fullchain (cert + intermediate concatenados en ese orden).
cat cert.pem chain.pem > fullchain.pem
- En Nginx usar
ssl_certificate /ruta/fullchain.pem; ssl_certificate_key /ruta/privkey.pem;.
- En Apache usar
SSLCertificateFile /ruta/cert.pem y SSLCertificateChainFile /ruta/chain.pem o SSLCertificateFile /ruta/fullchain.pem según versión.
- Reiniciar servicio y comprobar con OpenSSL.
Solución específica para cURL error 60 en entornos gestionados
- Añadir
curl.cainfo en php.ini con ruta a cacert.pem actualizada o usar CURLOPT_CAINFO en llamadas PHP.
- Si no es posible, comunicar al hosting que actualicen CA bundle del sistema.
Nginx vs Apache al renovar SSL en WordPress: diferencias prácticas y snippets listos
Aunque la lógica es la misma, diferencias en la configuración y nombres de directivas importan.
Nginx (snippet mínimo)
server {
listen 443 ssl http2;
server_name ejemplo.com www.ejemplo.com;
ssl_certificate /etc/letsencrypt/live/ejemplo.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ejemplo.com/privkey.pem;
include /etc/nginx/snippets/ssl-params.conf;
root /var/www/ejemplo.com/html;
index index.php index.html;
location /wp-admin/ { try_files $uri $uri/ /index.php?$args; }
}
Apache (snippet mínimo)
<VirtualHost *:443>
ServerName ejemplo.com
ServerAlias www.ejemplo.com
DocumentRoot /var/www/ejemplo.com/html
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/ejemplo.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/ejemplo.com/privkey.pem
<Directory /var/www/ejemplo.com/html>
AllowOverride All
</Directory>
</VirtualHost>
Problemas típicos y comprobaciones rápidas
- Nginx muestra certificado antiguo tras renovar: asegurarse de recargar
nginx -s reload y que no existan bloques ssl_certificate duplicados.
- Apache sirve certificado por defecto (mismatch): comprobar
SSLCertificateFile en VirtualHost correcto y que default-ssl no interfiera.
Checklist: renovar SSL tras cambios en WordPress
- ✅Emitir certificado (comprobar SANs y wildcard si aplica)
- ⚠Verificar cadena (usar fullchain.pem)
- 🔁Reiniciar servidor y comprobar con OpenSSL
- 🌐Vaciar CDN y cache (Cloudflare, Varnish, plugin cache)
- 🔎Probar endpoints (wp-admin, REST API, webhooks, pagos)
Costes ocultos de renovar SSL para tiendas WooCommerce
Para tiendas, además del precio del certificado, hay costes operativos y riesgos que suelen pasarse por alto:
- Tiempo de inactividad por errores de cadena o redirecciones: pérdida de ventas y desaprobación por pasarela de pago.
- Soporte para integración de certificados en pasarelas y plugins de pago que exigen
Full (strict) en Cloudflare.
- Adaptación de subdominios, certificados SAN o wildcard para entornos de staging y APIs (coste de ampliar SANs o configurar múltiples certificados).
- Coste de verificación y pruebas: horas de QA para checkout, e-mails transaccionales y notificaciones.
Estimación indicativa (2026, mercado España)
- Certificado Let's Encrypt: 0€ (coste humano de 30–120 min si la automatización falla).
- Certificado comercial (DV/OV): 30–150 €/año (dependiendo del proveedor y número de dominios).
- Integración y pruebas en WooCommerce: 2–6 horas de técnico (150–500 € según tarifa).
- Gestión de CDN y sincronización (si requiere cambio manual): 50–200 €.
Checklist operativo completo tras actualizar WordPress y certificados
- [ ] Verificar siteurl/home en WordPress (WP-CLI).
- [ ] Comprobar certificado y cadena con OpenSSL.
- [ ] Reiniciar servidor y comprobar logs (error.log / ssl_error_log).
- [ ] Ejecutar curl -Iv desde servidor y desde red externa.
- [ ] Vaciar cache de plugins y CDN; invalidar assets críticos.
- [ ] Ejecutar search-replace para URLs http:// en base de datos si es necesario.
- [ ] Comprobar webhooks, REST API y pasarelas de pago.
- [ ] Activar HSTS gradualmente solo cuando todo esté 100% en HTTPS.
Flujo de reparación rápido
Paso 1 🔎 comprobar certificado → Paso 2 🛠️ reparar cadena y reiniciar servidor → Paso 3 ♻️ vaciar cachés/CDN → ✅ Paso 4 probar desde cliente y API
Preguntas frecuentes
¿Por qué aparece cURL error 60 después de actualizar un plugin?
Suele indicar que PHP/cURL no encuentra la CA intermedia o que el servidor no sirve la cadena completa. Revisar curl.cainfo en php.ini y la configuración SSL del servidor.
Ejecutar openssl s_client -showcerts -connect dominio:443 y verificar si se listan los certificados intermedios. Usar herramientas online como SSL Labs para ver la cadena.
¿Puedo usar Let's Encrypt en WooCommerce sin problemas?
Sí, siempre que las renovaciones sean automáticas y se compruebe que pasarelas de pago funcionan en modo HTTPS estricto.
¿Qué hago si tras renovar el certificado el navegador sigue mostrando uno antiguo?
Vaciar cache del servidor y del CDN, reiniciar el proceso web (Nginx/Apache) y comprobar que no haya configuraciones duplicadas con rutas a certificados antiguos.
¿Debo usar includeSubDomains en HSTS para mi sitio WordPress?
Solo si todas las subrutas y subdominios están servidos por HTTPS válidos. Evitar includeSubDomains hasta comprobarlo.
¿Cómo arreglar redirecciones en bucle tras forzar HTTPS?
Comprobar plugins de redirección, reglas en .htaccess y configuración de siteurl/home. Desactivar temporalmente plugins que gestionen SSL para aislar el problema.
¿Qué comprobaciones hacer para APIs externas tras renovar SSL?
Probar webhooks y endpoints con curl desde servidor y desde terceros, confirmar que la CA es reconocida por clientes externos y actualizar certificados en paneles de integración si requiere.
Conclusión
Actualizar certificados SSL/HTTPS tras cambios en WordPress suele fallar por problemas con la cadena de certificados, la configuración del servidor o la sincronización con CDN/APIs. Con un flujo de diagnóstico que priorice comprobaciones desde servidor (OpenSSL, curl), revisión de configuración (Nginx/Apache) y limpieza de cache/CDN, la mayoría de incidencias se resuelven en minutos.
Pasos siguientes
- Ejecutar
openssl s_client -showcerts -connect tu-dominio:443 y copiar los errores para analizarlos.
- Revisar y, si hace falta, regenerar
fullchain.pem (cert + intermediate) y recargar Nginx/Apache.
- Comprobar webhooks/pasarelas y activar HSTS únicamente cuando todas las rutas estén 100% en HTTPS.
