Ein selbst gehosteter Daemon für Remote-Code-Signing, der die sgcSign-Engine hinter einer REST-API, einer Bootstrap-Web-Admin-Konsole und einem Kommandozeilen-Client für 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.
21 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. Mit --page-hashes (page_hashes in der API) fügst du Seiten-Hashes für Kernelmodus-Treiber hinzu, wie signtool /ph.
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.
Stärkere Anmeldung an der Admin-Konsole und verschlüsselte Geheimnisse auf dem Datenträger, damit ein gestohlenes Passwort oder eine kopierte Konfigurationsdatei die Signierschlüssel nicht öffnet.
Konsolenkonten ergänzen einen 6-stelligen Code aus einer beliebigen TOTP-Authenticator-App, dazu 10 einmalig verwendbare Wiederherstellungscodes für ein verlorenes Telefon. Mit admin.require_2fa muss sich jeder Konsolenbenutzer einrichten, bevor er eine andere Seite erreicht. Ein Administrator kann einen verlorenen zweiten Faktor zurücksetzen.
Melde dich an der Konsole mit Microsoft Entra ID, Okta, Keycloak, Google oder einem beliebigen Standard-OpenID-Connect-Anbieter an, per Authorization-Code-Flow mit PKCE. Benutzer verknüpfen eine externe Identität mit ihrem Konto, und neue Benutzer können optional ein Konto beantragen, das ein Administrator freigibt.
Jede Antwort enthält Sicherheits-Header und eine strikte Content Security Policy. Dazu kommen eine konfigurierbare Passwortrichtlinie, temporäre Passwörter, die bei der ersten Anmeldung ersetzt werden müssen, und Sitzungen, die enden, sobald sich die Rolle oder die Rechte dahinter ändern.
Provider-Passwörter, PINs, Cloud-Zugangsdaten und Webhook-Geheimnisse werden mit AES-256-GCM verschlüsselt gespeichert, unter einem an den Rechner gebundenen Hauptschlüssel (DPAPI unter Windows). sgcSignServer --protect-secrets verschlüsselt eine vorhandene Konfiguration an Ort und Stelle.
Der Server entscheidet, wer mit welchem Schlüssel und nach wessen Freigabe signieren darf, und jede Signatur erhält einen Zeitstempel, auch wenn ein Zeitstempelserver ausfällt.
Markiere einen Provider oder ein ganzes Projekt als freigabepflichtig, und der Server lehnt direktes Signieren mit approval_required ab. Jede Freigabe signiert nur einmal. Die Regel gilt auf jedem Signierpfad, einschließlich der Roh-Digest-Signierung für signtool /dlib.
Erzeuge einen Schlüssel neu, während das alte Geheimnis noch bis zu 7 Tage weiter funktioniert, bearbeite sein Ablaufdatum, sieh, wem er gehört, und beschränke ihn auf eine Liste erlaubter Provider. Mit api_keys.self_service erstellen und verwalten Operatoren ihre eigenen Schlüssel innerhalb der von dir gesetzten Grenzen. Ein Schlüssel kann seine Gültigkeit auch erst bei der ersten Verwendung beginnen: Er gilt N Tage ab seinem ersten authentifizierten Aufruf, mit einem erforderlichen Datum „aktivieren bis“, damit ein unbenutzter Schlüssel nie unbegrenzt gültig bleibt. Unterschlüssel funktionieren erst, wenn ihr übergeordneter Schlüssel aktiviert ist, die Aktivierung wird im Auditprotokoll als apikey.activate erfasst, und Community begrenzt beide Werte auf 30 Tage.
Der Server zählt falsche PIN-Ergebnisse pro Token und meldet sich nach max_pin_attempts nicht mehr an, sodass eine falsche PIN in der Konfiguration nie ein Hardware-Token sperrt. Der letzte Versuch wird nur mit allow_final_pin_try genutzt, und ein Administrator setzt den Schutz über die Konsole zurück.
sgcsign config speichert Server, Provider und weitere Einstellungen in benannten Profilen, und sgcsign auth set-key hinterlegt den API-Key, sodass Build-Skripte sie nicht mehr wiederholen müssen. Die Delphi-CLI und das .NET-Tool esegece.sgcsign.cli teilen sich dieselben Dateien.
tsa_urls-Listen pro Provider und no_timestamp für eine Anfrage, die keinen Zeitstempel erhalten darf.
sgcsign timestamp fügt einer bereits per Authenticode signierten Datei einen Zeitstempel hinzu, mit demselben Fallback.
# sgcSignServer.conf.json
"timestamp": {
"servers": ["http://timestamp.digicert.com", "http://timestamp.sectigo.com"],
"timeout_ms": 30000
}
# Zeitstempel für eine bereits signierte Datei
sgcsign timestamp MyApp.exe --tsa http://timestamp.digicert.com --tsa http://timestamp.sectigo.comBetreibe den Server jahrelang ohne Überraschungen: verschlüsselte Backups, Warnungen vor dem Ablauf eines Zertifikats, E-Mail, wenn ein Mensch eingreifen muss, und ein Windows-Installer.
Ein Archiv enthält die Konfiguration, die Datenbank, den Hauptschlüssel sowie jede Schlüssel- und Zertifikatsdatei, verschlüsselt mit AES-256-GCM unter einer Passphrase. Archive entstehen nach Zeitplan oder über die Konsole, und sgcSignServer --archive restore stellt den Server auf demselben Rechner wieder her oder zieht ihn auf einen neuen um.
Die Signaturzertifikate und das TLS-Zertifikat des Servers werden beim Start und täglich geprüft. Warnungen bei noch 30, 14, 7 und 1 Tagen erscheinen im Dashboard und gehen als cert.expiring-Webhook, als E-Mail und als Metrik sgcsign_certificate_not_after_seconds hinaus.
E-Mail, wenn ein Konto gesperrt wird, wenn sich die Zwei-Faktor-Authentifizierung oder ein Passwort ändert, wenn ein Backup fehlschlägt oder ein Zertifikat bald abläuft. SMTP mit STARTTLS oder implizitem TLS, und unter Windows benötigt der Mailer keine OpenSSL-Bibliotheken.
sgcSignServer_Setup.exe installiert den Server als Windows-Dienst, legt den ersten Administrator an und öffnet den Firewall-Port. TLS nutzt ein erzeugtes selbstsigniertes Zertifikat, eine vorhandene PFX-Datei oder reines HTTP für Testrechner.
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.