OpenSSL 4.1 sous Windows : vérifier la révision 2 de l’installateur et les signatures des DLL

État au 11 novembre 2026. OpenSSL a publié l’installateur Windows 4.1.0-2 le 4 novembre. Il ajoute des signatures Authenticode à libcrypto et libssl dans les paquets x86 et ARM64 ; la bibliothèque OpenSSL reste inchangée. Attention : la version affichée, 4.1.0, ne distingue pas les deux révisions de l’installateur. Ce guide concerne les administrateurs et développeurs gérant une installation Windows autonome. [1][2]

Ce que corrige réellement la révision 2

Le ticket #30 décrit une application en échec à cause de DLL non signées dans le paquet x86 initial. Les notes de publication mentionnent également ARM64. Cela ne démontre ni compromission ni nouvelle correction cryptographique. Toutes les pannes TLS n’ont pas cette origine. Un avertissement relatif au certificat d’un site et la signature de code Windows d’une DLL locale sont deux contrôles distincts. [1][2]

Prérequis et choix du paquet

Identifiez d’abord le responsable et les dépendances. Lorsqu’une application embarque sa propre copie d’OpenSSL, suivez la procédure de son éditeur au lieu de remplacer des DLL isolées. Pour vos installations autonomes, sauvegardez configuration, options d’installation, provenance du paquet et ancienne valeur de PATH ; conservez les clés privées uniquement dans le dispositif de sauvegarde protégé existant. Prévoyez une restauration éprouvée et une fenêtre de maintenance. Le choix x86/x64 dépend aussi de l’application cible, pas seulement du système. VS inclut le runtime Visual C++ correspondant ; hybridCRT évite cette dépendance. ARM64 existe uniquement en hybridCRT. EXE et MSI sont des conditionnements alternatifs. Le code utilise C:\Pilot\bin comme simple exemple : remplacez ce chemin par le répertoire réel et vérifié avant exécution. [3]

Cinq étapes pour un remplacement maîtrisé

  1. Inventoriez sans rien modifier. Dans PowerShell sous Windows, utilisez Get-Command openssl -All pour trouver les résolutions de commande et relever les chemins complets. L’absence de résultat n’exclut pas des copies embarquées. Rapprochez application, architecture, emplacements des DLL, ancien installateur et éventuelles erreurs de signature dans les journaux. Ne copiez ni clés privées ni jetons dans un rapport.
  2. Téléchargez le paquet adapté depuis la publication liée, portant l’étiquette publish/4.1.0-2. Notez étiquette et nom de fichier, puis comparez le SHA-256 calculé au fichier de contrôle correspondant de l’éditeur. Un même nom peut désigner plusieurs révisions. Vérifiez la signature numérique de l’installateur dans Windows avant de l’exécuter. L’éditeur attendu est OpenSSL Software Services Czech, s.r.o. Arrêtez en cas de signature invalide ou d’écart inexpliqué ; ne désactivez pas les protections. [1][7]
  3. Uniquement si la révision autonome 4.1.0-1 est effectivement installée : fermez proprement les applications concernées pendant la maintenance, désinstallez via Paramètres → Applications → OpenSSL Library selon l’éditeur, puis installez la révision 2. Exécuter le nouveau paquet sur la révision 1 ne constitue pas une mise à niveau. Ne supprimez pas indistinctement d’autres paquets OpenSSL ; sécurisez d’abord dépendances et restauration. [1]
  4. Choisissez les composants et le répertoire en connaissance de cause. Ne modifiez pas PATH aveuglément : le README indique que l’installateur peut placer son dossier en tête du PATH système. Utilisez un chemin explicite pour le pilote. Après installation, contrôlez les signatures de libcrypto-4.dll et libssl-4.dll dans le dossier réellement utilisé. Le bloc PowerShell ci-dessous ne fait que lire. Le statut Valid et le titulaire attendu du certificat doivent concorder. [3][4]
  5. Exécutez version -a via le chemin explicite d’openssl.exe et consignez plateforme et répertoires de configuration et de modules. La seule mention 4.1.0 ne prouve pas la révision 2. Redémarrez l’application concernée et reproduisez l’opération auparavant défaillante avec des données de test non sensibles. Vérifiez aussi quelle DLL elle charge réellement : une commande réussie ne valide pas l’application. [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

Validation et restauration

Validez seulement si identité du paquet, signatures des DLL, chemins attendus et test applicatif concordent. En cas d’échec, suspendez le déploiement, conservez le diagnostic et restaurez l’état du paquet et de la configuration documenté auparavant par la procédure éprouvée. Revenir à des DLL non signées ne satisfait pas une exigence de signature ; laissez l’opération concernée suspendue si nécessaire. Ne mélangez pas les DLL manuellement et ne désactivez pas durablement les contrôles.

Limites de ces recommandations

La révision 2 ne valide pas automatiquement une configuration FIPS. D’après le README, hybridCRT propose uniquement le fournisseur actuel, non validé FIPS ; l’option validée appartient à la variante VS correspondante. Pour le cycle de vie, 4.1 n’est pas LTS : la fin de support annoncée est le 23 novembre 2027. Ce guide repose sur des sources, pas sur un essai d’installation Windows ou de cryptographie réalisé par nos soins. Aucun lien affilié. [3][6]