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 un cliente de línea de comandos para pipelines CI/CD.
Un único host, Windows o Linux, 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.
21 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.
Construye y firma una venta registrada con una clave que custodia el servidor, opcionalmente la envía a la autoridad tributaria y devuelve la respuesta. Todas las cajas de una cadena comparten un mismo certificado de contribuyente. POST /api/v1/sign/eet.
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. Añade --page-hashes (page_hashes en la API) para incluir hashes de página en controladores en modo kernel, como signtool /ph.
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.
Inicio de sesión más robusto para la consola de administración y secretos cifrados en disco, de modo que una contraseña robada o un archivo de configuración copiado no abran las claves de firma.
Las cuentas de la consola añaden un código de 6 dígitos de cualquier aplicación autenticadora TOTP, con 10 códigos de recuperación de un solo uso por si se pierde el teléfono. Con admin.require_2fa, todos los usuarios de la consola deben registrarse antes de acceder a cualquier otra página. Un administrador puede restablecer un segundo factor perdido.
Accede a la consola con Microsoft Entra ID, Okta, Keycloak, Google o cualquier proveedor OpenID Connect estándar, mediante el flujo de código de autorización con PKCE. Los usuarios vinculan una identidad externa a su cuenta, y los nuevos usuarios pueden solicitar opcionalmente una cuenta que aprueba un administrador.
Cada respuesta incluye cabeceras de seguridad y una Content Security Policy estricta. Política de contraseñas configurable, contraseñas temporales que deben cambiarse en el primer inicio de sesión y sesiones que terminan en cuanto cambia el rol o los permisos que las respaldan.
Las contraseñas de proveedores, los PIN, las credenciales de la nube y los secretos de webhooks se guardan cifrados con AES-256-GCM bajo una clave maestra ligada a la máquina (DPAPI en Windows). sgcSignServer --protect-secrets cifra en su sitio una configuración existente.
El servidor decide quién puede firmar, con qué clave y con la aprobación de quién, y cada firma recibe un sello de tiempo incluso cuando un servidor de sellos de tiempo está caído.
Marca un proveedor o un proyecto completo como que requiere aprobación, y el servidor rechaza la firma directa con approval_required. Cada aprobación firma una sola vez. La regla se aplica en todas las rutas de firma, incluida la firma de hash en bruto para signtool /dlib.
Regenera una clave mientras el secreto anterior sigue funcionando hasta 7 días, edita su caducidad, consulta quién es su propietario y limítala a una lista de proveedores permitidos. Con api_keys.self_service, los operadores crean y gestionan sus propias claves dentro de los límites que definas. Una clave también puede empezar su validez en el primer uso: es válida durante N días contados desde su primera llamada autenticada, con una fecha obligatoria de activar antes de, para que una clave sin usar nunca siga válida para siempre. Las subclaves solo funcionan cuando su clave principal está activada, la activación queda registrada en el registro de auditoría como apikey.activate y Community limita ambos valores a 30 días.
El servidor cuenta los resultados de PIN incorrecto por token y deja de iniciar sesión tras max_pin_attempts, de modo que un PIN erróneo en la configuración nunca bloquea un token de hardware. El último intento solo se usa con allow_final_pin_try, y un administrador restablece la protección desde la consola.
sgcsign config guarda el servidor, el proveedor y otros ajustes en perfiles con nombre, y sgcsign auth set-key almacena la clave API, de modo que los scripts de compilación dejan de repetirlos. La CLI de Delphi y la herramienta .NET esegece.sgcsign.cli comparten los mismos archivos.
tsa_urls por proveedor, y no_timestamp para una solicitud que no debe llevar sello de tiempo.
sgcsign timestamp añade un sello de tiempo a un archivo ya firmado con Authenticode, con el mismo respaldo.
# sgcSignServer.conf.json
"timestamp": {
"servers": ["http://timestamp.digicert.com", "http://timestamp.sectigo.com"],
"timeout_ms": 30000
}
# Añadir sello de tiempo a un archivo ya firmado
sgcsign timestamp MyApp.exe --tsa http://timestamp.digicert.com --tsa http://timestamp.sectigo.comMantén el servidor en marcha durante años sin sorpresas: copias cifradas, avisos antes de que caduque un certificado, correo cuando algo requiere a una persona y un instalador para Windows.
Un único archivo contiene la configuración, la base de datos, la clave maestra y todos los archivos de claves y certificados, cifrado con AES-256-GCM bajo una frase de contraseña. Las copias se ejecutan según una programación o desde la consola, y sgcSignServer --archive restore reconstruye el servidor en la misma máquina o lo traslada a una nueva.
Los certificados de firma y el certificado TLS del servidor se comprueban al arrancar y cada día. Los avisos a los 30, 14, 7 y 1 días restantes aparecen en el panel y salen como webhook cert.expiring, como correo y como métrica sgcsign_certificate_not_after_seconds.
Correo cuando se bloquea una cuenta, cuando cambia la autenticación en dos pasos o una contraseña, cuando falla una copia de seguridad o un certificado está a punto de caducar. SMTP con STARTTLS o TLS implícito, y en Windows el envío de correo no necesita bibliotecas OpenSSL.
sgcSignServer_Setup.exe instala el servidor como servicio de Windows, crea el primer administrador y abre el puerto del cortafuegos. TLS usa un certificado autofirmado generado, un archivo PFX existente o HTTP sin cifrar para máquinas de prueba.
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 de hash o de archivo 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: 312De 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.