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.

API REST + admin web
7 formats de signature
Projets multi-locataires
Journal d'audit chaîné par hachage

Ce que tu obtiens

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.

API REST

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.

Console d'admin web

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.

Installateur service Windows

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.

Projets multi-locataires

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.

Workflow d'approbation à deux étapes

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.

Journal d'audit SHA-256

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.

Métriques Prometheus

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.

Webhooks signés HMAC

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.

XAdES · PAdES · CAdES

Le même moteur que celui livré dans la bibliothèque, exposé via l'API REST. Chaque profil par pays, chaque niveau de signature.

XAdES

Signatures XML pour VeriFactu, FatturaPA, Facturae, KSeF, e-Factura, Peppol, myDATA et les contrats de travail UE. POST /api/v1/sign/xades.

PAdES

Signatures PDF PAdES-Basic avec mises à jour incrémentales qui préservent le contenu original. Signatures visibles ou invisibles. POST /api/v1/sign/pades.

CAdES

Signatures CMS / PKCS#7 detached ou attached pour des données binaires arbitraires. Horodatage + validation à long terme. POST /api/v1/sign/cades.

EET 2.0 tchèque

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.

Authenticode, ClickOnce, NuGet, VSIX

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.

Authenticode

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.

ClickOnce

Signe les manifestes ClickOnce (.application / .manifest) pour que les clients Windows installent sans invites de confiance. POST /api/v1/sign/clickonce.

Paquets NuGet

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.

Extensions VSIX

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.

Sécurité et accès

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.

Connexion à deux facteurs

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.

Connexion OpenID Connect

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.

Durcissement de la console

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.

Secrets chiffrés au repos

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.

Contrôle de signature et horodatage

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.

Approbations imposées

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.

Cycle de vie des clés API

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.

Garde-fou des tentatives de PIN PKCS#11

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.

Profils enregistrés de la CLI

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.

Horodatage avec repli automatique

  • Une liste, à l'échelle du serveur, de serveurs d'horodatage RFC 3161 par défaut, essayés dans l'ordre jusqu'à ce que l'un réponde.
  • Des listes 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.
timestamps
# 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

Sauvegardes, supervision et installation

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.

Sauvegardes planifiées chiffrées

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.

Supervision de l'expiration des certificats

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.

Notifications par e-mail

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.

Installeur Windows

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.

Comment les pièces s'emboîtent

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.

Un seul binaire, trois interfaces

  • Les agents de build appellent /api/v1 via HTTPS avec une clé API bearer.
  • Les opérateurs se connectent à /admin dans n'importe quel navigateur. Interface Bootstrap, cookies de session, accès basé sur les rôles.
  • Les fournisseurs de clés sont récupérés à la demande depuis PFX, magasin Windows, PKCS#11, Azure TS, AWS KMS, GCloud KMS, Vault, Certum, CSC v2.
  • La base de données SQLite persiste les utilisateurs, clés API, journal d'audit, sessions, file webhook. Jamais le matériel de clé lui-même.
  • Les webhooks se déclenchent de manière asynchrone vers les systèmes SIEM et chat à chaque événement audité.
topology.txt
                +----------------------------+
                |   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)|
     +-------------+   +---------------+   +-----------+

À un curl de distance

Une 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.

Signer un .exe en un seul appel

  • 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.
  • La réponse porte X-Sgcsign-Signer-Subject + X-Sgcsign-Duration-Ms pour la corrélation des journaux.
  • Mode hash-only pour Authenticode : envoie le SHA-256, reçois un petit blob PKCS#7.
sign-binary.sh
# 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

Trois étapes vers un binaire signé

D'un hôte Windows vierge au premier artefact signé en moins de cinq minutes.

1

Installer

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.

2

Configurer un fournisseur de clés

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.

3

Émettre un token, appeler l'API

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.

Meilleur rapport qualité-prix : All-AccessTous les produits eSeGeCe, Support Premium inclus, à partir de €1,059/an.
Voir les tarifs All-Access

Centralise la signature sur ta build farm

Arrête de copier les certificats de signature sur chaque agent de build. Un sgcSign Server, un point de terminaison REST, audit complet et approbations.