Eine neutrale, mit Quellen belegte Übersicht der Code- und Dokumenten-Signaturtools, die Delphi- und C++ Builder-Entwicklern 2026 zur Verfügung stehen: sgcSign, Microsoft SignTool, osslsigncode, Azure Trusted Signing, DigiCert Software Trust Manager, jsign, Adobe Acrobat und die iText-/Apryse-PDF-SDKs. Jede Funktionsangabe verlinkt auf die eigene Dokumentation des Projekts.
Eine kurze Zusammenfassung jeder Option mit Link zur offiziellen Dokumentation oder zum Repository. Der ausführliche Vergleich steht in der Matrix unten.
eSeGeCe · Kommerziell
Kommerzielle Suite für digitale Signaturen in Delphi / C++ Builder / .NET. Wird in zwei sich ergänzenden Varianten ausgeliefert, die denselben Signaturkern nutzen. Die Komponentenbibliothek erzeugt XAdES-, PAdES-, CAdES- und ASiC-Signaturen in-process von Delphi 7 bis Delphi 13. Der sgcSign Server ergänzt einen selbst gehosteten REST-Signaturdienst, der zusätzlich zu den Dokumentformaten Authenticode (PE-Binaries), ClickOnce-Manifeste, NuGet-Pakete, VSIX-Bundles und PowerShell-Skripte signiert. Zehn Schlüsselanbieter decken lokale PFX/PEM, den Windows-Zertifikatsspeicher, PKCS#11-Hardware-Token, AWS KMS, Azure Trusted Signing, Google Cloud KMS, HashiCorp Vault, Certum SimplySign und jeden Remote-QTSP gemäß CSC v2 ab. 21 vorkonfigurierte Länderprofile steuern europäische E-Rechnungen und die eIDAS-konforme Signatur von Arbeitsverträgen.
Microsoft · Windows SDK EULA (kostenlos für die Entwicklung)
Microsofts Kommandozeilen-Tool für Code-Signaturen, das mit dem Windows 10-/Windows 11-SDK ausgeliefert wird. Signiert und stempelt Windows-Portable-Executable-Dateien (.exe, .dll, .sys, .cab, .cat) sowie AppX-/MSIX-Pakete, ClickOnce-Manifeste und Microsoft Office Visual Basic for Applications-Projekte über den SIP-Mechanismus (Subject Interface Package). Liest Zertifikate aus dem Windows-Zertifikatsspeicher, aus PKCS#12-Dateien, von Smartcards und von Cloud Signing Service (CSP)-Anbietern. PDF-, XML- und ETSI-XAdES-/PAdES-/CAdES-Signaturen gehören nicht zum Aufgabenbereich von SignTool.
Michał Trojnara & Mitwirkende · GPL-3.0-or-later (Open Source)
Plattformübergreifendes Open-Source-Tool für Authenticode-Signaturen, basierend auf OpenSSL. Signiert Microsoft PE-Binaries (.exe, .dll, .sys, .cab, .cat), CAB-Archive, AppX-/MSIX-Pakete, NuGet-Pakete und Skriptdateien. Läuft neben Windows auch unter Linux, BSD und macOS — das ist der historische Hintergrund des Projekts: Linux-Build-Farmen können damit Windows-Binaries signieren, ohne SignTool unter Wine laufen zu lassen. RFC 3161 und klassische Authenticode-Zeitstempel; Zertifikatsquellen sind unter anderem PKCS#12-Dateien und PKCS#11-Hardware-Token.
Microsoft · Kommerziell (Azure-Abonnement, monatlich)
Microsofts vollständig verwalteter Code-Signaturdienst in Azure (ehemals Azure Code Signing). Kunden besitzen das Signaturzertifikat nicht — Microsoft stellt alle drei Tage ein kurzlebiges Zertifikat aus und speichert den privaten Schlüssel in einem Azure-HSM. Integrationen gibt es für SignTool, GitHub Actions, Azure Pipelines, Trusted Signing PowerShell sowie eine eigene dlib (Trusted Signing CSP), die die Schlüssel für jedes CSP-fähige Tool bereitstellt. Signiert Windows-PE, MSIX, AppX, ClickOnce, VBScript-/JScript-/PowerShell-Skripte; PDF-/XML-Signatur ist nicht enthalten.
DigiCert · Kommerziell (Abonnement)
DigiCerts Cloud-Plattform für Code-Signaturen. Private Schlüssel liegen in einem von DigiCert gehosteten FIPS-140-2-/140-3-HSM. Signiert Windows-PE, Java-JAR, Android-APK, Linux-RPM/-DEB, Container-Images, NuGet, Apple-Mach-O-Binaries und mehr über eine Reihe dedizierter Tools: den smctl-Signing-Client, das DigiCert KSP-/CSP-Plug-in für SignTool, native Jenkins-/GitHub-Actions-/Azure-Pipelines-Integrationen und eine REST-API. Dokumente (PDF, XAdES) werden über das separate Produkt DigiCert Document Trust Manager signiert.
Emmanuel Bourg · Apache 2.0 (Open Source)
Open-Source-Tool für Authenticode-Signaturen auf Java-Basis. Läuft als eigenständiger Befehl, als Maven-/Gradle-/Ant-Plug-in oder über eine programmatische Java-API. Signiert Microsoft PE-Binaries, MSI-Installer, Microsoft-Skriptdateien (.ps1, .vbs, .js), MSIX-/AppX-Pakete, CAB-Archive und CAT-Kataloge. Unterstützt eine breite Liste von Cloud-HSMs über eine einzige CLI: AWS KMS, Azure Key Vault, Azure Trusted Signing, Google Cloud KMS, DigiCert ONE, HashiCorp Vault, Oracle Cloud KMS, Yubico YubiHSM, AWS CloudHSM (über PKCS#11) und jedes PKCS#11-Gerät.
Adobe · Kommerziell (Abonnement)
Adobe Acrobat Pro und Adobe Acrobat Sign sind Endanwender-Produkte zum Signieren von PDF-Dokumenten. Acrobat Pro vergibt digitale Signaturen und zertifizierte Signaturen mit Zeitstempeln und validiert eingehende PDF-Signaturen; Acrobat Sign (ehemals EchoSign) ist ein Cloud-Dienst, um elektronische Signaturen von externen Parteien einzuholen. Keines davon ist eine Entwicklerbibliothek: Es gibt kein Delphi-/C++ Builder-SDK und kein Kommandozeilen-Signaturtool im Lieferumfang. PAdES Long-Term Validation wird auf Validierungsseite über die Adobe Approved Trust List (AATL) und die European Union Trusted List (EUTL) unterstützt.
iText Group / Apryse Software (PDFTron) · Kommerziell (AGPL oder kommerzielle Lizenz)
Zwei kommerzielle PDF-SDKs, die häufig für unbeaufsichtigte PDF-Signaturen in serverseitigen Anwendungen eingesetzt werden. iText Core (ehemals iTextSharp) ist für Java und .NET unter AGPL-3.0 oder einer kommerziellen Lizenz verfügbar; der Namensraum com.itextpdf.signatures deckt PAdES-B-B / B-T / B-LT / B-LTA, MDP-Zertifizierungen (Modification Detection) und sichtbare Erscheinungsbilder ab. Apryse PDFTron ist ein kommerzielles plattformübergreifendes SDK (Java, .NET, C++, Node.js, Python, Go, iOS, Android, Web) mit einer PDF.SignatureHandler-API und PAdES-Unterstützung. Keiner der Anbieter liefert ein natives Delphi-Binding mit.
Ein Häkchen () bedeutet, dass das Projekt native Unterstützung dokumentiert. Ein Strich (—) bedeutet, dass das Projekt sie nicht nativ bereitstellt. Eine Tilde (~) bedeutet teilweise / per Add-on / nicht ausdrücklich dokumentiert — im Abschnitt „Quellen“ steht, was wir verifizieren konnten.
| Funktion | sgcSign | Microsoft SignTool | osslsigncode | Azure Trusted Signing | DigiCert Software Trust Manager | jsign | Adobe Acrobat / Adobe Sign | iText / Apryse |
|---|---|---|---|---|---|---|---|---|
| Windows-Binaries signieren Authenticode für .exe / .dll / .sys / .ocx | — | — | ||||||
| ClickOnce-Manifeste signieren .application-/.manifest-Dateien | ~ | ~ | — | — | ||||
| NuGet-/VSIX-Pakete signieren .nupkg-/.vsix-Container | ~ | ~ | ~ | ~ | — | — | ||
| Mobile Pakete signieren (APK / IPA) Android-APK- oder iOS-IPA-Bundles | — | — | — | — | — | — | — | |
| PDF-Dokumente signieren (PAdES) ETSI EN 319 142, Adobe-kompatibel | — | — | — | ~ | — | |||
| Office-Dokumente signieren Word / Excel / PowerPoint docx / xlsx / pptx | — | ~ | — | — | — | — | — | — |
| XML-Dokumente signieren (XAdES) ETSI EN 319 132 | — | — | — | ~ | — | — | ~ | |
| Native Delphi-/C++ Builder-API Erstklassige VCL-/FMX-Komponenten | — | — | — | — | — | — | — | |
| Plattformübergreifende Tools Läuft unter Windows, Linux und macOS | ~ | — | ~ | |||||
| Cloud-HSM-Unterstützung AWS / Azure / GCP / HashiCorp / CSC v2 | ~ | ~ | ~ | ~ | ||||
| eIDAS-/Länderprofil-Voreinstellungen Länderspezifische Signaturvoreinstellungen (VeriFactu, KSeF usw.) | — | — | — | ~ | — | ~ | ~ | |
| Eigenständige CLI Kommandozeilen-Client enthalten | ~ | — | — | |||||
| Bibliothek / SDK Programmatische API für den Aufruf aus einer Anwendung | — | — | ~ | ~ | ~ | — | ||
| Aktive Pflege Release- oder Tag-Aktivität in den letzten 12–18 Monaten | ||||||||
| Lizenzmodell Lizenztyp | Kommerziell | Windows SDK EULA | GPL-3.0-or-later | Kommerziell (Azure-Abo) | Kommerziell (Abo) | Apache 2.0 | Kommerziell (Abo) | AGPL oder kommerziell (iText) / kommerziell (Apryse) |
Jede Option hier hat ihre echte Zielgruppe. Die richtige Wahl hängt davon ab, ob du Code, Dokumente oder beides signierst, in welcher Laufzeit die Signaturlogik läuft, wie du Schlüssel verwahren willst und welche Lizenz du bevorzugst.
Wähle sgcSign, wenn du deine Anwendung mit Delphi 7–13, C++ Builder oder .NET baust und eine einzige Komponenten-Suite willst, die aus derselben Schlüsselanbieter-Abstraktion sowohl Dokumentsignaturen (XAdES, PAdES, CAdES, ASiC) als auch Code-Signaturen (Authenticode, ClickOnce, NuGet, VSIX, PowerShell) erzeugt. Die 21 vorkonfigurierten Länderprofile decken die europäische E-Rechnung und die eIDAS-konforme Signatur von Arbeitsverträgen ab; die Server-Variante zentralisiert die Schlüsselverwahrung für Build-Farmen.
Wähle Microsoft SignTool, wenn deine zu signierenden Artefakte allesamt Windows-Binaries sind (PE / .cab / AppX / MSIX) und der Build-Host unter Windows läuft. SignTool ist die Referenz-CLI, die zu jedem Cloud-Signaturdienst passt, der einen CSP/KSP mitbringt (DigiCert KeyLocker, Azure Trusted Signing, GlobalSign Atlas usw.) — und die Installation des Windows-SDK ist kostenlos.
Wähle osslsigncode, wenn dein Build-Host unter Linux, BSD oder macOS läuft und du Windows-Artefakte signieren willst — CAB-Archive, PE-Dateien, MSIX-Pakete oder NuGet-Pakete. Die GPL-3.0-Lizenz passt natürlich in CI-Pipelines, die bereits OpenSSL und PKCS#11-Hardware-Token nutzen.
Wähle Azure Trusted Signing, wenn du einen vollständig verwalteten Windows-Code-Signaturdienst willst, bei dem Microsoft Zertifikat und HSM besitzt, wenn dein Team ohnehin in Azure arbeitet und wenn die zu signierenden Artefakte Windows-PE, MSIX, AppX, ClickOnce oder PowerShell sind. Das Modell mit kurzlebigen Zertifikaten nimmt dir den Aufwand für Verlängerung und Identitätsprüfung bei einem eigenen Code-Signing-Zertifikat ab.
Wähle DigiCert Software Trust Manager, wenn du bereits das DigiCert-Code-Signing-Zertifikat kaufst und es in deren FIPS-validiertem HSM gespeichert haben willst — mit einer zentralen Oberfläche für Verlängerungen, Widerrufe und Audits. Der native smctl-Client und das SignTool-KSP-Plug-in decken Windows-Binaries, Java-JARs, Container-Images und Mobile-Pakete in einem einzigen Workflow ab.
Wähle jsign, wenn deine Build-Pipeline bereits auf einer JVM-Toolchain läuft (Maven, Gradle, Ant oder Jenkins auf dem JDK), wenn du eine einzige CLI willst, die jedes gängige Cloud-HSM bedient, und wenn du Windows-PE / MSI / MSIX / Skriptdateien signierst. Die Apache-2.0-Lizenz fügt sich sauber in Closed-Source-Build-Flows ein.
Wähle Adobe Acrobat / Adobe Sign, wenn der Signaturworkflow interaktiv und menschengetrieben ist — eine Person öffnet ein PDF in Acrobat, platziert eine sichtbare Signatur und schickt die Datei weiter. Acrobat Sign weitet dieses Muster auf Mehrparteien-Signaturabläufe per E-Mail aus. Build-Zeit- oder serverseitige Automatisierung ist nicht erforderlich.
Wähle iText oder Apryse PDFTron, wenn deine Anwendung auf Java, .NET, C++ oder einer der anderen unterstützten Laufzeiten basiert und PDF das dominierende Dokumentformat ist. Beide SDKs bieten ausgereifte PAdES-Unterstützung, starke PDF-Funktionsabdeckung jenseits der Signatur (Formulare, Schwärzung, Rendering) und prominente Enterprise-Referenzen.
Kurze Hinweise zu den Unterschieden, falls du von einer der obigen Optionen wechselst. Nicht konfrontativ — einfach die praktische Zuordnung.
SignTool deckt ausschließlich Windows-Code-Signaturen ab. Wenn deine Anwendung SignTool bereits aus einem Build-Skript heraus aufruft, stellt der sgcSign Server einen REST-Signatur-Endpoint bereit, der ein Binary und einen Anbieternamen entgegennimmt und das signierte Artefakt zurückgibt — derselbe Workflow, aber die Authenticode-Operation läuft zentral, und der daraus resultierende Audit-Trail, Freigabe-Workflow und projektbezogene Kontingente liegen an einem Ort. Dokumentensignaturen (XAdES / PAdES / CAdES / ASiC) sind dann aus demselben Daemon verfügbar.
Wenn deine Build-Pipeline osslsigncode nutzt, um Windows-Binaries von Linux-Build-Agents aus Authenticode zu signieren, bietet dir der sgcSign Server denselben Ablauf über eine HTTPS-API — und ergänzt erstklassige Treiber für AWS KMS, Azure Trusted Signing, Google Cloud KMS und HashiCorp Vault zusätzlich zum PKCS#11-Pfad, den du eventuell schon einsetzt. Dokumentformate (PDF / XML / CMS) sind dann aus demselben Endpoint verfügbar.
sgcSign stellt Azure Trusted Signing als einen seiner zehn Schlüsselanbieter bereit (TsgcAzureTrustedSigningProvider), sodass eine Delphi- oder C++ Builder-Anwendung Azure Trusted Signing direkt ansteuern kann — derselbe private Schlüssel, dasselbe von Microsoft ausgestellte Public-Trust-Zertifikat, aber der Signer läuft in-process. Wenn du zusätzlich PDF-/XAdES-/CAdES-Dokumentsignaturen brauchst, bedient derselbe Schlüsselanbieter auch die Dokumentsigner.
Wenn du Windows-Binaries heute mit smctl signierst, kann der sgcSign Server dasselbe Code-Signing-Zertifikat über den von DigiCert bereitgestellten PKCS#11-Provider ansteuern und ergänzt obendrein erstklassige XAdES-/PAdES-/CAdES-Dokumentsignaturen — nützlich, wenn eine Anwendung Code- und Dokumentensignaturen aus einem Daemon braucht.
jsign deckt Windows-Code-Signaturen über eine breite Palette von Cloud-HSMs ab. Der sgcSign Server überschneidet sich bei der Cloud-HSM-Matrix (AWS KMS, Azure Trusted Signing, Google Cloud KMS, HashiCorp Vault) und ergänzt ETSI-Dokumentsignaturen (PAdES, XAdES, CAdES, ASiC) sowie die 21 Länderprofile — nützlich, wenn derselbe Schlüssel sowohl Code- als auch Dokumentensignaturen erzeugen muss.
Adobe Acrobat ist ein Endanwender-Tool, keine Entwicklerbibliothek. Wenn du Endnutzer heute PDFs in Acrobat signieren lässt und nun unbeaufsichtigte serverseitige PAdES-Signaturen willst, liefert sgcSign den PDF-Signer (TsgcPAdESSigner) sowie Timestamp- und OCSP-Clients, um aus einer Build-Pipeline oder einem Backend-Dienst PAdES-T- und PAdES-LT-Signaturen zu erzeugen.
iText und Apryse bieten kein natives Delphi-Binding, also umschließen Delphi-Anwendungen ihr .NET- oder Java-SDK in der Regel mit einer dünnen Bridge. sgcSign erzeugt PAdES-B-B / B-T / B-LT-Signaturen aus nativem Delphi- und C++ Builder-Code — die Bridge-Schicht entfällt, und dieselbe Schlüsselanbieter-Kette, die PDFs signiert, signiert auch XML-, CMS- und Authenticode-Artefakte.
Jede Zelle in der Matrix oben verweist auf eine dieser offiziellen Dokumentationsseiten, Repositories oder Release Notes. Alle URLs wurden zum Redaktionszeitpunkt per HEAD-Anfrage geprüft.