Un daemon de signature de code distant auto-hébergé qui enveloppe le moteur sgcSign derrière une API REST, une console d'admin web Bootstrap et des pipelines CI/CD prêts à l'emploi.
Un seul hôte Windows accepte les requêtes de signature des agents de build, des développeurs et des pipelines CI — avec audit complet, approbations et métriques intégrés.
Points de terminaison /api/v1 sécurisés par TLS pour la signature, la vérification, la santé, les métriques et les workflows d'approbation. Contrat stable et machine-friendly pour les agents de build et les SDK.
Interface /admin basée sur Bootstrap pour les utilisateurs, clés API, fournisseurs, projets, audit, approbations, webhooks et métriques. Les opérateurs n'ont jamais besoin d'éditer du JSON.
Assistant Inno Setup ou dépôt de zip. Le daemon s'enregistre comme service Windows, termine TLS lui-même et fonctionne sans surveillance sur un hôte durci.
Chaque projet isole un sous-ensemble de fournisseurs, clés API, visibilité d'audit et files d'approbation. Plusieurs équipes partagent un seul serveur sans voir le matériel de signature des autres.
La même clé API demande, un administrateur ou un admin de projet approuve ou rejette, et seulement après les octets sont signés. Le hachage SHA-256 et la taille du fichier sont verrouillés dans la requête.
Chaque action — signer, vérifier, login, approbation, déclenchement de webhook — est ajoutée à un journal d'audit chaîné par hachage. La falsification est détectable ; le scraping SIEM est simple.
Compteurs de signature / vérification / approbation, histogrammes de latence de signature, jauges de disponibilité des fournisseurs. Exposition texte Prometheus 0.0.4 directe sans base de données supplémentaire à gérer.
13 événements de cycle de vie livrés avec X-Sgcsign-Signature: sha256=…. La file de réessai à trois tentatives garde les systèmes SIEM, chat et ticketing en synchro.
Le même moteur que celui livré dans la bibliothèque, exposé via l'API REST. Chaque profil par pays, chaque niveau de signature.
Signatures XML pour VeriFactu, FatturaPA, Facturae, KSeF, e-Factura, Peppol, myDATA et les contrats de travail UE. POST /api/v1/sign/xades.
Signatures PDF PAdES-Basic avec mises à jour incrémentales qui préservent le contenu original. Signatures visibles ou invisibles. POST /api/v1/sign/pades.
Signatures CMS / PKCS#7 detached ou attached pour des données binaires arbitraires. Horodatage + validation à long terme. POST /api/v1/sign/cades.
Le daemon de signature parle à n'importe quelle source de certificat que tu configures : magasin Windows, PFX, token matériel PKCS#11, Azure Trusted Signing, AWS KMS, Google KMS.
Signe les .exe, .dll, .msi, .cab, .cat, .ocx, .sys. Le mode hash-only permet aux runners à faible bande passante d'échanger quelques dizaines d'octets contre un blob PKCS#7 de 8 Ko.
Signe les manifestes ClickOnce (.application / .manifest) pour que les clients Windows installent sans invites de confiance. POST /api/v1/sign/clickonce.
Signe les paquets .nupkg pour que le client NuGet valide l'identité de l'éditeur. Signatures d'auteur et de dépôt prises en charge. POST /api/v1/sign/nuget.
Signe les paquets d'extension Visual Studio pour que VS Marketplace et l'IDE lui-même les acceptent comme de confiance. POST /api/v1/sign/vsix.
Les agents de build appellent un point de terminaison REST stable au lieu d'installer des certificats de signature sur chaque runner.
L'action composite publie l'artefact sur l'API REST du serveur. Le token émis par l'admin web, limité à un projet, ne quitte jamais le secret store du runner.
La tâche de pipeline exécute le client CLI sgcSign, qui charge le binaire, interroge pour approbation si nécessaire et télécharge le résultat signé — le tout en une seule étape.
Extrait de pipeline déclaratif qui utilise curl ou la CLI fournie. Fonctionne avec des agents Linux et Windows ; la signature apparaît comme artefact de build.
Image avec le daemon et un exemple de configuration de fournisseur. Exécute le conteneur, monte ton certificat TLS + les secrets du fournisseur, et tu as un service de signature portable.
Déploie sur Kubernetes pour une signature entièrement redondante et à grande échelle. Associe à un KMS cloud (Azure Trusted Signing, AWS KMS, Google KMS) pour des pods sans clé.
Un seul service Windows termine TLS, expose /api/v1 + /admin et contacte le fournisseur de clés configuré à chaque appel. Le matériel de clé ne réside jamais dans la base de données.
/api/v1 via HTTPS avec une clé API bearer.
/admin dans n'importe quel navigateur. Interface Bootstrap, cookies de session, accès basé sur les rôles.
+----------------------------+
| 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 de distanceUne clé API bearer, un upload multipart et le binaire signé est renvoyé en streaming vers stdout. Authenticode, CAdES, PAdES, XAdES, ClickOnce, NuGet, VSIX partagent la même forme.
X-API-Key ou Authorization: Bearer — les deux méthodes d'auth fonctionnent.
X-Project sélectionne le locataire ; la clé doit être autorisée pour le projet.
X-Sgcsign-Signer-Subject + X-Sgcsign-Duration-Ms pour la corrélation des journaux.
# Signe Authenticode MyApp.exe via l'API REST
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
# En-têtes renvoyés par le serveur
# X-Sgcsign-Signer-Subject: CN=ACME Corp, O=ACME, C=US
# X-Sgcsign-Duration-Ms: 312D'un hôte Windows vierge au premier artefact signé en moins de cinq minutes.
Exécute l'assistant Inno Setup fourni ou dépose le zip dans un dossier. Le daemon s'enregistre comme service Windows appelé sgcSignServer. Lie-toi à :8443 et charge ton certificat TLS.
Ajoute un fournisseur à sgcSignServer.conf.json — un fichier PFX, un compte Azure Trusted Signing, une clé AWS KMS, un utilisateur Certum SimplySign ou n'importe lequel des dix autres fournisseurs de clés. Aucun redémarrage de service requis.
Ouvre /admin/apikeys, clique sur Nouvelle clé API, limite-la à un projet, copie le token dans le secret de ton runner CI. L'agent de build appelle POST /api/v1/sign.