Ein selbst gehosteter Daemon für Remote-Code-Signing, der die sgcSign-Engine hinter einer REST-API, einer Bootstrap-Web-Admin-Konsole und fertigen CI/CD-Pipelines bündelt.
Ein einziger Host, Windows oder Linux, nimmt Signing-Requests von Build-Agents, Entwicklern und CI-Pipelines entgegen — mit eingebautem Audit, Genehmigungen und Metriken.
TLS-gesicherte /api/v1-Endpunkte für Signaturerstellung, Verifizierung, Health, Metriken und Genehmigungs-Workflows. Stabiler, maschinenfreundlicher Vertrag für Build-Agents und SDKs.
Bootstrap-basierte /admin-Oberfläche für Nutzer, API-Keys, Provider, Projekte, Audit, Genehmigungen, Webhooks und Metriken. Betreiber müssen kein JSON editieren.
Inno-Setup-Assistent oder Zip-Drop. Der Daemon registriert sich als Windows-Service, terminiert TLS selbst und läuft unbeaufsichtigt auf einem gehärteten Host.
Jedes Projekt isoliert einen Ausschnitt aus Providern, API-Keys, Audit-Sichtbarkeit und Genehmigungs-Queues. Mehrere Teams teilen sich einen Server, ohne das Signing-Material des jeweils anderen zu sehen.
Derselbe API-Key stellt den Antrag, ein Admin oder Projekt-Admin genehmigt oder lehnt ab, erst danach werden die Bytes signiert. SHA-256-Hash und Dateigröße werden in den Antrag eingebrannt.
Jede Aktion — Signieren, Verifizieren, Login, Genehmigung, Webhook-Auslösung — wird an ein hash-verkettetes Audit-Log angehängt. Manipulationen sind erkennbar; SIEM-Scraping ist unkompliziert.
Counter für Sign / Verify / Approval, Histogramme zur Signaturlatenz, Gauges zur Provider-Verfügbarkeit. Direktes Prometheus-0.0.4-Text-Format ohne zusätzliche Datenbank.
13 Lifecycle-Events, ausgeliefert mit X-Sgcsign-Signature: sha256=…. Eine Retry-Queue mit drei Versuchen hält SIEM, Chat und Ticketing-Systeme synchron.
Dieselbe Engine wie in der Bibliothek, freigegeben über die REST-API. Jedes Länderprofil, jede Signaturstufe.
XML-Signaturen für VeriFactu, FatturaPA, Facturae, KSeF, e-Factura, Peppol, myDATA und EU-Arbeitsverträge. POST /api/v1/sign/xades.
PAdES-Basic-PDF-Signaturen mit inkrementellen Updates, die den Originalinhalt erhalten. Sichtbare oder unsichtbare Signaturen. POST /api/v1/sign/pades.
CMS-/PKCS#7-Signaturen, detached oder attached, für beliebige Binärdaten. Zeitstempel + Long-Term Validation. POST /api/v1/sign/cades.
Erstellt und signiert einen erfassten Verkauf mit einem Schlüssel, den der Server verwaltet, sendet ihn optional an die Steuerbehörde und gibt die Antwort zurück. Mehrere Kassen einer Kette teilen sich ein Zertifikat des Steuerpflichtigen. POST /api/v1/sign/eet.
Der Signing-Daemon spricht mit der Zertifikatsquelle, die du konfigurierst: Windows-Store, PFX, PKCS#11-Hardware-Token, Azure Trusted Signing, AWS KMS, Google KMS.
Signiere .exe, .dll, .msi, .cab, .cat, .ocx, .sys. Im Hash-only-Modus tauschen Runner mit wenig Bandbreite ein paar Dutzend Bytes gegen einen 8-KB-PKCS#7-Blob.
Signiere ClickOnce-Manifeste (.application / .manifest), damit Windows-Clients ohne Trust-Prompts installieren. POST /api/v1/sign/clickonce.
Signiere .nupkg-Pakete, damit der NuGet-Client die Publisher-Identität validiert. Author- und Repository-Signaturen werden unterstützt. POST /api/v1/sign/nuget.
Signiere Visual-Studio-Erweiterungspakete, damit VS Marketplace und die IDE selbst sie als vertrauenswürdig akzeptieren. POST /api/v1/sign/vsix.
Build-Agents sprechen einen stabilen REST-Endpunkt an, statt auf jedem Runner Signatur-Zertifikate zu installieren.
Eine Composite Action schickt das Artefakt an die REST-API des Servers. Das Token wird im Web-Admin ausgestellt, auf ein Projekt eingeschränkt und verlässt nie den Secret-Store des Runners.
Ein Pipeline-Task führt den sgcSign-CLI-Client aus, der das Binary hochlädt, bei Bedarf auf Genehmigung wartet und das signierte Ergebnis herunterlädt — alles in einem Schritt.
Snippet für deklarative Pipelines mit curl oder der mitgelieferten CLI. Funktioniert mit Linux- und Windows-Agents; die Signatur erscheint als Build-Artefakt.
Image mit dem Daemon und einer Beispiel-Provider-Konfiguration. Starte den Container, mounte dein TLS-Zertifikat + Provider-Secrets und du hast einen portablen Signing-Dienst.
Deploye auf Kubernetes für vollständig redundantes, skalierbares Signing. Kombiniere mit Cloud-KMS (Azure Trusted Signing, AWS KMS, Google KMS) für schlüssellose Pods.
Ein einziger Windows-Dienst terminiert TLS, stellt /api/v1 + /admin bereit und greift bei jedem Aufruf auf den konfigurierten Key-Provider zu. Schlüsselmaterial liegt nie in der Datenbank.
/api/v1 über HTTPS mit einem Bearer-API-Key an.
/admin an. Bootstrap-UI, Session-Cookies, rollenbasierter Zugriff.
+----------------------------+
| Build agents / CI / CLI |
+-------------+--------------+
|
| HTTPS (TLS 1.2/1.3)
v
+-------------------------------------------+
| sgcSignServer.exe (Windows service) |
| /api/v1/* (signing, verify, health) |
| /admin/* (web console, sessions) |
+---+-----------------+---------------------+
| | |
v v v
+-------------+ +---------------+ +-----------+
| SQLite DB | | KeyProviders | | Webhooks |
| (audit/keys)| | PFX/HSM/KMS | | (outbound)|
+-------------+ +---------------+ +-----------+curl entferntEin Bearer-API-Key, ein Hash- oder Datei-Upload, und das signierte Binary fließt zurück auf stdout. Authenticode, CAdES, PAdES, XAdES, ClickOnce, NuGet, VSIX folgen alle derselben Form.
X-API-Key oder Authorization: Bearer — beide Auth-Methoden funktionieren.
X-Project wählt den Mandanten; der Key muss für das Projekt autorisiert sein.
X-Sgcsign-Signer-Subject + X-Sgcsign-Duration-Ms für die Log-Korrelation.
# Authenticode-sign MyApp.exe via the REST API
curl -X POST https://sign.example.com/api/v1/sign \
-H "Authorization: Bearer $TOKEN" \
-H "X-Project: production" \
-F "format=authenticode" \
-F "file=@./MyApp.exe" \
-o MyApp-signed.exe
# Headers returned by the server
# X-Sgcsign-Signer-Subject: CN=ACME Corp, O=ACME, C=US
# X-Sgcsign-Duration-Ms: 312Vom frischen Windows-Host zum ersten signierten Artefakt in unter fünf Minuten.
Starte den mitgelieferten Inno-Setup-Assistenten oder lege das ZIP in einen Ordner ab. Der Daemon registriert sich als Windows-Service namens sgcSignServer. Binde dich auf :8443 und lade dein TLS-Zertifikat.
Trage einen Provider in sgcSignServer.conf.json ein — eine PFX-Datei, ein Azure-Trusted-Signing-Konto, einen AWS-KMS-Key, einen Certum-SimplySign-Nutzer oder einen der zehn anderen Key-Provider. Ein Neustart des Dienstes ist nicht nötig.
Öffne /admin/apikeys, klicke auf New API key, schränke ihn auf ein Projekt ein und kopiere das Token in den Secret deines CI-Runners. Der Build-Agent ruft POST /api/v1/sign auf.