Cloudflare ya admite autenticación poscuántica hacia el origen: cuándo merece la pena revisarla
Cloudflare ya permite usar ML-DSA en Authenticated Origin Pulls y Custom Origin Trust Store para reforzar la autenticación poscuántica entre el edge y el origen.
Cloudflare confirmó el 17 de junio de 2026 el soporte de certificados ML-DSA para Authenticated Origin Pulls y Custom Origin Trust Store, y el 24 de julio dejó la guía técnica bastante más aterrizada en su documentación. La lectura útil no es “Cloudflare ya habla postcuántico” a secas, sino otra más concreta: ya es posible endurecer también la autenticación entre el edge y tu servidor origen con firmas poscuánticas, no solo el intercambio de claves.
Esto importa porque muchas conversaciones sobre criptografía poscuántica se quedan en el navegador, el cliente VPN o el túnel. Aquí el foco está en otra parte de la cadena: la conexión TLS entre Cloudflare y el origen. Si usas Cloudflare delante de un servicio sensible y te preocupa el largo plazo de certificados, middleboxes o cumplimiento, esta novedad sí merece una revisión seria.
Resumen rápido: qué anunció Cloudflare
- 17 de junio de 2026: Cloudflare anunció soporte para ML-DSA en Authenticated Origin Pulls y Custom Origin Trust Store.
- 24 de julio de 2026: publicó una guía más completa sobre post-quantum between Cloudflare and origin servers.
- La conexión Cloudflare-origen ya puede combinar intercambio de claves híbrido X25519MLKEM768 con autenticación por certificados ML-DSA.
- Authenticated Origin Pulls permite que Cloudflare presente un certificado cliente ML-DSA al origen durante el mTLS.
- Custom Origin Trust Store permite que Cloudflare valide el certificado del origen contra una CA ML-DSA propia.
- Usadas juntas, ambas piezas permiten autenticación poscuántica extremo a extremo entre edge y origen.
Qué problema resuelve exactamente
Hasta ahora era fácil simplificar el mensaje y decir que “Cloudflare ya soporta post-cuántica”, pero eso dejaba fuera una diferencia importante. Una cosa es el intercambio de claves y otra la autenticación del canal. Si el edge y el origen negocian un key agreement híbrido, pero luego siguen autenticándose con certificados clásicos, el salto no está completo.
Lo nuevo aquí es precisamente esa segunda capa. Según la documentación oficial de Cloudflare, la parte de firmas poscuánticas entra por ML-DSA y puede aplicarse tanto al certificado cliente que Cloudflare presenta al origen como a la CA privada que Cloudflare usa para confiar en el certificado del servidor origen.
Qué piezas entran en juego
Authenticated Origin Pulls con ML-DSA
Authenticated Origin Pulls ya servía para algo muy útil: hacer que tu origen solo atienda conexiones que realmente vengan de Cloudflare. Con el soporte nuevo, esa verificación puede apoyarse en un certificado cliente ML-DSA que Cloudflare presenta en el handshake mTLS.
La guía oficial aclara además un matiz importante: esto aplica a AOP a nivel de zona y por hostname. El modo global usa un certificado proporcionado por Cloudflare y no es configurable de la misma forma.
Custom Origin Trust Store con ML-DSA
La otra mitad es Custom Origin Trust Store. Aquí el movimiento consiste en subir una CA ML-DSA privada para que Cloudflare valide contra ella el certificado del servidor origen cuando trabajas en Full (strict). Esto evita depender de una CA pública tradicional para ese tramo concreto.
La contrapartida también está bien documentada: al cargar una CA en Custom Origin Trust Store, Cloudflare deja de confiar en las CAs públicas por defecto para esa zona. No es una casilla inocente; exige saber exactamente qué certificados presenta tu origen y cómo vas a gestionarlos.
Qué necesitas antes de tocarlo
La parte menos vistosa, pero más importante, está en los requisitos. Cloudflare pide OpenSSL 3.5.0 o superior tanto para generar certificados como, en la práctica, para tener soporte usable de ML-DSA. También hace falta que tu origen negocie TLS 1.3 y que la librería TLS del servidor soporte esta familia de firmas.
Hay otro detalle técnico fácil de pasar por alto y que conviene dejar claro: las claves privadas ML-DSA deben subirse en formato seed-only. Cloudflare indica de forma explícita que el formato expanded-key se rechaza en los endpoints de subida. Si montas las pruebas deprisa y esto falla, no parece un detalle menor: es justo uno de los puntos que más pueden hacer perder tiempo.
Qué conviene revisar antes de activarlo
- Si tu origen realmente usa TLS 1.3 de forma limpia. Si todavía dependes de compatibilidades viejas o middleboxes delicados, conviene validar primero esa base.
- Qué librería TLS tienes delante. Nginx, balanceadores, proxies o appliances intermedios pueden limitar más que el propio servidor.
- Si te compensa AOP, COTS o ambas. No todo el mundo necesita las dos piezas a la vez.
- Cómo vas a gestionar la CA privada. Si no tienes claro el ciclo de vida de esa CA, la mejora criptográfica puede convertirse en deuda operativa.
- Qué certificados clásicos quieres retirar de verdad. La guía de Cloudflare insiste en evitar mezclas que permitan downgrade práctico.
La advertencia más importante: no es un check mágico
Cloudflare deja bastante claro en su documentación que subir material ML-DSA no basta si luego mantienes caminos clásicos aceptados en paralelo. Por ejemplo, si en Custom Origin Trust Store dejas también CAs clásicas o si el origen sigue aceptando certificados cliente no poscuánticos, la conexión puede seguir expuesta a downgrade criptográfico.
Traducido a lenguaje operativo: la novedad sirve cuando endureces de verdad la política, no cuando solo añades una opción más al inventario. Esta es probablemente la idea más útil para cualquier equipo que vaya a probarlo.
Cuándo tiene sentido en una infraestructura real
Esta novedad encaja mejor en escenarios donde el origen ya es una pieza crítica y bien controlada, no en cualquier web pequeña puesta detrás de Cloudflare sin más. Tiene más sentido si trabajas con:
- servicios internos o B2B sensibles donde el tramo edge-origen forma parte del modelo de amenaza;
- entornos regulados que quieren empezar a ensayar políticas criptográficas a largo plazo;
- infraestructura propia donde puedes tocar servidor, CA, balanceadores y validación de extremo a extremo;
- equipos que ya usan AOP o Full (strict) y quieren endurecer el siguiente escalón sin rehacer toda la arquitectura.
Si vienes siguiendo en su-ip.es nuestras piezas sobre Cloudflare DMARC Management, los controles de bots de IA en Cloudflare o el EDE 33 en 1.1.1.1, esta noticia cae en la misma familia: mejoras que no suenan tan vistosas como una feature comercial, pero sí afectan a la seguridad operativa real.
Qué hacer si quieres probarlo sin romper nada
- Empieza en un hostname o zona controlada, no en todo el perímetro productivo.
- Genera una CA y un leaf ML-DSA con OpenSSL 3.5.0 o superior, respetando el formato seed-only que exige Cloudflare.
- Activa AOP o COTS por separado primero para entender mejor cada pieza y el punto exacto donde falla algo.
- Valida el handshake TLS 1.3 y comprueba qué certificados acepta todavía tu origen.
- Retira las rutas clásicas sobrantes si tu objetivo es evitar downgrade real y no solo “tener soporte” en la ficha técnica.
FAQ breve
Esto sustituye al post-quantum key agreement que Cloudflare ya tenía?
No. Lo complementa. El key agreement híbrido resuelve una parte del problema y las firmas ML-DSA añaden la capa de autenticación mediante certificados.
Hace falta usar AOP y COTS a la vez?
No necesariamente. Pueden usarse por separado, pero juntas permiten una autenticación poscuántica más completa entre Cloudflare y el origen.
Vale para cualquier origen detrás de Cloudflare?
No. Hace falta que tu software TLS soporte ML-DSA y TLS 1.3, y que puedas gestionar la CA y los certificados de forma controlada.
Hay riesgo de ruptura operativa si se configura mal?
Sí. Sobre todo con Custom Origin Trust Store, porque sustituye la confianza en CAs públicas por las que tú subas para esa zona.
Fuentes oficiales
- Cloudflare Changelog: Post-quantum ML-DSA certificates for Authenticated Origin Pulls and Custom Origin Trust Store
- Cloudflare Docs: Post-quantum between Cloudflare and origin servers
- Cloudflare Docs: Authenticated Origin Pulls
- Cloudflare Blog: referencia pública del despliegue y difusión de la novedad
Conclusión práctica
La novedad no obliga a correr a activarla hoy en cualquier despliegue, pero sí cambia algo importante: la conversación sobre post-cuántica en Cloudflare ya no se limita al intercambio de claves o al cliente final. Ahora también alcanza la autenticación del tramo edge-origen, que es justo donde muchas infraestructuras serias necesitan garantías más largas.
Si tu entorno ya usa Cloudflare con AOP, Full (strict) o una política de CA privada bien gobernada, merece la pena revisar esta función con calma y pruebas reales. No por postureo criptográfico, sino porque empieza a tocar una capa que sí tiene impacto operativo y de seguridad de verdad.