Problemas con certificados y HTTP headers: guía esencial

¿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)

• Ejemplo Nginx:

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";

• Herramientas: CSP Evaluator y los reportes para ajustar.

X-Frame-Options

• Evitar clickjacking:

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.

Auditoría de headers de seguridad para tiendas WooCommerce

• 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.

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.

¿Qué headers son imprescindibles para un checkout seguro?

HSTS, X-Frame-Options/frame-ancestors, X-Content-Type-Options, Referrer-Policy y cookies Secure/HttpOnly.

Siguientes pasos

1. Ejecutar comprobación inmediata con OpenSSL y SSL Labs y corregir cadena si aparece error.
2. Configurar renovación automática (certbot/acme.sh) y probar con --dry-run; añadir hooks para recargar servicios.
3. Aplicar cabeceras HSTS + X-Frame + X-Content-Type y poner CSP en report-only para ajustar sin bloquear funciones.

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.