Cómo habilitar X25519MLKEM768 en Nginx y OpenSSL 3.5
Guía paso a paso para habilitar el intercambio de claves híbrido post-cuántico en tu servidor Nginx con OpenSSL 3.5 — incluyendo cómo verificarlo y errores comunes.
El paso de mayor impacto y menor riesgo en una migración post-cuántica es habilitar el intercambio de claves híbrido en tus endpoints TLS. Esta guía te muestra cómo activar X25519MLKEM768 en Nginx con OpenSSL 3.5, cómo verificar que realmente se está negociando y los dos fallos que despistan a casi todo el mundo.
Si prefieres primero el panorama general, consulta nuestra Guía de migración a la criptografía post-cuántica. Si no, vamos a la configuración.
Qué es X25519MLKEM768, en un párrafo
X25519MLKEM768 es un grupo de intercambio de claves híbrido: ejecuta X25519 clásico y ML-KEM-768 post-cuántico a la vez y combina ambos secretos compartidos. La conexión es segura mientras cualquiera de los dos algoritmos aguante, así que obtienes protección post-cuántica hoy sin apostarlo todo a un algoritmo joven. Es el grupo que Chrome, Firefox, Cloudflare y otros han desplegado en producción. Habilitarlo protege tu tráfico frente a la interceptación de tipo «recolectar ahora, descifrar después» de inmediato.
Requisito previo: OpenSSL 3.5+
Esta es la parte que bloquea a la mayoría. El soporte nativo de ML-KEM llegó en OpenSSL 3.5.0, publicado el 8 de abril de 2025 como versión de soporte a largo plazo. Si tu Nginx está enlazado contra OpenSSL 3.4 o anterior, no puedes ofrecer ML-KEM por mucho que lo pongas en la configuración.
Comprueba contra qué versión está enlazado Nginx realmente:
nginx -V 2>&1 | grep -i openssl
Ojo: importa la versión de OpenSSL con la que Nginx fue compilado, no solo la que esté instalada en el sistema. Si tienes una compilación antigua, tendrás que actualizar OpenSSL y recompilar o actualizar Nginx (o usar un paquete de tu distribución que traiga 3.5+).
La configuración de Nginx
Con OpenSSL 3.5+ en su sitio, defines la lista de preferencia de curvas/grupos en tu bloque server o http. Pon el grupo híbrido primero para que sea el preferido, con los grupos clásicos después como fallback:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;
Ese orden significa: prefiere el híbrido post-cuántico, pero haz fallback limpio a X25519 o P-256 para los clientes que aún no lo admiten. Nada se rompe para los clientes antiguos — simplemente negocian un grupo clásico como antes.
Si gestionas los ajustes de TLS mediante ssl_conf_command, el equivalente es:
ssl_conf_command Groups X25519MLKEM768:X25519:secp256r1;
Recarga Nginx para aplicarlo:
nginx -t && nginx -s reload
Verifica que realmente funciona
No te fíes de la configuración — verifica el handshake. Con un cliente OpenSSL 3.5+:
openssl s_client -connect tudominio.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated"
Si el grupo negociado vuelve como X25519MLKEM768, ya está. También puedes confirmarlo desde fuera con un escáner que entienda los grupos post-cuánticos — lanza un análisis gratis de PQScore y mira el resultado de Intercambio de claves.
Dos fallos que provocan resultados engañosos
1. Un middlebox está eliminando el grupo PQ. Algunos appliances de seguridad en línea y balanceadores que hacen inspección TLS eliminan el grupo post-cuántico del ClientHello, de modo que tu origen nunca lo ve. El síntoma: tu configuración es correcta, el origen lo admite, pero las sondas externas informan de que no hay soporte PQ. Si estás detrás de un proxy que inspecciona TLS o un WAF antiguo, comprueba si entiende X25519MLKEM768 y lo deja pasar.
2. Estás detrás de una CDN. Si una CDN termina el TLS por delante de ti, entonces lo que negocian los clientes es la configuración TLS de la CDN — no la tuya. Habilitar el grupo en tu origen no cambiará lo que ven los visitantes. La buena noticia es que la mayoría de las CDN principales ya admiten el intercambio de claves post-cuántico; la solución es habilitarlo en el panel de la CDN, no en tu origen.
Qué cubre y qué no cubre esto
Habilitar X25519MLKEM768 protege tu intercambio de claves — la mitad del problema correspondiente a «recolectar ahora, descifrar después». No hace que las firmas de tu certificado sean post-cuánticas; esa es una migración aparte a ML-DSA que depende de tu autoridad de certificación y es una vía más larga. Para la secuencia completa — inventario, intercambio de claves y luego PKI — consulta la guía de migración.
¿Quieres confirmar que tu cambio funcionó desde fuera? Analiza tu dominio gratis con PQScore →