sgcSign Server
Un daemon de firma de código remoto autoalojado que envuelve el motor de sgcSign tras una API REST, una consola de administración web Bootstrap y pipelines CI/CD listos para usar.
Un daemon de firma de código remoto autoalojado que envuelve el motor de sgcSign tras una API REST, una consola de administración web Bootstrap y pipelines CI/CD listos para usar.
Un único host Windows acepta solicitudes de firma de agentes de build, desarrolladores y pipelines CI — con auditoría completa, aprobaciones y métricas integradas.
Endpoints /api/v1 protegidos con TLS para firma, verificación, comprobación de estado, métricas y flujos de aprobación. Contrato estable y orientado a máquinas para agentes de build y SDK.
Interfaz /admin basada en Bootstrap para usuarios, claves API, proveedores, proyectos, auditoría, aprobaciones, webhooks y métricas. Los operadores nunca necesitan editar JSON.
Asistente Inno Setup o despliegue por ZIP. El daemon se registra como servicio Windows, termina TLS por sí mismo y se ejecuta sin atención en un host endurecido.
Cada proyecto aísla un subconjunto de proveedores, claves API, visibilidad de auditoría y colas de aprobación. Varios equipos comparten un único servidor sin ver el material de firma del otro.
La misma clave API solicita, un administrador o admin de proyecto aprueba o rechaza, y solo entonces se firman los bytes. El hash SHA-256 y el tamaño del archivo se bloquean en la solicitud.
Cada acción — firma, verificación, inicio de sesión, aprobación, disparo de webhook — se añade a un registro de auditoría encadenado por hash. La manipulación es detectable; el scraping desde un SIEM es directo.
Contadores de firma / verificación / aprobación, histogramas de latencia de firma, indicadores de disponibilidad de proveedores. Exposición directa en formato texto Prometheus 0.0.4, sin base de datos adicional que gestionar.
13 eventos de ciclo de vida entregados con X-Sgcsign-Signature: sha256=…. La cola de reintentos en tres pasos mantiene sincronizados los sistemas SIEM, de chat y de tickets.
El mismo motor que se distribuye en la biblioteca, expuesto a través de la API REST. Cada perfil por país, cada nivel de firma.
Firmas XML para VeriFactu, FatturaPA, Facturae, KSeF, e-Factura, Peppol, myDATA y contratos laborales de la UE. POST /api/v1/sign/xades.
Firmas PDF PAdES-Basic con actualizaciones incrementales que conservan el contenido original. Firmas visibles o invisibles. POST /api/v1/sign/pades.
Firmas CMS / PKCS#7 detached o attached para datos binarios arbitrarios. Sello de tiempo + validación a largo plazo. POST /api/v1/sign/cades.
El daemon de firma habla con la fuente de certificados que configures: almacén de Windows, PFX, token hardware PKCS#11, Azure Trusted Signing, AWS KMS o Google KMS.
Firma .exe, .dll, .msi, .cab, .cat, .ocx, .sys. El modo solo-hash permite que los runners con poco ancho de banda intercambien unas pocas decenas de bytes a cambio de un blob PKCS#7 de 8 KB.
Firma manifiestos ClickOnce (.application / .manifest) para que los clientes Windows instalen sin avisos de confianza. POST /api/v1/sign/clickonce.
Firma paquetes .nupkg para que el cliente NuGet valide la identidad del editor. Compatible con firmas de autor y de repositorio. POST /api/v1/sign/nuget.
Firma paquetes de extensión de Visual Studio para que el VS Marketplace y el propio IDE los acepten como confiables. POST /api/v1/sign/vsix.
Los agentes de build llaman a un endpoint REST estable en lugar de instalar certificados de firma en cada runner.
Una acción compuesta publica el artefacto en la API REST del servidor. El token emitido por el panel web, limitado a un proyecto, no sale del almacén de secretos del runner.
La tarea de pipeline ejecuta la CLI cliente de sgcSign, que sube el binario, sondea la aprobación si es necesaria y descarga el resultado firmado — todo en un solo paso.
Fragmento de pipeline declarativo usando curl o la CLI incluida. Funciona con agentes Linux y Windows; la firma aparece como artefacto de build.
Imagen con el daemon y una configuración de proveedor de ejemplo. Ejecuta el contenedor, monta tu cert TLS y los secretos del proveedor y tendrás un servicio de firma portable.
Despliega en Kubernetes para una firma totalmente redundante y escalada. Combínalo con un KMS en la nube (Azure Trusted Signing, AWS KMS, Google KMS) para tener pods sin claves locales.
Un único servicio Windows termina TLS, expone /api/v1 + /admin y consulta el proveedor de claves configurado en cada llamada. El material de claves nunca vive en la base de datos.
/api/v1 sobre HTTPS con una clave API tipo bearer.
/admin desde cualquier navegador. Interfaz Bootstrap, cookies de sesión y control de acceso basado en roles.
+----------------------------+
| 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 distanciaUna clave API tipo bearer, una subida multipart y el binario firmado vuelve por stdout. Authenticode, CAdES, PAdES, XAdES, ClickOnce, NuGet y VSIX comparten la misma forma.
X-API-Key o Authorization: Bearer — cualquiera de los dos métodos de auth funciona.
X-Project selecciona el tenant; la clave debe estar autorizada para el proyecto.
X-Sgcsign-Signer-Subject + X-Sgcsign-Duration-Ms para correlacionar logs.
# 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: 312
De un host Windows recién instalado al primer artefacto firmado en menos de cinco minutos.
Ejecuta el asistente Inno Setup incluido o copia el ZIP en una carpeta. El daemon se registra como servicio Windows con el nombre sgcSignServer. Lo asocias al puerto :8443 y cargas tu certificado TLS.
Añade un proveedor a sgcSignServer.conf.json — un archivo PFX, una cuenta Azure Trusted Signing, una clave AWS KMS, un usuario Certum SimplySign o cualquiera de los otros diez proveedores de claves. No se requiere reiniciar el servicio.
Abre /admin/apikeys, haz clic en Nueva clave API, limítala a un proyecto y copia el token en el almacén de secretos de tu runner CI. El agente de build llama a POST /api/v1/sign.