OpenSSL 4.1 en Windows: comprobar la revisión 2 del instalador y las firmas de las DLL

Actualizado el 11 de noviembre de 2026. OpenSSL publicó el instalador de Windows 4.1.0-2 el 4 de noviembre. Añade firmas Authenticode a libcrypto y libssl en los paquetes x86 y ARM64; la biblioteca OpenSSL no cambia. Importante: la versión mostrada, 4.1.0, no distingue las dos revisiones del instalador. Esta guía se dirige a administradores y desarrolladores que gestionan una instalación independiente en Windows. [1][2]

Qué corrige realmente la revisión 2

El issue #30 documenta una aplicación que fallaba porque las DLL del paquete x86 original no estaban firmadas. Las notas de publicación también señalan ARM64. Esto no acredita una intrusión ni una nueva corrección criptográfica. No todos los fallos TLS tienen esta causa. Una advertencia sobre el certificado de una web no equivale a la firma de código Windows de una DLL local. [1][2]

Requisitos y elección del paquete

Identifique primero responsables y dependencias. Si una aplicación incorpora su propia copia de OpenSSL, siga el procedimiento de su fabricante, sin sustituir DLL sueltas. En instalaciones bajo su gestión, respalde configuración, opciones de instalación, procedencia del paquete y PATH anterior; mantenga las claves privadas exclusivamente en el sistema de copias protegido existente. Prepare una recuperación probada y una ventana de mantenimiento. x86/x64 deben corresponder también a la aplicación, no solo al sistema operativo. VS incluye el runtime Visual C++ correspondiente; hybridCRT evita esa dependencia. ARM64 solo está disponible con hybridCRT. EXE y MSI son alternativas de empaquetado. El código utiliza C:\Pilot\bin únicamente como ejemplo: sustitúyalo por la carpeta de instalación real y verificada antes de ejecutarlo. [3]

Cinco pasos para una sustitución controlada

  1. Haga un inventario sin modificar nada. En PowerShell de Windows, Get-Command openssl -All permite localizar resoluciones del comando y anotar rutas completas. Que no haya resultados no descarta copias integradas. Relacione aplicación, arquitectura, ubicación de DLL, instalador anterior y posibles errores de firma en los registros. No copie claves privadas ni tokens en informes de diagnóstico.
  2. Descargue el paquete adecuado desde la publicación enlazada con la etiqueta publish/4.1.0-2. Registre etiqueta y nombre, y compare el SHA-256 calculado con el archivo de comprobación correspondiente del fabricante. El mismo nombre puede identificar revisiones distintas. Compruebe en Windows la firma digital del instalador antes de ejecutarlo. El editor esperado es OpenSSL Software Services Czech, s.r.o. Deténgase ante una firma inválida o una discrepancia inexplicada; no desactive protecciones. [1][7]
  3. Solo si está instalada realmente la revisión independiente 4.1.0-1: cierre de forma controlada las aplicaciones afectadas durante el mantenimiento, desinstale mediante Configuración → Aplicaciones → OpenSSL Library, siguiendo al fabricante, e instale la revisión 2. Ejecutar el nuevo paquete sobre la revisión 1 no realiza una actualización. No elimine indiscriminadamente otros paquetes OpenSSL; asegure primero dependencias y recuperación. [1]
  4. Elija componentes y destino deliberadamente. No cambie PATH sin evaluar las consecuencias: el README indica que el instalador puede anteponer su carpeta al PATH del sistema. Use una ruta explícita para la prueba piloto. Tras instalar, compruebe las firmas de libcrypto-4.dll y libssl-4.dll en la carpeta realmente utilizada. El bloque PowerShell siguiente solo lee información. Deben coincidir el estado Valid y el titular esperado del certificado. [3][4]
  5. Ejecute version -a con la ruta explícita de openssl.exe y registre plataforma y carpetas de configuración y módulos. Mostrar 4.1.0 no demuestra por sí solo la revisión 2. Reinicie la aplicación afectada y repita el flujo que fallaba con datos de prueba no sensibles. Compruebe además qué copia de DLL carga realmente: el éxito de la línea de comandos no sustituye la aceptación de la aplicación. [1][5]
$OpenSslBin = 'C:\Pilot\bin'
'openssl.exe', 'libcrypto-4.dll', 'libssl-4.dll' | ForEach-Object {
    Get-AuthenticodeSignature -LiteralPath (Join-Path $OpenSslBin $_)
} | Format-List Path, Status, StatusMessage, SignerCertificate

Comprobación final y recuperación

Dé por válido el cambio únicamente si coinciden identidad del paquete, firmas de DLL, rutas previstas y prueba de la aplicación. Ante un fallo, detenga el despliegue, conserve el diagnóstico y restaure el estado de paquete/configuración documentado mediante la recuperación probada. Volver a DLL sin firma no satisface una exigencia de firma; si es necesario, mantenga suspendida la operación afectada. No mezcle DLL manualmente ni desactive permanentemente las comprobaciones.

Límites de esta guía

La revisión 2 no valida automáticamente una configuración FIPS. Según el README, hybridCRT solo ofrece el proveedor actual, no validado FIPS; la opción validada corresponde a la variante VS adecuada. En planificación de soporte, 4.1 no es LTS: el fabricante indica el 23 de noviembre de 2027 como fecha final. Esta guía se basa en fuentes, no en pruebas propias de instalación Windows o criptografía. Sin enlaces de afiliación. [3][6]