Servidor sgcSign

Um daemon de assinatura de código remota auto-hospedado que encapsula o motor sgcSign por trás de uma REST API, um console de admin web Bootstrap e um cliente de linha de comando para pipelines CI/CD.

REST API + Admin web
7 formatos de assinatura
Projetos multi-tenant
Log de auditoria com hash encadeado

O que você recebe

Um único host, Windows ou Linux, aceita solicitações de assinatura de agentes de build, desenvolvedores e pipelines CI — com auditoria completa, aprovações e métricas integradas.

REST API

Endpoints /api/v1 protegidos por TLS para assinatura, verificação, saúde, métricas e fluxos de aprovação. Contrato estável e amigável para agentes de build e SDKs.

Web Admin Console

Interface /admin baseada em Bootstrap para usuários, chaves de API, provedores, projetos, auditoria, aprovações, webhooks e métricas. Operadores nunca precisam editar JSON.

Windows-service Installer

Assistente Inno Setup ou extração de zip. O daemon se registra como um serviço Windows, encerra o TLS por conta própria e roda sem supervisão em um host protegido.

Projetos multi-tenant

Cada projeto isola um subconjunto de provedores, chaves de API, visibilidade de auditoria e filas de aprovação. Várias equipes compartilham um servidor sem ver o material de assinatura umas das outras.

Fluxo de Aprovação em Duas Etapas

A mesma chave de API faz a requisição, um administrador ou admin de projeto aprova ou rejeita, e somente então os bytes são assinados. O hash SHA-256 e o tamanho do arquivo ficam vinculados à requisição.

Log de Auditoria SHA-256

Toda ação — assinar, verificar, login, aprovação, disparo de webhook — é acrescentada a um log de auditoria com hash encadeado. Adulterações são detectáveis; a integração com SIEM é simples.

Métricas Prometheus

Contadores de assinatura/verificação/aprovação, histogramas de latência de assinatura, indicadores de disponibilidade de provedores. Exposição direta no formato texto Prometheus 0.0.4 sem banco de dados adicional.

Webhooks Assinados com HMAC

21 eventos de ciclo de vida entregues com X-Sgcsign-Signature: sha256=…. Fila de reenvio com três tentativas mantém SIEM, chat e sistemas de tickets sincronizados.

XAdES · PAdES · CAdES

O mesmo motor que acompanha a biblioteca, exposto pela REST API. Todos os perfis por país, todos os níveis de assinatura.

XAdES

Assinaturas XML para VeriFactu, FatturaPA, Facturae, KSeF, e-Factura, Peppol, myDATA e contratos de trabalho da UE. POST /api/v1/sign/xades.

PAdES

Assinaturas PDF PAdES-Basic com atualizações incrementais que preservam o conteúdo original. Assinaturas visíveis ou invisíveis. POST /api/v1/sign/pades.

CAdES

Assinaturas CMS / PKCS#7 destacadas ou incorporadas para dados binários arbitrários. Carimbo de tempo + validação de longo prazo. POST /api/v1/sign/cades.

EET 2.0 tcheco

Monta e assina uma venda registrada com uma chave mantida pelo servidor, opcionalmente a envia à autoridade fiscal e retorna a resposta. Uma rede de pontos de venda compartilha um único certificado do contribuinte. POST /api/v1/sign/eet.

Authenticode, ClickOnce, NuGet, VSIX

O daemon de assinatura se comunica com qualquer fonte de certificado que você configurar: repositório Windows, PFX, token de hardware PKCS#11, Azure Trusted Signing, AWS KMS, Google KMS.

Authenticode

Assina .exe, .dll, .msi, .cab, .cat, .ocx, .sys. O modo somente-hash permite que runners com pouca largura de banda troquem algumas dezenas de bytes por um blob PKCS#7 de 8 KB. Adicione --page-hashes (page_hashes na API) para incluir page hashes em drivers em modo kernel, como signtool /ph.

ClickOnce

Assina manifestos ClickOnce (.application / .manifest) para que clientes Windows instalem sem alertas de confiança. POST /api/v1/sign/clickonce.

NuGet Packages

Assina pacotes .nupkg para que o cliente NuGet valide a identidade do publicador. Assinaturas de autor e de repositório são suportadas. POST /api/v1/sign/nuget.

VSIX Extensions

Assina pacotes de extensão do Visual Studio para que o VS Marketplace e o próprio IDE os aceitem como confiáveis. POST /api/v1/sign/vsix.

Segurança e acesso

Login mais forte no console de administração e segredos criptografados em disco, de modo que uma senha roubada ou um arquivo de configuração copiado não abra as chaves de assinatura.

Login em dois fatores

As contas do console passam a usar um código de 6 dígitos de qualquer aplicativo autenticador TOTP, com 10 códigos de recuperação de uso único para o caso de perda do celular. Defina admin.require_2fa e todo usuário do console deverá se cadastrar antes de acessar qualquer outra página. Um administrador pode redefinir um segundo fator perdido.

Login com OpenID Connect

Entre no console com Microsoft Entra ID, Okta, Keycloak, Google ou qualquer provedor OpenID Connect padrão, usando o fluxo de código de autorização com PKCE. Os usuários vinculam uma identidade externa à sua conta, e novos usuários podem, opcionalmente, solicitar uma conta que um administrador aprova.

Console reforçado

Toda resposta traz cabeçalhos de segurança e uma Content Security Policy rigorosa. Há uma política de senhas configurável, senhas temporárias que precisam ser trocadas no primeiro login e sessões que terminam assim que o perfil ou os direitos por trás delas mudam.

Segredos criptografados em repouso

Senhas de provedores, PINs, credenciais de nuvem e segredos de webhooks são armazenados criptografados com AES-256-GCM sob uma chave mestra vinculada à máquina (DPAPI no Windows). sgcSignServer --protect-secrets criptografa uma configuração existente no próprio local.

Controle de assinatura e carimbos de tempo

O servidor decide quem pode assinar, com qual chave e após a aprovação de quem, e toda assinatura recebe um carimbo de tempo mesmo quando um servidor de carimbo de tempo está fora do ar.

Aprovações obrigatórias

Marque um provedor ou um projeto inteiro como sujeito a aprovação, e o servidor recusa a assinatura direta com approval_required. Cada aprovação assina uma única vez. A regra vale em todos os caminhos de assinatura, inclusive a assinatura de digest bruto para o signtool /dlib.

Ciclo de vida das chaves de API

Regenere uma chave enquanto o segredo antigo continua funcionando por até 7 dias, edite sua validade, veja quem é o proprietário e limite-a a uma lista de provedores permitidos. Com api_keys.self_service, os operadores criam e gerenciam as próprias chaves dentro dos limites definidos por você. Uma chave também pode começar a valer no primeiro uso: ela é válida por N dias contados a partir da primeira chamada autenticada, com uma data obrigatória de ativar antes de, para que uma chave nunca usada não fique válida para sempre. As subchaves só funcionam depois que a chave principal é ativada, a ativação é registrada no log de auditoria como apikey.activate e a edição Community limita os dois valores a 30 dias.

Proteção contra tentativas de PIN PKCS#11

O servidor conta os resultados de PIN incorreto por token e deixa de fazer login após max_pin_attempts, de modo que um PIN errado na configuração nunca bloqueie um token de hardware. A última tentativa só é usada com allow_final_pin_try, e um administrador redefine a proteção pelo console.

Perfis salvos da CLI

sgcsign config salva o servidor, o provedor e outras configurações em perfis nomeados, e sgcsign auth set-key guarda a chave de API, para que os scripts de build deixem de repeti-los. A CLI Delphi e a ferramenta .NET esegece.sgcsign.cli compartilham os mesmos arquivos.

Carimbos de tempo com fallback automático

  • Uma lista, válida para todo o servidor, de servidores de carimbo de tempo RFC 3161 padrão, testados em ordem até que um responda.
  • Listas tsa_urls por provedor, e no_timestamp para uma requisição que não deve receber carimbo de tempo.
  • sgcsign timestamp adiciona um carimbo de tempo a um arquivo que já está assinado com Authenticode, com o mesmo fallback.
timestamps
# sgcSignServer.conf.json
"timestamp": {
  "servers": ["http://timestamp.digicert.com", "http://timestamp.sectigo.com"],
  "timeout_ms": 30000
}

# Carimbo de tempo em um arquivo que já está assinado
sgcsign timestamp MyApp.exe --tsa http://timestamp.digicert.com --tsa http://timestamp.sectigo.com

Backups, monitoramento e instalação

Mantenha o servidor em operação por anos sem surpresas: backups criptografados, avisos antes de um certificado expirar, e-mail quando algo exige uma pessoa e um instalador para Windows.

Backups agendados e criptografados

Um único arquivo guarda a configuração, o banco de dados, a chave mestra e todos os arquivos de chave e certificado, criptografado com AES-256-GCM sob uma senha. Os arquivos são gerados em um agendamento ou pelo console, e sgcSignServer --archive restore reconstrói o servidor na mesma máquina ou o move para uma nova.

Monitoramento de expiração de certificados

Os certificados de assinatura e o certificado TLS do servidor são verificados na inicialização e todos os dias. Avisos com 30, 14, 7 e 1 dia restantes aparecem no painel e saem como o webhook cert.expiring, um e-mail e a métrica sgcsign_certificate_not_after_seconds.

Notificações por e-mail

E-mail quando uma conta é bloqueada, quando a autenticação em dois fatores ou uma senha muda, quando um backup falha ou um certificado está prestes a expirar. SMTP com STARTTLS ou TLS implícito, e no Windows o envio de e-mail não precisa de bibliotecas OpenSSL.

Instalador para Windows

sgcSignServer_Setup.exe instala o servidor como serviço do Windows, cria o primeiro administrador e abre a porta no firewall. O TLS usa um certificado autoassinado gerado, um arquivo PFX existente ou HTTP simples em máquinas de teste.

Como as Peças se Encaixam

Um único serviço Windows encerra o TLS, expõe /api/v1 + /admin e acessa o provedor de chaves configurado em cada chamada. O material de chave nunca fica armazenado no banco de dados.

Um único binário, três interfaces

  • Agentes de build acessam /api/v1 via HTTPS com uma chave de API bearer.
  • Operadores fazem login em /admin em qualquer navegador. Interface Bootstrap, cookies de sessão, acesso baseado em papéis.
  • Provedores de chave buscados sob demanda em PFX, repositório Windows, PKCS#11, Azure TS, AWS KMS, GCloud KMS, Vault, Certum, CSC v2.
  • Banco de dados SQLite persiste usuários, chaves de API, log de auditoria, sessões e fila de webhooks. Nunca o material de chave em si.
  • Webhooks são disparados de forma assíncrona para SIEM e sistemas de chat em cada evento auditado.
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)|
     +-------------+   +---------------+   +-----------+

Um curl de distância

Uma chave de API bearer, um upload de hash ou de arquivo, e o binário assinado volta para o stdout. Authenticode, CAdES, PAdES, XAdES, ClickOnce, NuGet, VSIX compartilham a mesma estrutura.

Assinar um .exe em uma chamada

  • X-API-Key ou Authorization: Bearer — qualquer método de autenticação funciona.
  • X-Project seleciona o tenant; a chave deve estar autorizada para o projeto.
  • A resposta inclui X-Sgcsign-Signer-Subject + X-Sgcsign-Duration-Ms para correlação de logs.
  • Modo somente-hash para Authenticode: envie o SHA-256, receba um pequeno blob PKCS#7.
sign-binary.sh
# 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

Três Passos para um Binário Assinado

De um host Windows recém-instalado ao primeiro artefato assinado em menos de cinco minutos.

1

Instalar

Execute o assistente Inno Setup incluído ou extraia o zip em uma pasta. O daemon se registra como um serviço Windows chamado sgcSignServer. Vincule à porta :8443 e carregue seu certificado TLS.

2

Configurar um Provedor de Chave

Adicione um provedor ao sgcSignServer.conf.json — um arquivo PFX, conta Azure Trusted Signing, chave AWS KMS, usuário Certum SimplySign ou qualquer um dos outros dez provedores de chave. Não é necessário reiniciar o serviço.

3

Emitir um Token e Chamar a API

Abra /admin/apikeys, clique em New API key, vincule ao projeto, copie o token para o segredo do runner de CI. O agente de build chama POST /api/v1/sign.

Melhor custo-benefício: All-AccessTodos os produtos da eSeGeCe, com Suporte Premium incluído, a partir de €1,059/ano.
Ver preços do All-Access

Centralize a Assinatura em Todo o Seu Parque de Build

Pare de copiar certificados de assinatura para cada agente de build. Um sgcSign Server, um endpoint REST, auditoria completa e aprovações.