Neutralne, oparte na źródłach zestawienie narzędzi do podpisywania kodu i dokumentów dostępnych dla deweloperów Delphi i C++ Builder w 2026 roku: sgcSign, Microsoft SignTool, osslsigncode, Azure Trusted Signing, DigiCert Software Trust Manager, jsign, Adobe Acrobat i SDK PDF iText / Apryse. Każda informacja o funkcji zawiera link do oficjalnej dokumentacji projektu.
Jednostronicowe podsumowanie każdej opcji z linkiem do oficjalnej dokumentacji lub repozytorium. Szczegółowe porównanie znajduje się w macierzy poniżej.
eSeGeCe · Komercyjny
Komercyjny pakiet podpisów cyfrowych dla Delphi / C++ Builder / .NET. Dostępny w dwóch uzupełniających się wariantach, które współdzielą ten sam rdzeń podpisywania. Biblioteka komponentów tworzy podpisy XAdES, PAdES, CAdES i ASiC w procesie, od Delphi 7 do Delphi 13. sgcSign Server dodaje własny demon REST do podpisywania Authenticode (pliki PE), manifestów ClickOnce, pakietów NuGet, pakietów VSIX i skryptów PowerShell, oprócz formatów dokumentów. Dziesięć dostawców kluczy obsługuje lokalne PFX/PEM, magazyn certyfikatów Windows, tokeny sprzętowe PKCS#11, AWS KMS, Azure Trusted Signing, Google Cloud KMS, HashiCorp Vault, Certum SimplySign i dowolny zdalny QTSP CSC v2. Dwadzieścia jeden wstępnie skonfigurowanych profili krajowych obsługuje europejskie e-fakturowanie i podpisywanie umów o pracę eIDAS.
Microsoft · Windows SDK EULA (bezpłatny do celów deweloperskich)
Narzędzie wiersza poleceń firmy Microsoft do podpisywania kodu, dostarczone z Windows 10/11 SDK. Podpisuje i opatruje znacznikami czasu pliki Windows Portable Executable (.exe, .dll, .sys, .cab, .cat) oraz pakiety AppX/MSIX, manifesty ClickOnce i projekty Microsoft Office VBA przez mechanizm SIP (Subject Interface Package). Odczytuje certyfikaty z magazynu certyfikatów Windows, plików PKCS#12, kart inteligentnych i dostawców CSP. Podpisywanie PDF, XML i ETSI XAdES / PAdES / CAdES nie leży w zakresie SignTool.
Michał Trojnara & contributors · GPL-3.0-or-later (open source)
Wieloplatformowe narzędzie open-source do podpisywania Authenticode, oparte na OpenSSL. Podpisuje pliki binarne Windows PE (.exe, .dll, .sys, .cab, .cat), archiwa CAB, pakiety AppX/MSIX, pakiety NuGet i pliki skryptów. Działa na Linux, BSD i macOS oprócz Windows — stąd historyczny powód powstania projektu: umożliwia farmom kompilacji na Linuksie podpisywanie plików binarnych Windows bez uruchamiania SignTool pod Wine. Znaczniki czasu RFC 3161 i starsze Authenticode; źródła certyfikatów to pliki PKCS#12 i tokeny sprzętowe PKCS#11.
Microsoft · Komercyjny (subskrypcja Azure, miesięcznie)
W pełni zarządzana usługa podpisywania kodu firmy Microsoft w Azure (dawniej Azure Code Signing). Klienci nie posiadają certyfikatu podpisywania — Microsoft wystawia krótkotrwały certyfikat co trzy dni i przechowuje klucz prywatny w Azure HSM. Integracje dostępne są dla SignTool, GitHub Actions, Azure Pipelines, PowerShell Trusted Signing i dedykowanej biblioteki dlib (Trusted Signing CSP) udostępniającej klucze każdemu narzędziu obsługującemu CSP. Podpisuje Windows PE, MSIX, AppX, ClickOnce, skrypty VBScript / JScript / PowerShell; podpisywanie PDF / XML nie jest w zakresie.
DigiCert · Komercyjny (subskrypcja)
Platforma podpisywania kodu DigiCert w chmurze. Klucze prywatne są przechowywane w HSM FIPS 140-2 / 140-3 hostowanym przez DigiCert. Podpisuj Windows PE, Java JAR, Android APK, Linux RPM / DEB, obrazy kontenerów, NuGet, pliki binarne Apple Mach-O i inne przez zestaw dedykowanych narzędzi: klienta podpisywania smctl, wtyczkę DigiCert KSP / CSP dla SignTool, natywne integracje Jenkins / GitHub Actions / Azure Pipelines i REST API. Dokumenty (PDF, XAdES) są podpisywane przez oddzielny produkt DigiCert Document Trust Manager.
Emmanuel Bourg · Apache 2.0 (open source)
Narzędzie Authenticode open-source oparte na Javie. Działa jako samodzielne polecenie, wtyczka Maven / Gradle / Ant lub programowe API Java. Podpisuje pliki binarne Microsoft PE, instalatory MSI, pliki skryptów Microsoft (.ps1, .vbs, .js), pakiety MSIX / AppX, archiwa CAB i katalogi CAT. Obsługuje szeroką gamę chmurowych HSM przez jeden CLI: AWS KMS, Azure Key Vault, Azure Trusted Signing, Google Cloud KMS, DigiCert ONE, HashiCorp Vault, Oracle Cloud KMS, Yubico YubiHSM, AWS CloudHSM (przez PKCS#11) i dowolne urządzenie PKCS#11.
Adobe · Komercyjny (subskrypcja)
Adobe Acrobat Pro i Adobe Acrobat Sign to produkty dla użytkowników końcowych do podpisywania dokumentów PDF. Acrobat Pro stosuje podpisy cyfrowe i certyfikowane ze znacznikami czasu oraz waliduje przychodzące podpisy PDF; Acrobat Sign (dawniej EchoSign) to usługa chmurowa do zbierania podpisów elektronicznych od stron zewnętrznych. Żadne z nich nie jest biblioteką deweloperską: brak SDK dla Delphi / C++ Builder i narzędzia do podpisywania z wiersza poleceń. Walidacja długoterminowa PAdES jest obsługiwana po stronie walidacji przez Adobe Approved Trust List (AATL) i European Union Trusted List (EUTL).
iText Group / Apryse Software (PDFTron) · Komercyjny (AGPL lub licencja komercyjna)
Dwa komercyjne SDK PDF powszechnie używane do nienadzorowanego podpisywania PDF w aplikacjach po stronie serwera. iText Core (dawniej iTextSharp) dostępny jest dla Java i .NET na licencji AGPL-3.0 lub komercyjnej; przestrzeń nazw com.itextpdf.signatures obsługuje PAdES-B-B / B-T / B-LT / B-LTA, certyfikacje MDP (wykrywanie modyfikacji) i widoczne podpisy. Apryse PDFTron to komercyjne wieloplatformowe SDK (Java, .NET, C++, Node.js, Python, Go, iOS, Android, web) z API PDF.SignatureHandler i obsługą PAdES. Żaden z dostawców nie dostarcza natywnego wiązania dla Delphi.
Znacznik () oznacza udokumentowaną natywną obsługę. Myślnik (—) oznacza brak natywnej obsługi. Tylda (~) oznacza częściową obsługę / przez dodatek / niewyraźnie udokumentowaną — patrz sekcja Źródła, aby zobaczyć, co udało nam się zweryfikować.
| Funkcja | sgcSign | Microsoft SignTool | osslsigncode | Azure Trusted Signing | DigiCert Software Trust Manager | jsign | Adobe Acrobat / Adobe Sign | iText / Apryse |
|---|---|---|---|---|---|---|---|---|
| Podpisywanie plików binarnych Windows Authenticode dla .exe / .dll / .sys / .ocx | — | — | ||||||
| Podpisywanie manifestów ClickOnce pliki .application / .manifest | ~ | ~ | — | — | ||||
| Podpisywanie pakietów NuGet / VSIX kontenery .nupkg / .vsix | ~ | ~ | ~ | ~ | — | — | ||
| Podpisywanie pakietów mobilnych (APK / IPA) pakiety Android APK lub iOS IPA | — | — | — | — | — | — | — | |
| Podpisywanie dokumentów PDF (PAdES) ETSI EN 319 142, zgodne z Adobe | — | — | — | ~ | — | |||
| Podpisywanie dokumentów Office Word / Excel / PowerPoint docx / xlsx / pptx | — | ~ | — | — | — | — | — | — |
| Podpisywanie dokumentów XML (XAdES) ETSI EN 319 132 | — | — | — | ~ | — | — | ~ | |
| Natywne API Delphi / C++ Builder Komponenty VCL / FMX pierwszej klasy | — | — | — | — | — | — | — | |
| Narzędzia wieloplatformowe Działa na Windows, Linux i macOS | ~ | — | ~ | |||||
| Obsługa chmurowego HSM AWS / Azure / GCP / HashiCorp / CSC v2 | ~ | ~ | ~ | ~ | ||||
| Profile krajowe eIDAS Wstępnie skonfigurowane profile podpisywania dla każdego kraju (VeriFactu, KSeF itp.) | — | — | — | ~ | — | ~ | ~ | |
| Samodzielny interfejs CLI Dołączony klient wiersza poleceń | ~ | — | — | |||||
| Biblioteka / SDK Programowe API do wywołania przez aplikację | — | — | ~ | ~ | ~ | — | ||
| Aktywne utrzymanie Wydanie lub aktywność tagów w ciągu ostatnich 12–18 miesięcy | ||||||||
| Model licencji Typ licencji | Commercial | Windows SDK EULA | GPL-3.0-or-later | Commercial (Azure subscription) | Commercial (subscription) | Apache 2.0 | Commercial (subscription) | AGPL or Commercial (iText) / Commercial (Apryse) |
Każda opcja ma prawdziwych odbiorców. Właściwy wybór zależy od tego, czy podpisujesz kod, dokumenty lub jedno i drugie, środowiska uruchomieniowego obsługującego logikę podpisywania, preferencji dotyczących przechowywania kluczy i preferencji licencyjnych.
Wybierz sgcSign, gdy budujesz aplikację w Delphi 7–13, C++ Builder or .NET i chcesz jednego zestawu komponentów produkującego zarówno podpisy dokumentów (XAdES, PAdES, CAdES, ASiC), jak i podpisy kodu (Authenticode, ClickOnce, NuGet, VSIX, PowerShell) z tej samej abstrakcji dostawcy kluczy. 21 wstępnie skonfigurowanych profili krajowych obsługuje europejskie e-fakturowanie i podpisywanie umów o pracę eIDAS; wariant serwerowy centralizuje przechowywanie kluczy dla farm kompilacji.
Wybierz Microsoft SignTool, gdy wszystkie artefakty, które podpisujesz, to pliki binarne Windows (PE / .cab / AppX / MSIX) a host kompilacji działa na Windows. SignTool to referencyjny interfejs wiersza poleceń współpracujący z każdą usługą podpisywania w chmurze dostarczającą CSP / KSP (DigiCert KeyLocker, Azure Trusted Signing, GlobalSign Atlas itp.), a instalacja Windows SDK jest bezpłatna.
Wybierz osslsigncode, gdy twój host kompilacji działa na Linuksie, BSD or macOS a artefakty do podpisania to pliki binarne Windows — archiwa CAB, pliki PE, pakiety MSIX lub NuGet. Licencja GPL-3.0 pasuje naturalnie do potoków CI, które już używają OpenSSL i tokenów sprzętowych PKCS#11.
Wybierz Azure Trusted Signing, gdy chcesz w pełni zarządzanej usługi podpisywania kodu Windows gdzie Microsoft jest właścicielem certyfikatu i HSM, gdy zespół już działa na Azure, a artefakty do podpisania to Windows PE, MSIX, AppX, ClickOnce lub PowerShell. Model krótkotrwałego certyfikatu usuwa obciążenie odnowieniem i weryfikacją tożsamości związane z posiadaniem certyfikatu podpisywania kodu.
Wybierz DigiCert Software Trust Manager, gdy już kupujesz certyfikat podpisywania kodu DigiCert i chcesz, aby był przechowywany w ich zwalidowanym FIPS HSM z jednym centralnym panelem do odnowień, unieważnień i audytu. Natywny klient smctl i wtyczka SignTool KSP obsługują pliki binarne Windows, Java JAR, obrazy kontenerów i pakiety mobilne w jednym przepływie pracy.
Wybierz jsign, gdy pipeline budowania już działa na łańcuchu narzędzi JVM (Maven, Gradle, Ant or Jenkins on JDK), gdy chcesz jednego CLI obsługującego każdy główny chmurowy HSM, a artefakty do podpisania to Windows PE / MSI / MSIX / pliki skryptów. Licencja Apache 2.0 pasuje czysto do zamkniętych przepływów kompilacji.
Wybierz Adobe Acrobat / Adobe Sign, gdy przepływ podpisywania jest interaktywny i sterowany przez człowieka — osoba otwiera plik PDF w Acrobacie, umieszcza widoczny podpis i wysyła plik. Acrobat Sign rozszerza ten wzorzec o wielostronne przepływy podpisywania zbierane przez e-mail. Nie jest wymagana automatyzacja czasu kompilacji ani po stronie serwera.
Wybierz iText lub Apryse PDFTron, gdy aplikacja jest zbudowana na Java, .NET, C++ lub jednym z innych obsługiwanych środowisk a PDF jest dominującym formatem dokumentów. Oba SDK mają dojrzałą obsługę PAdES, szerokie pokrycie funkcji PDF poza podpisywaniem (formularze, redakcja, renderowanie) i znane referencje enterprise.
Krótkie uwagi o różnicach, jeśli przechodzisz z jednej z powyższych opcji. Bez konfrontacji — tylko praktyczne mapowanie.
SignTool obsługuje wyłącznie podpisywanie kodu Windows. Jeśli aplikacja już wywołuje SignTool ze skryptu kompilacji, sgcSign Server udostępnia punkt końcowy REST do podpisywania, który przyjmuje plik binarny i nazwę dostawcy i zwraca podpisany artefakt — ten sam przepływ pracy, ale operacja Authenticode działa centralnie, a wynikowy ślad audytu, przepływ zatwierdzania i limity per-projekt żyją w jednym miejscu. Podpisywanie dokumentów (XAdES / PAdES / CAdES / ASiC) jest wtedy dostępne z tego samego daemona.
Jeśli potok kompilacji używa osslsigncode do podpisywania Authenticode plików binarnych Windows z agentów kompilacji Linux, sgcSign Server zapewnia ten sam przepływ przez API HTTPS i dodaje sterowniki pierwszej klasy dla AWS KMS, Azure Trusted Signing, Google Cloud KMS i HashiCorp Vault oprócz ścieżki PKCS#11, z której możesz już korzystać. Formaty dokumentów (PDF / XML / CMS) są wtedy dostępne z tego samego punktu końcowego.
sgcSign udostępnia Azure Trusted Signing jako jednego z dziesięciu dostawców kluczy (TsgcAzureTrustedSigningProvider), dzięki czemu aplikacja Delphi lub C++ Builder może bezpośrednio korzystać z Azure Trusted Signing — ten sam klucz prywatny, ten sam publiczny certyfikat zaufania Microsoft, ale sygnatariusz działa w procesie. Jeśli potrzebujesz też podpisywania dokumentów PDF / XAdES / CAdES, ten sam dostawca kluczy obsługuje sygnatariuszy dokumentów.
Jeśli dziś podpisujesz pliki binarne Windows za pomocą smctl, sgcSign Server może korzystać z tego samego certyfikatu podpisywania kodu przez dostawcę PKCS#11 udostępnionego przez DigiCert i dodaje podpisywanie dokumentów XAdES / PAdES / CAdES pierwszej klasy — przydatne, gdy aplikacja potrzebuje zarówno podpisów kodu, jak i dokumentów z jednego daemona.
jsign obsługuje podpisywanie kodu Windows w szerokim zakresie chmurowych HSM. sgcSign Server pokrywa się w macierzy chmurowych HSM (AWS KMS, Azure Trusted Signing, Google Cloud KMS, HashiCorp Vault) i dodaje podpisywanie dokumentów ETSI (PAdES, XAdES, CAdES, ASiC) oraz 21 profili krajowych — przydatne, gdy ten sam klucz ma produkować zarówno podpisy kodu, jak i dokumentów.
Adobe Acrobat to narzędzie dla użytkowników końcowych, nie biblioteka deweloperska. Jeśli obecnie prosisz użytkowników końcowych o podpisywanie plików PDF w Acrobacie, a teraz chcesz nienadzorowanych podpisów PAdES po stronie serwera, sgcSign dostarcza sygnatariusza PDF (TsgcPAdESSigner) oraz klientów znaczników czasu i OCSP do produkcji podpisów PAdES-T i PAdES-LT z potoku kompilacji lub usługi backendowej.
iText i Apryse nie dostarczają natywnego wiązania dla Delphi, więc aplikacje Delphi zazwyczaj owijają ich SDK .NET lub Java za cienkim mostem. sgcSign produkuje podpisy PAdES-B-B / B-T / B-LT z natywnego kodu Delphi i C++ Builder — warstwa mostu znika, a ten sam łańcuch dostawcy kluczy, który podpisuje PDF, podpisuje też artefakty XML, CMS i Authenticode.
Każda komórka w powyższej macierzy prowadzi do jednej z tych oficjalnych stron dokumentacji, repozytoriów lub notatek o wydaniu. Wszystkie adresy URL zostały sprawdzone metodą HEAD w czasie pisania.