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 Windows-Host 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.
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 Multipart-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.