OpenSSL 4.1 unter Windows: Installer-Revision 2 und DLL-Signaturen prüfen
Stand: 11. November 2026. OpenSSL hat am 4. November den Windows-Installer 4.1.0-2 veröffentlicht. Er ergänzt Authenticode-Signaturen für libcrypto und libssl in den x86- und ARM64-Paketen; die OpenSSL-Bibliothek selbst bleibt unverändert. Wichtig: Die angezeigte Version 4.1.0 unterscheidet die beiden Installerrevisionen nicht. Diese Anleitung richtet sich an Administratoren und Entwickler mit einer eigenständig verwalteten Windows-Installation. [1][2]
Was Revision 2 tatsächlich korrigiert
Issue #30 dokumentiert, dass eine Anwendung wegen unsignierter DLLs aus dem ursprünglichen x86-Paket scheiterte. Die Releasebeschreibung nennt zusätzlich ARM64. Daraus folgt weder eine bestätigte Kompromittierung noch ein neuer Kryptografie-Patch. Nicht jede TLS-Störung hat diese Ursache. Eine im Browser sichtbare Zertifikatswarnung ist etwas anderes als die Windows-Codesignatur einer lokalen DLL. [1][2]
Voraussetzungen und Variantenwahl
Zuerst Zuständigkeit und Abhängigkeiten klären: Bringt eine Fachanwendung ihre eigene OpenSSL-Kopie mit, gilt deren Herstellerweg, nicht der Austausch einzelner DLLs. Für eigene Installationen Konfiguration, Installationsoptionen, Paketquelle und bisherige PATH-Einstellung sichern; private Schlüssel nur im bestehenden geschützten Sicherungssystem belassen. Einen erprobten Wiederherstellungsweg und ein Wartungsfenster vorsehen. x86/x64 beziehen sich auch auf die Zielanwendung, nicht allein auf das Betriebssystem. VS enthält die passende Visual-C++-Laufzeit; hybridCRT vermeidet diese Abhängigkeit. ARM64 gibt es nur als hybridCRT. EXE und MSI sind Verpackungsalternativen. Das Codebeispiel verwendet C:\Pilot\bin ausschließlich als Beispiel: vor Ausführung den tatsächlichen geprüften Installationsordner einsetzen. [3]
Fünf Schritte für einen kontrollierten Wechsel
- Bestand nur lesend aufnehmen. Unter Windows in PowerShell mit
Get-Command openssl -Allnach vorhandenen Befehlsauflösungen suchen und den vollständigen Pfad notieren. Ein fehlender Treffer beweist nicht, dass keine eingebettete Kopie existiert. Anwendung, Architektur, DLL-Pfade, bisheriges Paket und gegebenenfalls Signaturfehler aus deren Protokoll zusammenführen; keine privaten Schlüssel oder Tokens in Fehlerberichte kopieren. - Das zur Anwendung passende Paket von der verlinkten Release-Seite mit Tag
publish/4.1.0-2beziehen. Tag, Dateiname und SHA-256 aus der zugehörigen Herstellerdatei dokumentieren und vergleichen; gleiche Dateinamen können verschiedene Revisionen enthalten. Vor Ausführung die digitale Signatur des Installers über Windows prüfen. Erwarteter Herausgeber: OpenSSL Software Services Czech, s.r.o. Bei ungültiger Signatur oder unerklärlicher Abweichung stoppen, nicht Schutzfunktionen deaktivieren. [1][7] - Nur wenn die eigenständig verwaltete Revision 4.1.0-1 tatsächlich installiert ist: betroffene Anwendungen im Wartungsfenster kontrolliert beenden, nach Herstelleranweisung unter Einstellungen → Apps → OpenSSL Library deinstallieren und danach Revision 2 installieren. Ein Start des neuen Pakets über Revision 1 ist laut Hersteller kein Upgrade. Nicht pauschal andere OpenSSL-Pakete entfernen; zuerst Abhängigkeiten und Rückweg absichern. [1]
- Komponenten und Installationspfad bewusst wählen. PATH nicht unbesehen ändern: Laut README kann der Installer seinen Ordner systemweit voranstellen. Für den Pilotaufruf den vollständigen Programmpfad verwenden. Nach Installation die Signaturen von
libcrypto-4.dllundlibssl-4.dllim tatsächlich genutzten Ordner prüfen; der folgende PowerShell-Block liest nur.Validund der erwartete Zertifikatsinhaber müssen zusammenpassen. [3][4] - Mit dem expliziten
openssl.exe-Pfadversion -aausführen und Plattform sowie Konfigurations-/Modulpfade dokumentieren. Die Ausgabe 4.1.0 allein ist kein Nachweis für Revision 2. Anschließend die betroffene Anwendung neu starten und genau den vorher fehlgeschlagenen Arbeitsablauf mit unkritischen Testdaten prüfen. Auch deren tatsächlich geladene DLL-Kopie abgleichen; ein erfolgreicher CLI-Aufruf beweist noch keinen Anwendungserfolg. [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, SignerCertificateErfolgskontrolle und Rückweg
Bestanden ist der Wechsel erst, wenn Paketidentität, DLL-Signaturen, erwartete Pfade und Anwendungstest zusammen stimmen. Bei Fehlern den Rollout stoppen, Diagnose sichern und den vorher dokumentierten Paket-/Konfigurationszustand über den geprüften Wiederherstellungsweg zurückholen. Eine Rückkehr zu unsignierten DLLs erfüllt eine Signaturpflicht nicht; den betroffenen Ablauf gegebenenfalls ausgesetzt lassen. Kein manuelles DLL-Mischen und keine dauerhafte Abschaltung der Signaturprüfung.
Grenzen der Aussage
Revision 2 validiert nicht automatisch eine FIPS-Konfiguration. Laut README bietet hybridCRT nur den aktuellen, nicht FIPS-validierten Provider; die validierte Option gehört zur passenden VS-Variante. Für langfristige Planung ist 4.1 kein LTS-Zweig; der Hersteller nennt den 23. November 2027 als Supportende. Dies ist eine quellenbasierte Anleitung, kein eigener Windows-Installations- oder Kryptografietest. Keine Affiliate-Links. [3][6]
