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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
O mesmo motor que acompanha a biblioteca, exposto pela REST API. Todos os perfis por país, todos os níveis de assinatura.
Assinaturas XML para VeriFactu, FatturaPA, Facturae, KSeF, e-Factura, Peppol, myDATA e contratos de trabalho da UE. POST /api/v1/sign/xades.
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.
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.
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.
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.
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.
Assina manifestos ClickOnce (.application / .manifest) para que clientes Windows instalem sem alertas de confiança. POST /api/v1/sign/clickonce.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
# 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
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.
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.
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.
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.
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.
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.
/api/v1 via HTTPS com uma chave de API bearer.
/admin em qualquer navegador. Interface Bootstrap, cookies de sessão, acesso baseado em papéis.
+----------------------------+
| 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 distânciaUma 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.
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.
X-Sgcsign-Signer-Subject + X-Sgcsign-Duration-Ms para correlação de 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 um host Windows recém-instalado ao primeiro artefato assinado em menos de cinco minutos.
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.
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.
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.