OpenSSL 4.1 på Windows: kontrollér installerrevision 2 og DLL-signaturer

Status pr. 11. november 2026. OpenSSL udgav Windows-installationspakken 4.1.0-2 den 4. november. Den tilføjer Authenticode-signaturer til libcrypto og libssl i x86- og ARM64-pakkerne; selve OpenSSL-biblioteket er uændret. Vigtigt: Det viste versionsnummer 4.1.0 skelner ikke mellem de to installerrevisioner. Vejledningen er til administratorer og udviklere, der selv administrerer en selvstændig Windows-installation. [1][2]

Hvad revision 2 faktisk retter

Issue #30 beskriver en applikation, som fejlede på grund af usignerede DLL-filer fra den oprindelige x86-pakke. Udgivelsesnoterne nævner også ARM64. Det dokumenterer hverken et indbrud eller en ny kryptografisk rettelse. Ikke alle TLS-fejl skyldes dette problem. En advarsel om et webstedscertifikat og Windows-kodesignaturen på en lokal DLL er to forskellige kontroller. [1][2]

Forudsætninger og valg af pakke

Afklar først ansvar og afhængigheder. Hvis en applikation leverer sin egen OpenSSL-kopi, skal dens leverandørs opdateringsvej bruges i stedet for at udskifte enkelte DLL-filer. For egne installationer skal konfiguration, installationsvalg, pakkens oprindelse og tidligere PATH sikres; behold private nøgler alene i det eksisterende beskyttede backupsystem. Hav en afprøvet gendannelsesvej og et vedligeholdelsesvindue klar. x86/x64 skal også passe til applikationen, ikke blot operativsystemet. VS indeholder den tilsvarende Visual C++-runtime; hybridCRT undgår den afhængighed. ARM64 findes kun som hybridCRT. EXE og MSI er alternative pakkeformater. Koden bruger kun C:\Pilot\bin som eksempel: erstat det med den faktiske, kontrollerede installationsmappe før kørsel. [3]

Fem trin til en kontrolleret udskiftning

  1. Kortlæg uden at ændre noget. Brug Get-Command openssl -All i PowerShell på Windows til at finde kommandoopløsninger, og notér de fulde stier. Ingen resultater udelukker ikke indbyggede kopier. Sammenhold applikation, arkitektur, DLL-placeringer, tidligere installationspakke og eventuelle signaturfejl i loggen. Kopiér ikke private nøgler eller tokens til fejlrapporter.
  2. Hent den passende pakke fra den linkede udgivelse med tagget publish/4.1.0-2. Registrér tag og filnavn, og sammenlign den beregnede SHA-256 med leverandørens tilhørende kontrolfil. Ens filnavne kan høre til forskellige revisioner. Kontrollér installationsfilens digitale signatur i Windows inden kørsel. Den forventede udgiver er OpenSSL Software Services Czech, s.r.o. Stop ved ugyldig signatur eller uforklaret afvigelse; slå ikke beskyttelse fra. [1][7]
  3. Kun hvis den selvstændigt administrerede revision 4.1.0-1 faktisk er installeret: luk de berørte applikationer kontrolleret i vedligeholdelsesvinduet, afinstallér via Indstillinger → Apps → OpenSSL Library efter leverandørens anvisning, og installér derefter revision 2. Den nye pakke opgraderer ifølge udgivelsesnoterne ikke revision 1 direkte. Fjern ikke andre OpenSSL-pakker vilkårligt; afklar først afhængigheder og gendannelse. [1]
  4. Vælg komponenter og destination bevidst. Ændr ikke PATH blindt: README oplyser, at installationsprogrammet kan placere sin mappe først i systemets PATH. Brug en eksplicit programsti til piloten. Efter installation kontrolleres signaturerne på libcrypto-4.dll og libssl-4.dll i den mappe, som faktisk anvendes. PowerShell-blokken nedenfor læser kun oplysninger. Status Valid skal stemme med den forventede certifikatindehaver. [3][4]
  5. Kør version -a med den eksplicitte sti til openssl.exe, og registrér platform samt konfigurations- og modulmapper. Versionsstrengen 4.1.0 alene beviser ikke revision 2. Genstart den berørte applikation, og gentag den tidligere fejlede arbejdsgang med ufølsomme testdata. Kontrollér også, hvilken DLL-kopi applikationen faktisk indlæser: en vellykket kommandolinje er ikke en godkendt applikationstest. [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

Godkendelse og gendannelse

Godkend først ændringen, når pakkeidentitet, DLL-signaturer, forventede stier og applikationstest stemmer. Ved fejl standses udrulningen, diagnosen bevares, og den tidligere dokumenterede pakke-/konfigurationstilstand gendannes gennem den afprøvede procedure. Usignerede DLL-filer opfylder ikke et signaturkrav ved en tilbageførsel; hold om nødvendigt den berørte arbejdsgang sat på pause. Bland ikke DLL-filer manuelt, og deaktivér ikke signaturkontrollen permanent.

Vejledningens begrænsninger

Revision 2 validerer ikke automatisk en FIPS-konfiguration. Ifølge README tilbyder hybridCRT kun den aktuelle, ikke-FIPS-validerede provider; den validerede mulighed hører til den relevante VS-variant. Ved livscyklusplanlægning er 4.1 ikke LTS: den oplyste supportslutdato er 23. november 2027. Dette er en kildebaseret vejledning, ikke vores egen Windows-installations- eller kryptografitest. Ingen affiliatelinks. [3][6]