Un daemon di firma del codice remoto self-hosted che incapsula il motore sgcSign dietro un'API REST, una console di amministrazione web Bootstrap e un client a riga di comando per pipeline CI/CD.
Un singolo host, Windows o Linux, accetta richieste di firma da agenti di build, sviluppatori e pipeline CI — con audit completo, approvazioni e metriche integrate.
Endpoint /api/v1 protetti da TLS per firma, verifica, salute, metriche e flussi di approvazione. Contratto stabile e machine-friendly per agenti di build e SDK.
UI Bootstrap su /admin per utenti, chiavi API, provider, progetti, audit, approvazioni, webhook e metriche. Gli operatori non devono mai modificare JSON.
Wizard Inno Setup o estrazione da zip. Il daemon si registra come servizio Windows, termina TLS direttamente e funziona senza supervisione su un host irrobustito.
Ogni progetto isola un sottoinsieme di provider, chiavi API, visibilità dell'audit e code di approvazione. Più team condividono un solo server senza vedere il materiale di firma reciproco.
La stessa chiave API richiede, un admin o un project admin approva o rifiuta, e solo allora i byte vengono firmati. Hash SHA-256 e dimensione del file sono fissati nella richiesta.
Ogni azione — firma, verifica, login, approvazione, webhook — viene aggiunta a un audit log con catena di hash. Le manomissioni sono rilevabili; lo scraping per SIEM è semplice.
Contatori firma / verifica / approvazione, istogrammi di latenza della firma, gauge di disponibilità dei provider. Esposizione testuale diretta in Prometheus 0.0.4 senza database aggiuntivi da gestire.
21 eventi del ciclo di vita consegnati con X-Sgcsign-Signature: sha256=…. Una coda di retry a tre tentativi mantiene SIEM, chat e sistemi di ticketing sincronizzati.
Lo stesso motore fornito nella libreria, esposto tramite API REST. Ogni profilo per paese, ogni livello di firma.
Firme XML per VeriFactu, FatturaPA, Facturae, KSeF, e-Factura, Peppol, myDATA e contratti di lavoro UE. POST /api/v1/sign/xades.
Firme PDF PAdES-Basic con aggiornamenti incrementali che preservano il contenuto originale. Firme visibili o invisibili. POST /api/v1/sign/pades.
Firme CMS / PKCS#7 detached o attached per dati binari arbitrari. Timestamp + validazione a lungo termine. POST /api/v1/sign/cades.
Costruisce e firma una vendita registrata con una chiave custodita dal server, facoltativamente la invia all'amministrazione fiscale e restituisce la risposta. Più casse di una catena condividono un unico certificato del contribuente. POST /api/v1/sign/eet.
Il daemon di firma comunica con la sorgente di certificati che configuri: archivio Windows, PFX, token hardware PKCS#11, Azure Trusted Signing, AWS KMS, Google KMS.
Firma .exe, .dll, .msi, .cab, .cat, .ocx, .sys. La modalità solo hash consente ai runner a bassa banda di scambiare poche dozzine di byte per un blob PKCS#7 di 8 KB. Aggiungi --page-hashes (page_hashes nell'API) per i page hash dei driver in modalità kernel, come signtool /ph.
Firma manifest ClickOnce (.application / .manifest) in modo che i client Windows possano installare senza prompt di trust. POST /api/v1/sign/clickonce.
Firma pacchetti .nupkg in modo che il client NuGet validi l'identità del publisher. Supporto a firme author e repository. POST /api/v1/sign/nuget.
Firma pacchetti di estensione Visual Studio in modo che VS Marketplace e l'IDE stesso li accettino come affidabili. POST /api/v1/sign/vsix.
Accesso più sicuro alla console di amministrazione e segreti cifrati su disco, così una password rubata o un file di configurazione copiato non aprono le chiavi di firma.
Gli account della console aggiungono un codice a 6 cifre generato da qualsiasi app di autenticazione TOTP, con 10 codici di recupero monouso in caso di smarrimento del telefono. Con admin.require_2fa ogni utente della console deve registrarsi prima di raggiungere qualsiasi altra pagina. Un amministratore può reimpostare un secondo fattore perso.
Accedi alla console con Microsoft Entra ID, Okta, Keycloak, Google o qualsiasi provider OpenID Connect standard, usando il flusso authorization code con PKCE. Gli utenti collegano un'identità esterna al proprio account e i nuovi utenti possono, se vogliono, richiedere un account che un amministratore approva.
Ogni risposta include header di sicurezza e una Content Security Policy rigorosa. Una policy delle password configurabile, password temporanee da sostituire al primo accesso e sessioni che terminano non appena cambiano il ruolo o i diritti che le sostengono.
Password dei provider, PIN, credenziali cloud e segreti dei webhook sono memorizzati cifrati con AES-256-GCM sotto una chiave master legata alla macchina (DPAPI su Windows). sgcSignServer --protect-secrets cifra sul posto una configurazione esistente.
Il server decide chi può firmare, con quale chiave e dopo l'approvazione di chi, e ogni firma riceve una marca temporale anche quando un server di timestamp non è disponibile.
Contrassegna un provider o un intero progetto come soggetto ad approvazione e il server rifiuta la firma diretta con approval_required. Ogni approvazione firma una sola volta. La regola vale su ogni percorso di firma, compresa la firma dell'hash grezzo per signtool /dlib.
Rigenera una chiave mentre il vecchio segreto continua a funzionare per un massimo di 7 giorni, modifica la scadenza, vedi chi ne è il proprietario e limitala a un elenco di provider consentiti. Con api_keys.self_service, gli operatori creano e gestiscono le proprie chiavi entro i limiti che imposti. Una chiave può anche iniziare la validità al primo utilizzo: è valida per N giorni a partire dalla prima chiamata autenticata, con una data obbligatoria di attivazione entro cui usarla, così una chiave mai usata non resta valida per sempre. Le sottochiavi funzionano solo dopo l'attivazione della chiave principale, l'attivazione viene registrata nel log di audit come apikey.activate e Community limita entrambi i valori a 30 giorni.
Il server conta i PIN errati per ogni token e smette di effettuare il login dopo max_pin_attempts, così un PIN sbagliato nella configurazione non blocca mai un token hardware. L'ultimo tentativo viene usato solo con allow_final_pin_try e un amministratore reimposta la protezione dalla console.
sgcsign config salva server, provider e altre impostazioni in profili con nome, e sgcsign auth set-key memorizza la chiave API, così gli script di build non devono più ripeterli. La CLI Delphi e lo strumento .NET esegece.sgcsign.cli condividono gli stessi file.
tsa_urls per singolo provider e no_timestamp per una richiesta che non deve ricevere la marca temporale.
sgcsign timestamp aggiunge una marca temporale a un file già firmato con Authenticode, con lo stesso fallback.
# sgcSignServer.conf.json
"timestamp": {
"servers": ["http://timestamp.digicert.com", "http://timestamp.sectigo.com"],
"timeout_ms": 30000
}
# Aggiungi la marca temporale a un file già firmato
sgcsign timestamp MyApp.exe --tsa http://timestamp.digicert.com --tsa http://timestamp.sectigo.comGestisci il server per anni senza sorprese: backup cifrati, avvisi prima della scadenza di un certificato, email quando serve l'intervento di una persona e un installer per Windows.
Un unico archivio contiene la configurazione, il database, la chiave master e ogni file di chiavi e certificati, cifrato con AES-256-GCM tramite una passphrase. Gli archivi vengono creati secondo una pianificazione o dalla console, e sgcSignServer --archive restore ricostruisce il server sulla stessa macchina o lo sposta su una nuova.
I certificati di firma e il certificato TLS del server vengono controllati all'avvio e ogni giorno. Gli avvisi a 30, 14, 7 e 1 giorno dalla scadenza compaiono nella dashboard e partono come webhook cert.expiring, come email e come metrica sgcsign_certificate_not_after_seconds.
Email quando un account viene bloccato, quando cambiano l'autenticazione a due fattori o una password, quando un backup fallisce o un certificato sta per scadere. SMTP con STARTTLS o TLS implicito e, su Windows, il mailer non richiede librerie OpenSSL.
sgcSignServer_Setup.exe installa il server come servizio Windows, crea il primo amministratore e apre la porta del firewall. TLS usa un certificato autofirmato generato, un file PFX esistente oppure HTTP semplice per le macchine di test.
Un singolo servizio Windows termina TLS, espone /api/v1 + /admin e raggiunge il provider di chiavi configurato a ogni chiamata. Il materiale delle chiavi non vive mai nel database.
/api/v1 su HTTPS con una chiave API bearer.
/admin da qualsiasi browser. UI Bootstrap, cookie di sessione, accesso basato sui ruoli.
+----------------------------+
| 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 AwayUna API key bearer, un upload di hash o di file e il binario firmato torna in streaming su stdout. Authenticode, CAdES, PAdES, XAdES, ClickOnce, NuGet, VSIX condividono la stessa struttura.
X-API-Key or Authorization: Bearer: funzionano entrambi i metodi di autenticazione.
X-Project seleziona il tenant; la chiave deve essere autorizzata per il progetto.
X-Sgcsign-Signer-Subject + X-Sgcsign-Duration-Ms per la correlazione dei log.
# 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: 312Da un host Windows nuovo al primo artefatto firmato in meno di cinque minuti.
Esegui la procedura guidata Inno Setup inclusa oppure copia lo zip in una cartella. Il daemon si registra come servizio Windows chiamato sgcSignServer. Associalo a :8443 e carica il tuo certificato TLS.
Aggiungi un provider a sgcSignServer.conf.json — un file PFX, un account Azure Trusted Signing, una chiave AWS KMS, un utente Certum SimplySign o uno qualsiasi degli altri dieci provider di chiavi. Non è necessario riavviare il servizio.
Apri /admin/apikeys, fai clic su New API key, limitala a un progetto e copia il token nel secret del tuo runner CI. L'agente di build chiama POST /api/v1/sign.