OpenSSL-Signierung mit dem PKCS#11-Wrapper von EC

Veröffentlicht: April 2025 | Aktualisiert: August 2026

Die OpenSSL-Signierung mit PKCS#11 ist ein Verfahren, bei dem die OpenSSL-Befehlszeilenschnittstelle für kryptografische Signaturvorgänge genutzt wird, während der eigentliche private Schlüssel in einem Hardware-Sicherheitsmodul oder -Token verbleibt und niemals auf der Festplatte gespeichert wird. Ein PKCS#11-Wrapper stellt die Verbindung zwischen OpenSSL und der Hardware her, sodass die bekannten OpenSSL-Befehle die eigentliche Signierung an zertifizierte, manipulationssichere Hardware auslagern.

Einführung

Wenn es um die Sicherung digitaler Kommunikation oder die Überprüfung der Datenintegrität geht, ist OpenSSL eines der wichtigsten Werkzeuge für Entwickler und Sicherheitsexperten. Ob Sie Dateien signieren, Zertifikate erstellen oder digitale Signaturen überprüfen – OpenSSL bietet eine flexible und leistungsstarke Kommandozeilenschnittstelle für kryptografische Operationen.

Allerdings gibt es einen Haken: OpenSSL arbeitet standardmäßig mit softwarebasierten Schlüsseln, die auf der Festplatte gespeichert sind. Das mag für die Entwicklung oder interne Tests zwar in Ordnung sein, ist aber für Produktionsumgebungen, in denen die Sicherheit privater Schlüssel entscheidend ist, nicht ideal. Hier kommt PKCS#11 ins Spiel.

PKCS#11 ist eine Standard-API, die es Software ermöglicht, mit kryptografischen Token wie Smartcards, USB-Token und HSMs (Hardware-Sicherheitsmodulen) zu interagieren . Diese Token dienen der sicheren Speicherung von Schlüsseln und der Durchführung von Operationen wie Signieren oder Verschlüsseln direkt im Gerät – Ihr privater Schlüssel verlässt also niemals die Hardware.

Die Integration von OpenSSL in ein PKCS#11-kompatibles Gerät ist nicht immer Plug-and-Play. Deshalb verwenden wir einen PKCS#11-Wrapper, der als Brücke zwischen OpenSSL und dem hardwaregestützten Kryptografieanbieter fungiert. Der Wrapper ermöglicht die Ausführung vertrauter OpenSSL-Befehle und verlagert die eigentlichen Signaturvorgänge auf das HSM oder Token.

In diesem Blogbeitrag zeige ich Ihnen Schritt für Schritt, wie Sie OpenSSL-basierte Signaturen mit dem PKCS#11-Wrapper von CodeSign Secure und Encryption Consulting unter Ubuntu und Windows erstellen. Ich behandle Einrichtung, Konfiguration und Ausführung. Egal, ob Sie in Unternehmensumgebungen arbeiten oder einen sicheren Signaturprozess für Ihre Anwendung entwickeln möchten – diese Anleitung hilft Ihnen, Ihre kryptografischen Sicherheitsvorkehrungen ohne großen Lernaufwand zu verbessern.

Ubuntu vs. Windows-Installation: Ein kurzer Vergleich

Bevor wir uns mit den plattformspezifischen Schritten befassen, hier ein kurzer Überblick über die Unterschiede zwischen den beiden Setups.

Schritt	Ubuntu	Windows
Wrapper-Quelle	CodeSign Secure v3.02 Abschnitt „Signaturwerkzeuge“	CodeSign Secure v3.02 Abschnitt „Signaturwerkzeuge“
OpenSSL installieren	sudo apt install -y openssl libengine-pkcs11-openssl gnutls-bin xxd	Laden Sie das Win32 OpenSSL-Installationsprogramm von slproweb.com herunter.
PKCS#11 Motor	Wird mit dem Distributionspaket geliefert (libpkcs11.so(Der Pfad variiert je nach Ubuntu-Version)	Muss manuell aus OpenSCs libp11 über MSYS2 kompiliert werden.
Konfigurationsdatei	openssl.conf, Pfad festgelegt über die OPENSSL_CONF variable Umgebung	openssl.cnf in C:\Program Files\Common Files\SSL
Befehl unterschreiben	openssl pkeyutl -engine pkcs11 -sign ...	openssl dgst -engine pkcs11 -keyform engine -sign ...

OpenSSL PKCS11 – Ubuntu

Installation auf dem Client-System

Schritt 1: Gehen Sie zum Abschnitt „ Signing Tools“ von EC CodeSign Secure v3.02 und laden Sie den PKCS11 Wrapper für Ubuntu herunter.

Schritt 2: Generieren Sie anschließend ein P12-Authentifizierungszertifikat über das Dropdown-Menü System Setup > Benutzer > Authentifizierungszertifikat generieren.

Schritt 3: Gehen Sie zu Ihrem Ubuntu-Clientsystem und bearbeiten Sie die im PKCS11 Wrapper heruntergeladenen Konfigurationsdateien ( ec_pkcs11client.ini und pkcs11properties.cfg ).

Voraussetzungen für das Ubuntu-System

Installieren wir nun einige Voraussetzungen in Ihrem Clientsystem, um den PKCS11-Wrapper auszuführen.

Schritt 1: OpenSSL installieren: sudo apt install -y openssl libengine-pkcs11-openssl gnutls-bin xxd

Schritt 2: Erstellen Sie eine Konfigurationsdatei für PKCS#11

Schritt 3: Geben Sie die entsprechenden Details in die Konfigurationsdatei ein:

openssl_conf = openssl_init
[openssl_init]
Motoren = Motorabschnitt
[Engine-Abschnitt]
pkcs11 = pkcs11_Abschnitt
[pkcs11_Abschnitt]

#Pfad zur OpenSSL PKCS11 Engine
dynamischer_Pfad = „ „
MODULE_PATH = “ „

Der Pfad zur Datei ec_pkcs11client.so hängt davon ab, wo Sie die Datei speichern.

Der Pfad zu libpkcs11.so hängt von Ihrer Linux-Distribution und -Version ab:

• Ubuntu 18.04: /usr/lib/x86_64-linux-gnu/engines-1.1/libpkcs11.so
• Ubuntu 20.04: /usr/lib/x86_64-linux-gnu/engines-1.1/libpkcs11.so
• Ubuntu 22.04: /usr/lib/x86_64-linux-gnu/engines-3/libpkcs11.so

Schritt 4: Umgebungsvariable für die openssl.conf-Datei festlegen

export OPENSSL_CONF=

Führen Sie die Signierung und Überprüfung mit dem PKCS11-Wrapper durch

Nachdem nun alle Konfigurationen und Voraussetzungen installiert wurden, führen wir zunächst den Signiervorgang durch.

Der Signierbefehl sieht in etwa so aus (stellen Sie sicher, dass Sie diesen Befehl nur in dem Ordner ausführen, in dem Ihr PKCS11 Wrapper installiert ist):

openssl pkeyutl -engine pkcs11 -sign -in -inkey „pkcs11:object= ;Typ=privat” -keyform engine -out

Beispiel: openssl pkeyutl -engine pkcs11 -sign -in testfile.txt -inkey “pkcs11:object=CertEnrollTest;type=private” -keyform engine -out readme.sign.sha256

Nachdem wir die Datei erfolgreich signiert haben, überprüfen wir sie mit diesem Befehl:

openssl pkeyutl -engine pkcs11 -verify -in -inkey „pkcs11:object= ;Typ=privat” -keyform engine -sigfile

Beispiel: openssl pkeyutl -engine pkcs11 -verify -in testfile.txt -inkey “pkcs11:object=CertEnrollTest;type=private” -keyform engine -sigfile readme.sign.sha256

OpenSSL PKCS11 – Windows

Installation auf dem Client-System

Schritt 1: Gehen Sie zum Abschnitt „ Signierungstools“ von EC CodeSign Secure v3.02 und laden Sie den PKCS11 Wrapper für Windows herunter.

Schritt 2: Generieren Sie anschließend ein P12-Authentifizierungszertifikat über das Dropdown-Menü System Setup > Benutzer > Authentifizierungszertifikat generieren.

Schritt 3: Gehen Sie zu Ihrem Windows-Clientsystem und bearbeiten Sie die im PKCS11 Wrapper heruntergeladenen Konfigurationsdateien ( ec_pkcs11client.ini und pkcs11properties.cfg ).

Voraussetzungen für das Windows-System

Installieren wir nun einige Voraussetzungen in Ihrem Clientsystem, um den PKCS11-Wrapper auszuführen.

Schritt 1: Laden Sie OpenSSL von hier herunter und installieren Sie es auf Ihrem System.

Schritt 2: OpenSSL PKCS#11 manuell mit diesen Methoden kompilieren

• Laden Sie msys2-i686-*.exe herunter und installieren Sie es von https://msys2.github.io/
• Starten Sie eine MSYS2 MSYS-Konsole von der Start menü

Verwenden Sie diesen Befehl:

pacman -S git pkg-config libtool autoconf automake make gcc openssl-devel git clone https://github.com/OpenSC/libp11.git cd libp11 autoreconf -fi ./configure –prefix=/usr/local make && make install

Schritt 3: In der Konfigurationsdatei ( openssl.cnf ) im Ordner C:\Program Files\Common Files\SSL

Fügen Sie diese Zeilen hinzu:
openssl_conf = openssl_init
[openssl_init]
Motoren = Motorabschnitt
[Engine-Abschnitt]
pkcs11 = pkcs11_Abschnitt
[pkcs11_Abschnitt]

#Pfad zum kompilierten OpenSSL PKCS11 von OpenSC – libp11
dynamischer_Pfad = MODULE_PATH =

Führen Sie die Signierung und Überprüfung mit dem PKCS11-Wrapper durch

Nachdem nun alle Konfigurationen und Voraussetzungen installiert wurden, führen wir zunächst den Signiervorgang durch.

Der Signierbefehl sieht in etwa so aus (stellen Sie sicher, dass Sie diesen Befehl nur in dem Ordner ausführen, in dem Ihr PKCS11 Wrapper installiert ist):

openssl dgst -engine pkcs11 -keyform engine -sign „pkcs11:object= ;Typ=öffentlich” -sha256 -out

Zum Beispiel:

openssl dgst -engine pkcs11 -keyform engine -sign “pkcs11:object=CertEnrollTest;type=public” -sha256 -out test-signed.bin testfile.txt

Nachdem wir die Datei erfolgreich signiert haben, überprüfen wir sie mit diesem Befehl:

openssl dgst -engine pkcs11 -keyform engine -verify „pkcs11:object= ;Typ=öffentlich” -sha256 -Signatur

Beispielsweise:

openssl dgst -engine pkcs11 -keyform engine -verify „pkcs11:object=CertEnrollTest;type=public“ -sha256 -signature test-signed.bin testfile.txt

Sicherheitsüberlegungen

Bei kryptografischen Vorgängen – insbesondere bei der digitalen Signatur – ist der Schutz Ihrer privaten Schlüssel absolut unerlässlich. Ein durchgesickerter oder kompromittierter privater Schlüssel ist praktisch der Worst-Case-Fall, da er Identitätsdiebstahl, unbefugten Zugriff und zahlreiche Vertrauensprobleme nach sich zieht.

Lassen Sie uns also über einige bewährte Methoden sprechen, mit denen Sie Ihre Schlüssel (und Ihren Ruf) schützen können:

• Speichern Sie private Schlüssel niemals in einfachen DateienEs mag zwar praktisch sein, private Schlüssel als einfache Dateien auf der Festplatte zu speichern (selbst mit Dateisystemberechtigungen), birgt aber Risiken. Ein falsch konfiguriertes Backup-System oder ein neugieriger Administrator reichen aus, um sie versehentlich offenzulegen. Dies ist kein theoretisches Risiko. Laut dem GitGuardian-Bericht „State of Secrets Sprawl 2026“ wurden allein im Jahr 2025 28.65 Millionen neue, fest codierte Geheimnisse auf öffentlichen GitHub-Konten offengelegt – ein Anstieg von 34 % gegenüber dem Vorjahr.Laut dem Verizon-Bericht „Data Breach Investigations Report 2025“ beträgt die durchschnittliche Zeit, die ein Team benötigt, um einen Datenverlust zu beheben, 94 Tage – eine Sicherheitslücke, die Angreifer ausnutzen können, lange bevor es jemand bemerkt. Verwenden Sie stattdessen sichere Schlüsselspeichermechanismen – vorzugsweise hardwarebasiert.
• Verwenden Sie nach Möglichkeit HSMs oder sichere Token: Hardware-Sicherheitsmodule (HSMs) und Smartcards sind speziell für die sichere Schlüsselspeicherung konzipiert. Sie speichern nicht nur Schlüssel, sondern führen auch Vorgänge (wie Signieren oder Entschlüsseln) innerhalb des Geräts aus, sodass der private Schlüssel das Gerät nie verlässt. Dies bietet eine starke Schutzebene, insbesondere gegen Malware oder Insider-Bedrohungen.
• Sperren Sie den Zugriff auf Ihre PKCS#11-Module: Stellen Sie sicher, dass nur autorisierte Benutzer oder Dienste mit der PKCS#11-Schnittstelle kommunizieren können. Verwenden Sie PINs, rollenbasierten Zugriff und ordnungsgemäße Audits, um Missbrauch zu verhindern. Wenn Ihr Wrapper- oder HSM-Anbieter Protokollierung unterstützt, aktivieren Sie diese – Sie möchten eine klare Übersicht darüber, wer wann auf was zugegriffen hat.
• Vermeiden Sie es, Token unverschlossen zu lassen: Es ist verlockend, Skripte zu erstellen und Token entsperrt zu lassen, um den Betrieb aufrechtzuerhalten. Das ist jedoch riskant. Prüfen Sie stattdessen automatisierte Entsperrmechanismen, die die Sitzungsisolierung berücksichtigen, oder Tools, die Anmeldeinformationen für kurze Zeit sicher zwischenspeichern und strenge Zugriffskontrollen bieten.
• Überprüfen Sie, was Sie unterschreiben: Es klingt offensichtlich, aber stellen Sie sicher, dass Sie nicht versehentlich zufällige oder schädliche Dateien signieren. Integrieren Sie Plausibilitätsprüfungen oder verwenden Sie vor der Signierung Überprüfungsschritte, um sicherzustellen, dass nur genehmigte Inhalte Ihren Signaturprozess durchlaufen.

Letztendlich sind kryptografische Tools nur so sicher wie ihre Verwendung. PKCS#11 ermöglicht es Ihnen, kritische Vorgänge auf die Hardware auszulagern – Sie müssen jedoch die Grundlagen beachten: Schützen Sie Ihre Schlüssel, beschränken Sie den Zugriff und seien Sie einem Angreifer immer einen Schritt voraus.

Häufig gestellte Fragen

Was ist PKCS#11 und warum benötigt OpenSSL einen Wrapper dafür?

PKCS#11 ist eine Standard-API für die Kommunikation mit kryptografischen Token wie HSMs und Smartcards. OpenSSL unterstützt PKCS#11 für hardwarebasierte Schlüssel standardmäßig nicht nativ. Daher fungiert ein Wrapper als Brücke, der es vertrauten OpenSSL-Befehlen ermöglicht, die eigentliche Signieroperation an die Hardware auszulagern.

Verlässt der private Schlüssel beim Signieren mit OpenSSL und PKCS#11 jemals das HSM?

Nein. Das HSM führt die Signierungsoperation intern durch und gibt lediglich die resultierende Signatur zurück. Der private Schlüssel selbst wird vollständig innerhalb der Hardware generiert, gespeichert und verwendet und niemals in einer nutzbaren Form exportiert.

Was ist der größte Unterschied zwischen der Ubuntu- und der Windows-Konfiguration für den PKCS#11-Wrapper von EC?

Unter Ubuntu ist die OpenSSL PKCS#11-Engine im Paketmanager der Distribution enthalten. Unter Windows muss sie manuell aus dem libp11-Projekt von OpenSC mit MSYS2 kompiliert werden, da keine entsprechende, vorkonfigurierte Engine verfügbar ist.

Warum unterscheidet sich der Pfad zu libpkcs11.so zwischen den Ubuntu-Versionen?

Ubuntu 18.04 und 20.04 verwenden das Engine-Verzeichnis von OpenSSL 1.1 (engines-1.1), während Ubuntu 22.04 OpenSSL 3.x ausliefert, welches die Engines auf die engines-3 Verzeichnis. Die Angabe des falschen Pfads für die Konfigurationsdatei ist einer der häufigsten Installationsfehler.

Welcher OpenSSL-Befehl führt die Signieroperation tatsächlich durch, sobald PKCS#11 konfiguriert ist?

Unter Ubuntu ist es openssl pkeyutl -engine pkcs11 -sign mit dem Schlüssel, auf den über ein verwiesen wird pkcs11:object=... URI. Unter Windows entspricht dies folgendem: openssl dgst -engine pkcs11 -keyform engine -signBeide lagern die eigentliche kryptografische Operation über den Wrapper an das HSM aus.

Ist die Speicherung privater Schlüssel als einfache Dateien auf der Festplatte jemals akzeptabel?

Nicht für Signaturschlüssel im Produktivbetrieb. Selbst mit Dateisystemberechtigungen ist ein Schlüssel im Klartext nur eine fehlerhafte Backup-Konfiguration oder ein kompromittiertes Konto von der Offenlegung entfernt. Für kurzlebige Entwicklungs- oder Testschlüssel mag dies tolerierbar sein, aber Signaturschlüssel für Produktion und Release sollten immer in einem HSM oder einem sicheren Token gespeichert werden.

Wie häufig kommen Vorfälle von Diebstahl privater Schlüssel und Anmeldeinformationen bei der Codesignierung vor?

Verbreitet und zunehmend. Laut dem GitGuardian-Bericht „State of Secrets Sprawl 2026“ wurden allein im Jahr 2025 28.65 Millionen neue, fest codierte Geheimnisse auf öffentlichen GitHub-Plattformen offengelegt – ein Anstieg von 34 % gegenüber dem Vorjahr. Die durchschnittliche Zeit zur Behebung eines durchgesickerten Geheimnisses beträgt laut Verizons DBIR 2025 94 Tage, was ein langes Zeitfenster für die Ausnutzung von Sicherheitslücken bietet.

Welche Version von CodeSign Secure enthält aktuell diesen PKCS#11-Wrapper?

CodeSign Secure v3.02, das neben dem PKCS#11-Wrapper auch native LMS- und ML-DSA-Post-Quantum-Signierung, GPG2-Integration, Debian/RPM-Paketsignierung und jsign/jarsigner-Unterstützung hinzufügte.

Welche anderen Signaturwerkzeuge unterstützt CodeSign Secure v3.02 neben dem PKCS#11-Wrapper?

Version 3.02 fügte die GPG2-Signierung über PKCS#11, die Signierung von Debian (.deb)- und RPM-Paketen, jsign für Windows-Binärdateien (EXE, MSI) und jarsigner für Java-Archivdateien (JAR) sowie die native Fortanix HSM-Integration hinzu.

Fazit

Das Signieren mit OpenSSL unter Verwendung von PKCS#11 mag zunächst etwas technisch erscheinen, doch nach der Einrichtung – ob unter Ubuntu oder Windows – ist es ein reibungsloser und sicherer Workflow. Durch die Integration eines PKCS#11-Wrappers können Sie sensible Signiervorgänge von der Softwareebene auf sichere Hardware wie HSMs oder Token verlagern. Dies schützt nicht nur Ihre privaten Schlüssel, sondern hilft Ihnen auch, Compliance-Standards und bewährte Sicherheitspraktiken zu erfüllen.

Wenn Sie einen optimierten Einstieg suchen, vereinfacht der PKCS#11-Wrapper von EC den Integrationsprozess erheblich. Er ist zuverlässig, plattformübergreifend und mit einer Vielzahl von HSMs kompatibel – so können Sie sich voll und ganz auf die Sicherung Ihrer Abläufe konzentrieren und müssen sich weniger mit den grundlegenden Vorgängen herumschlagen. In der heutigen Bedrohungslandschaft schützt der Schutz Ihrer Schlüssel Ihr Unternehmen. Ob Sie Code, Dokumente oder Zertifikate signieren – die Kombination von OpenSSL mit einem robusten PKCS#11-Wrapper wie dem von EC ist eine kluge und zukunftssichere Entscheidung.