OpenSSL 4.1 su Windows: verificare la revisione 2 dell’installer e le firme delle DLL

Aggiornato al 11 novembre 2026. OpenSSL ha pubblicato l’installer Windows 4.1.0-2 il 4 novembre. Aggiunge firme Authenticode a libcrypto e libssl nei pacchetti x86 e ARM64; la libreria OpenSSL resta invariata. Attenzione: la versione visualizzata, 4.1.0, non distingue le due revisioni dell’installer. Questa guida è rivolta ad amministratori e sviluppatori che gestiscono un’installazione Windows autonoma. [1][2]

Che cosa corregge davvero la revisione 2

L’issue #30 documenta un’applicazione che non funzionava a causa di DLL non firmate nel pacchetto x86 originale. Le note di rilascio indicano anche ARM64. Questo non dimostra una compromissione né una nuova correzione crittografica. Non ogni errore TLS dipende da questa causa. Un avviso sul certificato di un sito è diverso dalla firma del codice Windows di una DLL locale. [1][2]

Prerequisiti e scelta del pacchetto

Chiarire prima responsabilità e dipendenze. Se un’applicazione include una propria copia di OpenSSL, seguire il percorso del suo produttore senza sostituire singole DLL. Per le installazioni gestite autonomamente, salvare configurazione, opzioni d’installazione, provenienza del pacchetto e PATH precedente; lasciare le chiavi private esclusivamente nel sistema di backup protetto esistente. Preparare un ripristino collaudato e una finestra di manutenzione. x86/x64 devono corrispondere anche all’applicazione, non soltanto al sistema operativo. VS include il runtime Visual C++ corrispondente; hybridCRT evita tale dipendenza. ARM64 è disponibile solo come hybridCRT. EXE e MSI sono formati alternativi. Il codice usa C:\Pilot\bin soltanto come esempio: sostituirlo con la directory d’installazione reale e verificata prima dell’esecuzione. [3]

Cinque passaggi per una sostituzione controllata

  1. Rilevare lo stato senza modifiche. In PowerShell su Windows, usare Get-Command openssl -All per individuare i comandi e annotarne i percorsi completi. L’assenza di risultati non esclude copie incorporate. Correlare applicazione, architettura, posizioni delle DLL, installer precedente ed eventuali errori di firma nei log. Non copiare chiavi private o token nei rapporti diagnostici.
  2. Scaricare il pacchetto adatto dalla pubblicazione collegata con tag publish/4.1.0-2. Registrare tag e nome del file e confrontare lo SHA-256 calcolato con il file di verifica corrispondente del produttore. Nomi identici possono appartenere a revisioni diverse. Verificare la firma digitale dell’installer in Windows prima di eseguirlo. L’editore atteso è OpenSSL Software Services Czech, s.r.o. Fermarsi se la firma non è valida o emergono differenze inspiegate; non disabilitare le protezioni. [1][7]
  3. Solo se è effettivamente installata la revisione autonoma 4.1.0-1: chiudere ordinatamente le applicazioni interessate durante la manutenzione, disinstallare tramite Impostazioni → App → OpenSSL Library come indicato dal produttore e installare la revisione 2. Avviare il nuovo pacchetto sopra la revisione 1 non esegue un aggiornamento. Non rimuovere indiscriminatamente altri pacchetti OpenSSL; verificare prima dipendenze e ripristino. [1]
  4. Scegliere consapevolmente componenti e destinazione. Non cambiare PATH alla cieca: il README indica che l’installer può anteporre la propria directory al PATH di sistema. Usare un percorso esplicito per il progetto pilota. Dopo l’installazione, controllare le firme di libcrypto-4.dll e libssl-4.dll nella directory realmente utilizzata. Il blocco PowerShell seguente legge soltanto. Lo stato Valid deve corrispondere al titolare previsto del certificato. [3][4]
  5. Eseguire version -a tramite il percorso esplicito di openssl.exe e registrare piattaforma e directory di configurazione e moduli. La sola indicazione 4.1.0 non prova la revisione 2. Riavviare l’applicazione interessata e ripetere l’operazione prima fallita con dati di prova non sensibili. Controllare anche quale copia delle DLL carica realmente: il successo del comando non convalida l’applicazione. [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

Verifica finale e ripristino

Accettare il cambiamento soltanto quando identità del pacchetto, firme delle DLL, percorsi previsti e prova applicativa concordano. In caso di errore, sospendere la distribuzione, conservare la diagnosi e recuperare lo stato precedente di pacchetto e configurazione tramite il ripristino collaudato. Tornare a DLL non firmate non soddisfa un requisito di firma; se necessario mantenere sospesa l’operazione interessata. Non mescolare DLL manualmente né disattivare permanentemente i controlli.

Limiti della guida

La revisione 2 non convalida automaticamente una configurazione FIPS. Secondo il README, hybridCRT offre solo il provider corrente, non convalidato FIPS; l’opzione convalidata appartiene alla variante VS corrispondente. Per la pianificazione, 4.1 non è LTS: il supporto dichiarato termina il 23 novembre 2027. La guida si basa sulle fonti, non su una nostra prova d’installazione Windows o crittografica. Nessun link affiliato. [3][6]