HTTPS con Cloudflare: certificado de origen y Full (strict)
Para proteger con HTTPS el tráfico entre el visitante, Cloudflare y tu servidor, configura un certificado válido en el origen y utiliza Full (strict) cuando tu instalación lo permita. El certificado que ve el navegador y el del servidor de origen cumplen funciones distintas. No elimines certificados existentes antes de comprobar cómo se presta el servicio.
Comprueba el dominio y el alcance del cambio
Antes de incorporar o modificar el dominio en Cloudflare, conserva un inventario de sus registros DNS y de los servicios que dependen de ellos. Comprueba quién administra el dominio, el hosting y los certificados. Cambiar nameservers o activar el proxy no debe hacerse sin conservar correo, subdominios y otros servicios.
Las capturas ilustran un panel anterior. Verifica los nombres y valores en tu proveedor actual antes de confirmar cambios. Si ya tienes Cloudflare funcionando, no necesitas volver a registrar el dominio ni sustituir toda su configuración para revisar HTTPS.
Distingue los dos tramos de conexión
El navegador establece una conexión con Cloudflare; Cloudflare se conecta después a tu origen. Full (strict) exige HTTPS y valida el certificado presentado por ese origen, incluido su nombre y su vigencia. Un candado en el navegador no demuestra por sí solo que el segundo tramo esté correctamente configurado.
No utilices Flexible como equivalente a cifrado hasta el servidor. Si tienes errores, identifica el certificado, puerto, hostname y reglas implicados en lugar de reducir la protección para ocultar el síntoma.
Prepara un certificado válido en el origen
Puedes usar un certificado de una autoridad pública compatible o, para el escenario documentado de tráfico a través del proxy, un certificado de Cloudflare Origin CA. Confirma que cubre los nombres necesarios y que el servidor presenta la cadena y la configuración adecuadas.
Origin CA no es un sustituto general de un certificado público para navegadores que acceden directamente al servidor. Si desactivas el proxy o cambias el flujo de tráfico, revisa antes la confianza y validez del certificado que recibirán esos clientes.
Cuando generes o instales un certificado, protege la clave privada. No la publiques, no la incluyas en capturas y no la compartas con quien no necesita administrarla. Si no tienes acceso o conocimientos para instalarla de forma segura, coordina el cambio con tu proveedor de hosting.
Activa Full (strict) y comprueba la web
- Confirma que el origen acepta HTTPS y presenta un certificado que coincide con el hostname.
- Selecciona Full (strict) en la configuración SSL/TLS correspondiente a tu aplicación o zona.
- Comprueba páginas públicas y las funciones esenciales del sitio.
- Revisa las redirecciones HTTP/HTTPS y los recursos mixtos sin crear reglas duplicadas.
Si aparece un error de certificado o un bucle, revisa primero la configuración del origen y las reglas de redirección. No borres claves ni cambies a un modo menos seguro como una solución permanente. Conserva una forma de volver a la configuración que tenías antes del cambio.
Seguridad y caché son revisiones distintas
Activar HTTPS no autoriza a almacenar páginas privadas o sesiones en caché. En WordPress, comprueba especialmente administración, cuentas y contenido personalizado. Para ampliar el diagnóstico, consulta Cloudflare y WordPress, la instalación de SSL en WordPress y las medidas de protección del sitio.
Deja un comentario