OpenSSL 4.1 w Windows: sprawdź rewizję 2 instalatora i podpisy bibliotek DLL

Stan na 11 listopada 2026 r. OpenSSL opublikował instalator Windows 4.1.0-2 dnia 4 listopada. Dodaje on podpisy Authenticode do libcrypto i libssl w pakietach x86 oraz ARM64; sama biblioteka OpenSSL pozostaje bez zmian. Ważne: wyświetlana wersja 4.1.0 nie odróżnia obu rewizji instalatora. Poradnik jest przeznaczony dla administratorów i programistów zarządzających samodzielną instalacją w Windows. [1][2]

Co naprawdę poprawia rewizja 2

Zgłoszenie #30 opisuje awarię aplikacji spowodowaną niepodpisanymi bibliotekami DLL z pierwotnego pakietu x86. Informacje o wydaniu wymieniają także ARM64. Nie jest to dowód włamania ani nowa poprawka kryptograficzna. Nie każdy problem TLS ma tę przyczynę. Ostrzeżenie o certyfikacie witryny i podpis kodu Windows lokalnej biblioteki DLL to różne mechanizmy kontroli. [1][2]

Wymagania i wybór pakietu

Najpierw ustal odpowiedzialność i zależności. Jeżeli aplikacja zawiera własną kopię OpenSSL, skorzystaj z aktualizacji jej producenta zamiast wymieniać pojedyncze DLL. Dla samodzielnych instalacji zachowaj konfigurację, opcje instalacji, pochodzenie pakietu i dotychczasowy PATH; klucze prywatne pozostaw wyłącznie w istniejącym chronionym systemie kopii zapasowych. Przygotuj sprawdzoną procedurę odtwarzania i okno serwisowe. x86/x64 musi pasować również do aplikacji, nie tylko systemu operacyjnego. VS zawiera odpowiednie środowisko Visual C++; hybridCRT nie ma tej zależności. ARM64 jest dostępny tylko jako hybridCRT. EXE i MSI to alternatywne formaty pakietu. Kod używa C:\Pilot\bin wyłącznie jako przykładu: przed uruchomieniem wpisz rzeczywisty, zweryfikowany katalog instalacji. [3]

Pięć kroków kontrolowanej wymiany

  1. Zrób inwentaryzację bez zmian. W PowerShell w Windows użyj Get-Command openssl -All, aby znaleźć rozpoznawane polecenia, i zapisz pełne ścieżki. Brak wyników nie wyklucza kopii dołączonych do aplikacji. Powiąż aplikację, architekturę, lokalizacje DLL, poprzedni instalator i ewentualne błędy podpisu w dziennikach. Nie kopiuj kluczy prywatnych ani tokenów do raportów.
  2. Pobierz odpowiedni pakiet z podlinkowanego wydania oznaczonego publish/4.1.0-2. Zapisz tag i nazwę pliku oraz porównaj obliczony SHA-256 z odpowiednim plikiem kontrolnym producenta. Identyczne nazwy mogą dotyczyć różnych rewizji. Przed uruchomieniem sprawdź podpis cyfrowy instalatora w Windows. Oczekiwany wydawca to OpenSSL Software Services Czech, s.r.o. Przy nieważnym podpisie lub niewyjaśnionej rozbieżności przerwij; nie wyłączaj zabezpieczeń. [1][7]
  3. Tylko jeśli rzeczywiście zainstalowano samodzielnie zarządzaną rewizję 4.1.0-1: w oknie serwisowym zamknij zależne aplikacje, odinstaluj pakiet przez Ustawienia → Aplikacje → OpenSSL Library zgodnie z instrukcją producenta, a następnie zainstaluj rewizję 2. Uruchomienie nowego pakietu na rewizji 1 nie wykonuje aktualizacji. Nie usuwaj bez rozpoznania innych pakietów OpenSSL; najpierw zabezpiecz zależności i odtwarzanie. [1]
  4. Świadomie wybierz składniki i katalog. Nie zmieniaj PATH bez oceny skutków: README informuje, że instalator może dodać swój katalog na początku systemowego PATH. W pilotażu używaj pełnej ścieżki. Po instalacji sprawdź podpisy libcrypto-4.dll i libssl-4.dll w faktycznie używanym katalogu. Poniższy blok PowerShell tylko odczytuje informacje. Status Valid musi odpowiadać oczekiwanemu właścicielowi certyfikatu. [3][4]
  5. Uruchom version -a przez pełną ścieżkę do openssl.exe i zanotuj platformę oraz katalogi konfiguracji i modułów. Sam napis 4.1.0 nie potwierdza rewizji 2. Uruchom ponownie aplikację i powtórz wcześniej niedziałającą czynność na niewrażliwych danych testowych. Sprawdź także faktycznie ładowaną kopię DLL: poprawny wynik polecenia nie oznacza jeszcze poprawnego działania aplikacji. [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

Weryfikacja i odtwarzanie

Zaakceptuj zmianę dopiero po zgodnym sprawdzeniu tożsamości pakietu, podpisów DLL, oczekiwanych ścieżek i działania aplikacji. W razie błędu wstrzymaj wdrożenie, zachowaj dane diagnostyczne i odtwórz udokumentowany stan pakietu oraz konfiguracji sprawdzoną procedurą. Powrót do niepodpisanych DLL nie spełnia wymagania podpisu; w razie potrzeby pozostaw daną operację wstrzymaną. Nie mieszaj DLL ręcznie i nie wyłączaj na stałe weryfikacji.

Ograniczenia poradnika

Rewizja 2 nie zapewnia automatycznie walidacji konfiguracji FIPS. Według README hybridCRT oferuje tylko bieżący provider bez walidacji FIPS; opcja zwalidowana należy do odpowiedniego wariantu VS. W planowaniu utrzymania uwzględnij, że 4.1 nie jest LTS: deklarowany koniec wsparcia to 23 listopada 2027 r. To poradnik oparty na źródłach, a nie przeprowadzony przez nas test instalacji Windows lub kryptografii. Bez linków afiliacyjnych. [3][6]