¿Te preocupa que una advertencia de seguridad o una pasarela de pago deje de funcionar por un certificado caducado o una cabecera mal configurada? En menos de 10 segundos se detecta si el sitio está en riesgo y, después, se muestran pasos técnicos y comprobables para resolver Problemas con certificados y seguridad HTTP headers en WordPress de forma segura y profesional.
Puntos clave: lo que debes saber en 1 minuto
- Detectar certificados caducados: usar herramientas como OpenSSL, curl, WP-CLI y servicios externos (SSL Labs) para comprobar la cadena de certificados.
- Errores en navegadores: 'Tu conexión no es privada' suele ser certificado caducado, CA no confiable o cadena incompleta; la solución inmediata es reemitir o instalar intermedios correctos.
- Cabeceras HTTP críticas: implementar HSTS, CSP y X-Frame-Options reduce riesgo de MITM, XSS y clickjacking cuando se configuran correctamente en servidor o via WordPress.
- Contenido mixto y plugins: los problemas HTTPS en plugins y recursos externos se arreglan con búsqueda/replace en base de datos, filtros secure URLs y revisando llamadas externas.
- Renovación automática: Let's Encrypt + certbot o acme.sh con systemd timers/cron y hooks para recargar PHP-FPM/Nginx son la opción estándar; validar con dry-run.
Cómo detectar certificados SSL/TLS caducados en WordPress
- Comprobación rápida en navegador: abrir https://tudominio.com y revisar el candado; clic para ver fecha de expiración.
-
Comprobación desde servidor (recomendado):
-
OpenSSL (comprobar cadena y fecha):
openssl s_client -connect tudominio.com:443 -servername tudominio.com -showcerts < /dev/null | openssl x509 -noout -dates
- Qué sucede si la salida muestra notAfter en el pasado → certificado caducado.
- cURL (comprobar versión TLS/cipher):
curl -vI --tlsv1.3 https://tudominio.com
-
WP-CLI (comprobación de URLs internas):
wp option get home && wp option get siteurl
- Verificar que ambas apunten a https://; si no, puede haber redirecciones o contenido mixto.
- Verificación externa: usar SSL Labs para diagnóstico de cadena, soporte TLS 1.3, OCSP stapling y calificación general.
- Comprobación de cadena e intermediarios: errores frecuentes incluyen missing intermediate CA o certificados intermedios caducados (p. ej. problemas con cadenas cruzadas en hosts antiguos).
Diagnóstico detallado con OpenSSL y comandos
- Verificar issuer y subject:
openssl s_client -connect tudominio.com:443 -showcerts -servername tudominio.com
- Revisar cada certificado en la cadena; si falta el intermedio, el navegador puede fallar aunque el certificado del dominio no esté caducado.
- Probar OCSP Stapling:
openssl s_client -connect tudominio.com:443 -status -servername tudominio.com
- Si no devuelve OCSP response, habilitar stapling en servidor (Nginx, Apache) mejora rendimiento y validez.
Soluciones rápidas para errores de certificado en navegadores
- Error: "Tu conexión no es privada" / NET::ERR_CERT_DATE_INVALID:
- Comprobación inicial: fecha del servidor, fecha local del navegador y fecha del certificado.
- Acción inmediata: reinstalar certificado válido o restaurar certificado previo si se dispone de backup.
- Error: autoridad no fiable (SELF_SIGNED_CERT_IN_CHAIN):
- No usar certificados autofirmados en producción; obtener Let’s Encrypt o certificado de CA reconocida.
- Error: cadena incompleta:
- Instalar el archivo de cadena/intermediate proporcionado por la CA; en Apache usar SSLCertificateChainFile o concatenar files; en Nginx concatenar crt + chain en un solo .pem.
- Acción rápida desde panel de hosting: la mayoría de paneles (cPanel/Plesk) permiten reemitir o instalar intermedios sin acceso SSH; en VPS usar certbot --install-cert o copiar .pem correctamente.
Configurar cabeceras HTTP (HSTS, CSP, X-Frame) en WordPress
- Recomendación general: aplicar cabeceras desde el servidor (Nginx/Apache) para rendimiento y seguridad; si no es posible, añadir vía hook en WordPress con header() en init.
HSTS (Strict-Transport-Security)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
- Ejemplo Apache (.htaccess o config):
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
- Consideraciones: no habilitar preload hasta que se entienda el impacto; usar primero max-age corto en fase de prueba.
CSP (Content Security Policy)
- Política recomendada inicial (balance entre seguridad y compatibilidad):
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://www.google-analytics.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none';
- Implementación progresiva: usar report-only para probar antes de bloquear. Ejemplo:
add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report-endpoint";
X-Frame-Options
add_header X-Frame-Options "SAMEORIGIN" always;
- Para sitios que permiten embedding en dominiios específicos usar Content-Security-Policy frame-ancestors.
Evitar contenido mixto y problemas HTTPS en plugins
- Diagnóstico de contenido mixto:
- Usar la consola del navegador (F12 → Console) para ver recursos HTTP bloqueados.
- Ejecutar búsqueda en base de datos por 'http://' para detectar referencias internas: wp search-replace 'http://tudominio.com' 'https://tudominio.com' --skip-columns=guid
- Plugins habituales problemáticos:
- Constructores, sliders, feeds externos y plugins de analytics que cargan recursos HTTP.
- Soluciones prácticas:
- Forzar URL seguras en funciones: en functions.php añadir filtro para restablecer URLs si un plugin usa home_url inseguro.
- Usar plugin especializado para mixed content (p. ej. Really Simple SSL) solo como parche temporal; corregir origen del recurso definitiva mente.
- Reescribir recursos externos a https o usar proxies seguros (cautela con CSP).
- Checklist rápido:
- Cambiar siteurl/home a https
- Ejecutar search-replace en DB (respaldo obligatorio)
- Revisar theme y child theme para hardcoded http
- Verificar llamadas AJAX/REST y endpoints externos
Renovar y validar certificados Let's Encrypt automáticamente
- Opción estándar: certbot (ACME client). Pasos básicos:
- Instalación: seguir guía oficial Let's Encrypt.
-
Prueba de renovación automática:
sudo certbot renew --dry-run
-
Automación: systemd timer o cron job que ejecute certbot renew y recargue Nginx/Apache/PHP-FPM con --deploy-hook.
- Alternativa ligera: acme.sh (compatible con DNS challenges y proveedores cloud)
- Wildcard y DNS challenge:
- Para certificados wildcard (*.dominio.com) usar validación DNS (ACME DNS challenge) y el proveedor DNS API.
- Validación post-renovación:
- Comprobar con curl y openssl, y revisar permisos/propietario de archivos .pem para que el servidor pueda leerlos.
- Ejemplo de hook para recargar servicios tras renovación (certbot):
--deploy-hook "systemctl reload nginx"
- Consideraciones para entornos compartidos o managed hosting: algunos hosts ofrecen Let's Encrypt integrado; comprobar logs y permisos.
- Priorizar páginas sensibles: checkout, login, /wp-admin, webhooks y páginas de pasarela de pago.
- Cabeceras mínimas obligatorias:
- Strict-Transport-Security (HSTS)
- X-Frame-Options o frame-ancestors
- X-Content-Type-Options: nosniff
- Referrer-Policy: no-referrer-when-downgrade (o stricter)
- Permissions-Policy según recursos (camera, microphone)
- Cookies seguras:
- Asegurar cookie secure y HttpOnly para cookies de sesión (WooCommerce y WordPress): setcookie(..., ['secure' => true, 'httponly' => true, 'samesite' => 'Lax']);
- Pruebas automatizadas:
- Ejecutar auditoría con SSL Labs y escanear headers con securityheaders.com.
- Checklist concreto para WooCommerce:
- Checkout en HTTPS con certificado válido y cadena completa.
- Cabeceras HSTS y X-Frame configuradas a nivel servidor.
- Cookies marcadas secure/httponly y sameSite adecuadas.
- No contenido mixto en imágenes/productos/pasarelas.
- Pruebas de pasarela con entornos sandbox y validación de redirecciones HTTPS.
| Configuración |
Apache |
Nginx |
Managed hosting |
| HSTS |
Header always set Strict-Transport-Security |
add_header Strict-Transport-Security ... always; |
Panel o soporte para añadir cabeceras |
| Instalación SSL |
SSLCertificateFile + Chain |
ssl_certificate (crt + chain); ssl_certificate_key |
Let’s Encrypt integrado o soporte |
| OCSP stapling |
SSLUseStapling On |
ssl_stapling on; ssl_stapling_verify on; |
Depende del proveedor |
Flujo de resolución de problemas SSL y headers
🔍
Paso 1
Detectar con OpenSSL/SSL Labs
⚙️
Paso 2
Aplicar corrección (instalar chain, renew)
🔐
Paso 3
Habilitar HSTS, X-Frame, CSP
✅
Paso 4
Verificar con SSL Labs y pruebas de compra
Ventajas, riesgos y errores comunes
Beneficios / cuándo aplicar ✅
- Aplicar cabeceras y certificados válidos cuando se protege datos de usuarios o se opera un e‑commerce.
- Renovación automática cuando hay certificados Let’s Encrypt para evitar expiraciones humanas.
- Habilitar OCSP stapling si el servidor lo soporta para mejorar velocidad y validación.
Errores que debes evitar / riesgos ⚠️
- Habilitar HSTS preload sin pruebas amplias (riesgo de quedar forzado a HTTPS en subdominios que no estén listos).
- Usar parches temporales en plugins para contenido mixto sin arreglar origen del recurso.
- No monitorear expiraciones: registros y alertas son imprescindibles.
Preguntas frecuentes
¿Cómo saber si mi certificado caducó?
Comprobar la fecha con OpenSSL o desde el navegador; también usar SSL Labs para análisis completo.
¿Qué hago si el navegador dice CA no confiable?
Instalar un certificado emitido por una CA reconocida (Let’s Encrypt, DigiCert) y asegurarse de incluir los intermedios proporcionados.
¿Let’s Encrypt es seguro para WooCommerce?
Sí; Let’s Encrypt es compatible con tiendas online. Para wildcard o requisitos empresariales, considerar proveedores con soporte empresarial si se necesita garantía adicional.
¿Cómo evito contenido mixto causado por plugins?
Ejecutar search-replace de URLs en la base de datos, revisar llamadas externas y forzar HTTPS mediante filtros o correcciones en el plugin.
¿Debo aplicar CSP estricta en un sitio WordPress existente?
Implementar CSP en modo report-only primero y ajustar según los reports antes de pasar a modo bloqueo.
¿Cómo renuevo automáticamente certificados en un servidor sin root?
Usar ACME DNS con acme.sh y API del proveedor DNS o coordinar con el hosting para integración; en entornos sin API, considerar certificados gestionados por el proveedor.
HSTS, X-Frame-Options/frame-ancestors, X-Content-Type-Options, Referrer-Policy y cookies Secure/HttpOnly.
Siguientes pasos
- Ejecutar comprobación inmediata con OpenSSL y SSL Labs y corregir cadena si aparece error.
- Configurar renovación automática (certbot/acme.sh) y probar con --dry-run; añadir hooks para recargar servicios.
- Aplicar cabeceras HSTS + X-Frame + X-Content-Type y poner CSP en report-only para ajustar sin bloquear funciones.
