Serveur sgcSign
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 un client en ligne de commande pour les pipelines CI/CD.
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 un client en ligne de commande pour les pipelines CI/CD.
Un seul hôte, Windows ou Linux, 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.
21 é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.
Construit et signe une vente enregistrée avec une clé détenue par le serveur, peut l'envoyer à l'administration fiscale et renvoie la réponse. Une chaîne de caisses partage un seul certificat de contribuable. POST /api/v1/sign/eet.
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. Ajoutez --page-hashes (page_hashes dans l'API) pour inclure les hachages de page des pilotes en mode noyau, comme signtool /ph.
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.
Une connexion renforcée à la console d'admin et des secrets chiffrés sur disque, pour qu'un mot de passe volé ou un fichier de configuration copié n'ouvre pas les clés de signature.
Les comptes de la console ajoutent un code à 6 chiffres issu de n'importe quelle application d'authentification TOTP, avec 10 codes de récupération à usage unique en cas de perte du téléphone. Active admin.require_2fa et chaque utilisateur de la console doit s'enrôler avant d'accéder à une autre page. Un administrateur peut réinitialiser un second facteur perdu.
Connecte-toi à la console avec Microsoft Entra ID, Okta, Keycloak, Google ou n'importe quel fournisseur OpenID Connect standard, avec le flux de code d'autorisation et PKCE. Les utilisateurs associent une identité externe à leur compte, et les nouveaux utilisateurs peuvent en option demander un compte qu'un administrateur approuve.
Chaque réponse porte des en-têtes de sécurité et une Content Security Policy stricte. Une politique de mots de passe configurable, des mots de passe temporaires à remplacer dès la première connexion, et des sessions qui se terminent dès que le rôle ou les droits qui les sous-tendent changent.
Les mots de passe des fournisseurs, les PIN, les identifiants cloud et les secrets de webhook sont stockés chiffrés avec AES-256-GCM sous une clé maître liée à la machine (DPAPI sous Windows). sgcSignServer --protect-secrets chiffre une configuration existante sur place.
Le serveur décide qui peut signer, avec quelle clé et après l'approbation de qui, et chaque signature reçoit un horodatage même lorsqu'un serveur d'horodatage est en panne.
Marque un fournisseur ou un projet entier comme nécessitant une approbation, et le serveur refuse la signature directe avec approval_required. Chaque approbation ne signe qu'une fois. La règle s'applique à tous les chemins de signature, y compris la signature de condensat brut pour signtool /dlib.
Régénère une clé pendant que l'ancien secret continue de fonctionner jusqu'à 7 jours, modifie son expiration, vois qui en est propriétaire et limite-la à une liste de fournisseurs autorisés. Avec api_keys.self_service, les opérateurs créent et gèrent leurs propres clés dans les limites que tu fixes. Une clé peut aussi commencer sa validité à la première utilisation : elle est valide N jours à compter de son premier appel authentifié, avec une date obligatoire « à activer avant » pour qu'une clé jamais utilisée ne reste pas valide indéfiniment. Les sous-clés ne fonctionnent qu'une fois leur clé parente activée, l'activation est consignée dans le journal d'audit sous apikey.activate, et l'édition Community limite les deux valeurs à 30 jours.
Le serveur compte les résultats de PIN incorrect par token et cesse de se connecter après max_pin_attempts, si bien qu'un mauvais PIN dans la configuration ne verrouille jamais un token matériel. Le dernier essai n'est utilisé qu'avec allow_final_pin_try, et un administrateur réinitialise le garde-fou depuis la console.
sgcsign config enregistre le serveur, le fournisseur et les autres réglages dans des profils nommés, et sgcsign auth set-key stocke la clé API, pour que les scripts de build cessent de les répéter. La CLI Delphi et l'outil .NET esegece.sgcsign.cli partagent les mêmes fichiers.
tsa_urls par fournisseur, et no_timestamp pour une requête qui ne doit pas être horodatée.
sgcsign timestamp ajoute un horodatage à un fichier déjà signé Authenticode, avec le même repli.
# sgcSignServer.conf.json
"timestamp": {
"servers": ["http://timestamp.digicert.com", "http://timestamp.sectigo.com"],
"timeout_ms": 30000
}
# Horodater un fichier déjà signé
sgcsign timestamp MyApp.exe --tsa http://timestamp.digicert.com --tsa http://timestamp.sectigo.com
Fais tourner le serveur pendant des années sans surprise : sauvegardes chiffrées, alertes avant l'expiration d'un certificat, e-mail quand quelque chose demande une intervention humaine, et un installeur Windows.
Une seule archive contient la configuration, la base de données, la clé maître et chaque fichier de clé et de certificat, chiffrée avec AES-256-GCM sous une phrase secrète. Les archives se lancent selon un calendrier ou depuis la console, et sgcSignServer --archive restore reconstruit le serveur sur la même machine ou le déplace vers une nouvelle.
Les certificats de signature et le certificat TLS du serveur sont vérifiés au démarrage et chaque jour. Les alertes à 30, 14, 7 et 1 jours restants s'affichent sur le tableau de bord et partent sous forme de webhook cert.expiring, d'e-mail et de métrique sgcsign_certificate_not_after_seconds.
Un e-mail quand un compte est verrouillé, quand l'authentification à deux facteurs ou un mot de passe change, quand une sauvegarde échoue ou qu'un certificat est sur le point d'expirer. SMTP avec STARTTLS ou TLS implicite, et sous Windows l'expéditeur n'a besoin d'aucune bibliothèque OpenSSL.
sgcSignServer_Setup.exe installe le serveur comme service Windows, crée le premier administrateur et ouvre le port du pare-feu. TLS utilise un certificat auto-signé généré, un fichier PFX existant, ou du HTTP simple pour les machines de test.
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 de hash ou de fichier 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: 312
D'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.