OpenSSL 4.1.0 ya está disponible desde el 23/10/2026 y es la primera versión de funciones de la rama 4.x tras OpenSSL 4.0: añade DTLS 1.3, GREASE y optimizaciones para ML-DSA, ML-KEM y AES-CBC, pero también retira opciones de compilación y llega con cuatro fallos conocidos en DTLS. Para los administradores, la pregunta práctica es qué rama usar en producción ahora que el calendario de soporte de OpenSSL deja varias versiones a punto de caducar.
Las claves de OpenSSL 4.1 para administradores en 30 segundos
- OpenSSL 4.1.0 se publicó el 23/10/2026 y mantiene la compatibilidad de API y ABI con la 4.0.
- Incorpora DTLS 1.3, GREASE, DTLS en la API de escucha SSL y la KDF de IKEv2.
- Acelera ML-DSA, ML-KEM y el descifrado AES-CBC en x86_64 y ppc64le, aunque sin cifras oficiales de mejora.
- Desaparecen no-ecdsa, no-ecdh y los objetivos de Windows CE e Itanium; tsget necesita Net::Curl::Easy.
- OpenSSL 3.6 deja de tener soporte el 01/11/2026; la 3.5 LTS mantiene soporte hasta abril de 2030.
La versión no es LTS. Según la política del proyecto, las versiones posteriores a la 3.5 que no son de soporte extendido reciben soporte completo durante 13 meses, mientras que la rama LTS actual, la 3.5, se mantiene hasta el 08/04/2030. En servidores, lo habitual seguirá siendo usar el paquete de la distribución, que es quien decide cuándo y cómo llega cada rama.
Qué cambia en protocolos y rendimiento
La incorporación más visible es DTLS 1.3 (RFC 9147), la versión para UDP del protocolo TLS 1.3. Afecta sobre todo a VPN, aplicaciones en tiempo real y dispositivos que usan DTLS, y el proyecto remite al manual ossl-guide-dtlsv13(7) para su configuración. La API de escucha SSL, pensada para aceptar conexiones de forma centralizada, también admite ahora DTLS.
Llega también GREASE (RFC 8701), que mete valores reservados y sin significado en el apretón de manos TLS para detectar servidores, balanceadores o cortafuegos que fallan ante extensiones desconocidas. Para un administrador, eso significa que un equipo intermedio mal implementado podría dar la cara antes. Completan la lista la KDF de IKEv2, útil en implementaciones de IPsec, y un soporte inicial para la arquitectura Elbrus 2000 (e2k).
En rendimiento, la versión optimiza las operaciones NTT de ML-DSA y ML-KEM en ppc64le, ML-DSA en x86_64, SHAKE x4 con AVX-512 y el descifrado AES-CBC con AVX-512 y VAES. Las notas no dan porcentajes de mejora, así que conviene medir con openssl speed en el hardware propio antes de sacar conclusiones. Los algoritmos poscuánticos llegaron a la biblioteca con la rama 3.5, como explicó Administración de Sistemas en OpenSSL 3.5 LTS incorpora soporte completo para QUIC y algoritmos post-cuánticos.
Lo que hay que revisar antes de compilar o actualizar
Quien compile OpenSSL a mano debe repasar sus scripts. Las opciones no-ecdsa y no-ecdh de Configure desaparecen porque, según el propio proyecto, no desactivaban de verdad esas implementaciones; la alternativa es no-ec, que elimina el soporte de curvas elípticas. También se retiran los objetivos VC-WIN64I (Windows sobre Itanium) y VC-CE (Windows CE), y se añaden VC-WIN32-MSVC2013 y VC-WIN64A-MSVC2013 para cubrir huecos de C99 en ese compilador.
Otro detalle que puede pasar desapercibido es tsget, la utilidad para pedir sellos de tiempo. Ahora usa el módulo Perl Net::Curl::Easy en lugar del abandonado WWW::Curl::Easy, así que en sistemas que dependan de ella hay que instalar el nuevo módulo antes de actualizar. Para comprobar qué versión y opciones de compilación tiene un sistema basta con:
openssl version -aEl proyecto documenta además cuatro fallos conocidos, todos en DTLS. Tras recibir un KeyUpdate en DTLS 1.3 se descartan del búfer de retransmisión otros registros pendientes, como un NewSessionTicket; el listener DTLS puede notificar un fallo permanente como SSL_ERROR_WANT_READ y un error de escritura reintentable como SSL_ERROR_SYSCALL; y un servidor DTLS 1.3 puede abortar el apretón de manos tras una pérdida de paquetes. Quien tenga previsto usar DTLS 1.3 en producción debería esperar a las correcciones o probarlo a fondo.
Un calendario de soporte con fechas cercanas
La página de estrategia de versiones de OpenSSL fija estas fechas: la 3.4 perdió el soporte el 22/10/2026, la 3.6 lo pierde el 01/11/2026, la 4.0 seguirá hasta el 14/05/2027 y la 3.5 LTS hasta el 08/04/2030. Las versiones 3.0, 1.1.1 y 1.0.2 ya solo reciben parches mediante soporte extendido de pago. La próxima versión mayor, OpenSSL 5.0, está prevista para octubre de 2027, seis meses después de la siguiente LTS. OpenSecurity ha publicado también un repaso de las novedades de esta versión: OpenSSL 4.1 añade DTLS 1.3 y GREASE y acelera la criptografía poscuántica.
Preguntas frecuentes
¿Qué versión de OpenSSL conviene usar en servidores?
Para producción, la rama 3.5 LTS ofrece el soporte más largo, hasta el 08/04/2030. OpenSSL 4.1 añade funciones nuevas, pero no es LTS.
¿Qué opciones de compilación elimina OpenSSL 4.1?
Retira no-ecdsa y no-ecdh, que se sustituyen por no-ec, y los objetivos VC-WIN64I y VC-CE para Windows sobre Itanium y Windows CE.
¿Cuándo termina el soporte de OpenSSL 3.6?
El 01/11/2026, según la página oficial de estrategia de versiones del proyecto.
¿Cómo compruebo la versión de OpenSSL instalada?
Con el comando openssl version -a, que muestra la versión y las opciones con las que se compiló.
Fuentes:
