OpenSSL 4.1 på Windows: kontroller installasjonsrevisjon 2 og DLL-signaturer

Status per 11. november 2026. OpenSSL publiserte Windows-installasjonspakken 4.1.0-2 den 4. november. Den legger til Authenticode-signaturer på libcrypto og libssl i x86- og ARM64-pakkene; selve OpenSSL-biblioteket er uendret. Viktig: Den viste versjonen 4.1.0 skiller ikke mellom de to installasjonsrevisjonene. Veiledningen er for administratorer og utviklere som forvalter en frittstående Windows-installasjon. [1][2]

Hva revisjon 2 faktisk retter

Sak #30 beskriver en applikasjon som feilet på grunn av usignerte DLL-filer fra den opprinnelige x86-pakken. Utgivelsesnotatene nevner også ARM64. Dette dokumenterer verken et innbrudd eller en ny kryptografisk rettelse. Ikke alle TLS-feil har denne årsaken. Et varsel om sertifikatet til et nettsted er noe annet enn Windows-kodesignaturen på en lokal DLL. [1][2]

Forutsetninger og valg av pakke

Avklar først ansvar og avhengigheter. Hvis en applikasjon leveres med sin egen OpenSSL-kopi, må du følge leverandørens oppdateringsløp fremfor å bytte enkeltstående DLL-filer. For egne installasjoner sikres konfigurasjon, installasjonsvalg, pakkens opprinnelse og tidligere PATH; behold private nøkler kun i det eksisterende beskyttede sikkerhetskopisystemet. Ha en utprøvd gjenopprettingsmåte og et vedlikeholdsvindu klart. x86/x64 må også passe til applikasjonen, ikke bare operativsystemet. VS inkluderer tilhørende Visual C++-kjøretidsmiljø; hybridCRT unngår denne avhengigheten. ARM64 finnes bare som hybridCRT. EXE og MSI er alternative pakkeformater. Koden bruker C:\Pilot\bin bare som eksempel: erstatt den med den faktiske, kontrollerte installasjonsmappen før kjøring. [3]

Fem trinn for en kontrollert utskifting

  1. Kartlegg uten å endre noe. I PowerShell på Windows bruker du Get-Command openssl -All for å finne kommandooppløsninger og notere fullstendige baner. Ingen treff utelukker ikke innebygde kopier. Se applikasjon, arkitektur, DLL-plasseringer, tidligere installasjonspakke og eventuelle signaturfeil i loggene i sammenheng. Ikke kopier private nøkler eller tokener til feilrapporter.
  2. Hent riktig pakke fra den lenkede utgivelsen med taggen publish/4.1.0-2. Registrer tagg og filnavn, og sammenlign beregnet SHA-256 med leverandørens tilhørende kontrollfil. Like filnavn kan tilhøre ulike revisjoner. Kontroller den digitale signaturen til installasjonsfilen i Windows før kjøring. Forventet utgiver er OpenSSL Software Services Czech, s.r.o. Stopp ved ugyldig signatur eller uforklarlig avvik; ikke slå av beskyttelsen. [1][7]
  3. Bare hvis den selvstendig forvaltede revisjonen 4.1.0-1 faktisk er installert: avslutt berørte applikasjoner kontrollert i vedlikeholdsvinduet, avinstaller via Innstillinger → Apper → OpenSSL Library i tråd med leverandørens anvisning, og installer deretter revisjon 2. Den nye pakken oppgraderer ifølge utgivelsesnotatene ikke revisjon 1 direkte. Ikke fjern andre OpenSSL-pakker vilkårlig; avklar først avhengigheter og gjenoppretting. [1]
  4. Velg komponenter og målmappe bevisst. Ikke endre PATH uten å vurdere virkningen: README sier at installasjonsprogrammet kan legge sin mappe først i systemets PATH. Bruk en eksplisitt programbane i piloten. Etter installasjon kontrolleres signaturene på libcrypto-4.dll og libssl-4.dll i mappen som faktisk brukes. PowerShell-blokken nedenfor leser bare informasjon. Status Valid må samsvare med forventet sertifikatinnehaver. [3][4]
  5. Kjør version -a med den eksplisitte banen til openssl.exe, og registrer plattform samt konfigurasjons- og modulmapper. Versjonsstrengen 4.1.0 alene beviser ikke revisjon 2. Start den berørte applikasjonen på nytt og gjenta arbeidsflyten som feilet med ufølsomme testdata. Kontroller også hvilken DLL-kopi den faktisk laster: vellykket kommandolinjekjøring er ikke en godkjent applikasjonstest. [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

Godkjenning og gjenoppretting

Godkjenn først endringen når pakkeidentitet, DLL-signaturer, forventede baner og applikasjonstest stemmer overens. Ved feil stopper du utrullingen, tar vare på diagnostikken og gjenoppretter tidligere dokumentert pakke- og konfigurasjonstilstand via den utprøvde prosedyren. Å gå tilbake til usignerte DLL-filer oppfyller ikke et signaturkrav; la om nødvendig den berørte arbeidsflyten være stanset. Ikke bland DLL-filer manuelt eller deaktiver signaturkontroll permanent.

Begrensninger i veiledningen

Revisjon 2 validerer ikke automatisk en FIPS-konfigurasjon. Ifølge README tilbyr hybridCRT bare den gjeldende, ikke-FIPS-validerte provideren; det validerte alternativet hører til riktig VS-variant. For livssyklusplanlegging er 4.1 ikke LTS: oppgitt sluttdato for støtte er 23. november 2027. Dette er kildebasert veiledning, ikke en Windows-installasjons- eller kryptografitest vi har utført selv. Ingen affiliatelenker. [3][6]