sgcSign Server

Samodzielnie hostowany demon zdalnego podpisywania kodu, który obudowuje silnik sgcSign interfejsem REST API, konsolą administracyjną Bootstrap i klientem wiersza poleceń dla pipeline'ów CI/CD.

REST API + panel administracyjny
7 formatów podpisu
Projekty wielodostępne
Dziennik audytu z łańcuchem haszowym

Co otrzymujesz

Jeden host, Windows lub Linux, przyjmuje żądania podpisywania od agentów buildu, deweloperów i pipeline'ów CI — z wbudowanym pełnym audytem, zatwierdzeniami i metrykami.

REST API

Zabezpieczone TLS punkty końcowe /api/v1 do podpisywania, weryfikacji, sprawdzania stanu, metryk i przepływów zatwierdzeń. Stabilny, maszynowo-przyjazny kontrakt dla agentów buildu i SDK.

Panel administracyjny

Interfejs /admin oparty na Bootstrap do zarządzania użytkownikami, kluczami API, dostawcami, projektami, audytem, zatwierdzeniami, webhookami i metrykami. Operatorzy nie muszą edytować JSON.

Instalator usługi Windows

Kreator Inno Setup lub wrzucenie ZIP. Demon rejestruje się jako usługa Windows, sam obsługuje TLS i działa bezobsługowo na zabezpieczonym hoście.

Projekty wielodostępne

Każdy projekt izoluje podzbiór dostawców, kluczy API, widoczności audytu i kolejek zatwierdzeń. Kilka zespołów współdzieli jeden serwer, nie widząc nawzajem swojego materiału podpisującego.

Dwuetapowy przepływ zatwierdzeń

Ten sam klucz API składa żądanie, administrator lub administrator projektu zatwierdza albo odrzuca, i dopiero wtedy bajty są podpisywane. Hash SHA-256 i rozmiar pliku są zablokowane w żądaniu.

Dziennik audytu SHA-256

Każde działanie — podpisanie, weryfikacja, logowanie, zatwierdzenie, wywołanie webhooka — jest dołączane do dziennika audytu z łańcuchem haszowym. Manipulacje są wykrywalne; scrapowanie SIEM jest proste.

Metryki Prometheus

Liczniki podpisywania / weryfikacji / zatwierdzeń, histogramy opóźnień podpisywania, mierniki dostępności dostawcy. Bezpośrednia ekspozycja tekstu Prometheus 0.0.4 bez dodatkowej bazy danych do zarządzania.

Webhooki podpisane HMAC

21 zdarzeń cyklu życia dostarczanych z X-Sgcsign-Signature: sha256=…. Kolejka ponownych prób (trzy próby) synchronizuje systemy SIEM, czat i tickety.

XAdES · PAdES · CAdES

Ten sam silnik co w bibliotece, udostępniony przez REST API. Każdy profil krajowy, każdy poziom podpisu.

XAdES

Podpisy XML dla VeriFactu, FatturaPA, Facturae, KSeF, e-Factura, Peppol, myDATA i unijnych umów o pracę. POST /api/v1/sign/xades.

PAdES

Podpisy PDF PAdES-Basic z aktualizacjami przyrostowymi zachowującymi oryginalną treść. Widoczne lub niewidoczne podpisy. POST /api/v1/sign/pades.

CAdES

Podpisy CMS / PKCS#7 odłączone lub dołączone dla dowolnych danych binarnych. Znacznik czasu + długoterminowa walidacja. POST /api/v1/sign/cades.

Czeska EET 2.0

Buduje i podpisuje zarejestrowaną sprzedaż kluczem przechowywanym na serwerze, opcjonalnie wysyła ją do organu podatkowego i zwraca odpowiedź. Sieć kas współdzieli jeden certyfikat podatnika. POST /api/v1/sign/eet.

Authenticode, ClickOnce, NuGet, VSIX

Demon podpisywania komunikuje się z dowolnie skonfigurowanym źródłem certyfikatów: magazyn Windows, PFX, token sprzętowy PKCS#11, Azure Trusted Signing, AWS KMS, Google KMS.

Authenticode

Podpisuje .exe, .dll, .msi, .cab, .cat, .ocx, .sys. Tryb tylko-hash pozwala agentom o małej przepustowości wymienić kilkadziesiąt bajtów na 8 KB obiekt PKCS#7. Dodaj --page-hashes (page_hashes w API), aby uzyskać skróty stron dla sterowników trybu jądra, tak jak signtool /ph.

ClickOnce

Podpisuje manifesty ClickOnce (.application / .manifest), aby klienty Windows instalowały bez monitów o zaufanie. POST /api/v1/sign/clickonce.

Pakiety NuGet

Podpisuje pakiety .nupkg, aby klient NuGet weryfikował tożsamość wydawcy. Obsługuje podpisy autora i repozytorium. POST /api/v1/sign/nuget.

Rozszerzenia VSIX

Podpisuje pakiety rozszerzeń Visual Studio, aby VS Marketplace i samo IDE akceptowały je jako zaufane. POST /api/v1/sign/vsix.

Bezpieczeństwo i dostęp

Silniejsze logowanie do konsoli administracyjnej i zaszyfrowane sekrety na dysku, dzięki czemu skradzione hasło lub skopiowany plik konfiguracji nie otwiera kluczy podpisujących.

Logowanie dwuskładnikowe

Konta konsoli dodają 6-cyfrowy kod z dowolnej aplikacji uwierzytelniającej TOTP, wraz z 10 jednorazowymi kodami odzyskiwania na wypadek utraty telefonu. Ustaw admin.require_2fa, a każdy użytkownik konsoli musi się zarejestrować, zanim przejdzie do jakiejkolwiek innej strony. Administrator może zresetować utracony drugi składnik.

Logowanie OpenID Connect

Loguj się do konsoli przez Microsoft Entra ID, Okta, Keycloak, Google lub dowolnego standardowego dostawcę OpenID Connect, z użyciem przepływu kodu autoryzacji z PKCE. Użytkownicy łączą tożsamość zewnętrzną ze swoim kontem, a nowi użytkownicy mogą opcjonalnie poprosić o konto zatwierdzane przez administratora.

Utwardzenie konsoli

Każda odpowiedź zawiera nagłówki bezpieczeństwa i ścisłą politykę Content Security Policy. Do tego konfigurowalna polityka haseł, hasła tymczasowe, które trzeba zmienić przy pierwszym logowaniu, oraz sesje kończone, gdy tylko zmieni się rola lub uprawnienia, na których się opierają.

Sekrety szyfrowane w spoczynku

Hasła dostawców, kody PIN, dane uwierzytelniające chmury i sekrety webhooków są przechowywane zaszyfrowane algorytmem AES-256-GCM pod kluczem głównym powiązanym z maszyną (DPAPI w systemie Windows). sgcSignServer --protect-secrets szyfruje istniejącą konfigurację w miejscu.

Kontrola podpisywania i znaczniki czasu

Serwer decyduje, kto może podpisywać, którym kluczem i po czyim zatwierdzeniu, a każdy podpis otrzymuje znacznik czasu, nawet gdy jeden serwer znaczników czasu nie działa.

Wymuszone zatwierdzenia

Oznacz dostawcę lub cały projekt jako wymagający zatwierdzenia, a serwer odmówi bezpośredniego podpisu z błędem approval_required. Każde zatwierdzenie pozwala podpisać jeden raz. Reguła obowiązuje na każdej ścieżce podpisywania, także przy podpisie surowego skrótu dla signtool /dlib.

Cykl życia kluczy API

Wygeneruj klucz ponownie, podczas gdy stary sekret działa jeszcze do 7 dni, zmień jego datę ważności, sprawdź, kto jest właścicielem, i ogranicz go do listy dozwolonych dostawców. Z api_keys.self_service operatorzy tworzą własne klucze i zarządzają nimi w ustalonych przez Ciebie granicach. Klucz może też rozpoczynać ważność przy pierwszym użyciu: jest ważny przez N dni liczonych od pierwszego uwierzytelnionego wywołania, z obowiązkową datą „aktywuj przed”, dzięki czemu nieużywany klucz nigdy nie pozostaje ważny bez końca. Podklucze działają dopiero po aktywacji klucza nadrzędnego, aktywacja jest zapisywana w dzienniku audytu jako apikey.activate, a edycja Community ogranicza obie wartości do 30 dni.

Ochrona prób PIN dla PKCS#11

Serwer zlicza błędne wyniki PIN dla każdego tokenu i przestaje się logować po max_pin_attempts, więc błędny PIN w konfiguracji nigdy nie zablokuje tokenu sprzętowego. Ostatnia próba jest użyta tylko z allow_final_pin_try, a administrator resetuje ochronę z poziomu konsoli.

Zapisane profile CLI

sgcsign config zapisuje serwer, dostawcę i inne ustawienia w nazwanych profilach, a sgcsign auth set-key przechowuje klucz API, więc skrypty kompilacji przestają je powtarzać. CLI w Delphi i narzędzie .NET esegece.sgcsign.cli korzystają z tych samych plików.

Znaczniki czasu z automatycznym przełączaniem

  • Ogólnoserwerowa lista domyślnych serwerów znaczników czasu RFC 3161, odpytywanych po kolei, aż któryś odpowie.
  • Listy tsa_urls dla każdego dostawcy oraz no_timestamp dla żądania, które nie może mieć znacznika czasu.
  • sgcsign timestamp dodaje znacznik czasu do pliku już podpisanego Authenticode, z tym samym przełączaniem.
timestamps
# sgcSignServer.conf.json
"timestamp": {
  "servers": ["http://timestamp.digicert.com", "http://timestamp.sectigo.com"],
  "timeout_ms": 30000
}

# Dodaj znacznik czasu do już podpisanego pliku
sgcsign timestamp MyApp.exe --tsa http://timestamp.digicert.com --tsa http://timestamp.sectigo.com

Kopie zapasowe, monitorowanie i instalacja

Prowadź serwer latami bez niespodzianek: zaszyfrowane kopie zapasowe, ostrzeżenia przed wygaśnięciem certyfikatu, e-mail, gdy coś wymaga człowieka, oraz instalator dla systemu Windows.

Zaszyfrowane kopie zapasowe według harmonogramu

Jedno archiwum zawiera konfigurację, bazę danych, klucz główny oraz każdy plik klucza i certyfikatu, zaszyfrowane algorytmem AES-256-GCM pod hasłem. Archiwa powstają według harmonogramu lub z konsoli, a sgcSignServer --archive restore odtwarza serwer na tej samej maszynie lub przenosi go na nową.

Monitorowanie wygasania certyfikatów

Certyfikaty podpisujące i certyfikat TLS serwera są sprawdzane przy starcie i codziennie. Ostrzeżenia na 30, 14, 7 i 1 dzień przed końcem ważności pojawiają się na pulpicie i są wysyłane jako webhook cert.expiring, e-mail oraz metryka sgcsign_certificate_not_after_seconds.

Powiadomienia e-mail

E-mail, gdy konto zostanie zablokowane, gdy zmieni się uwierzytelnianie dwuskładnikowe lub hasło, gdy kopia zapasowa się nie powiedzie albo certyfikat wkrótce wygaśnie. SMTP ze STARTTLS lub niejawnym TLS, a w systemie Windows moduł pocztowy nie wymaga bibliotek OpenSSL.

Instalator dla systemu Windows

sgcSignServer_Setup.exe instaluje serwer jako usługę Windows, tworzy pierwszego administratora i otwiera port zapory. TLS korzysta z wygenerowanego certyfikatu samopodpisanego, istniejącego pliku PFX albo zwykłego HTTP na maszynach testowych.

Jak elementy pasują do siebie

Jedna usługa Windows obsługuje TLS, udostępnia /api/v1 + /admin i kontaktuje się ze skonfigurowanym dostawcą klucza przy każdym wywołaniu. Materiał kluczowy nigdy nie trafia do bazy danych.

Jeden plik binarny, trzy interfejsy

  • Agenty buildu wywołują /api/v1 przez HTTPS z kluczem API bearer.
  • Operatorzy logują się do /admin w dowolnej przeglądarce. Interfejs Bootstrap, ciasteczka sesji, dostęp oparty na rolach.
  • Dostawcy kluczy pobierani na żądanie z PFX, magazynu Windows, PKCS#11, Azure TS, AWS KMS, GCloud KMS, Vault, Certum, CSC v2.
  • Baza danych SQLite przechowuje użytkowników, klucze API, dziennik audytu, sesje i kolejkę webhooków. Nigdy samego materiału kluczowego.
  • Webhooki są wysyłane asynchronicznie do systemów SIEM i czatu przy każdym zdarzeniu audytowanym.
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)|
     +-------------+   +---------------+   +-----------+

Jedno wywołanie curl

Klucz API bearer, przesyłanie hasha lub pliku i podpisany plik binarny przesyłany strumieniowo z powrotem do stdout. Authenticode, CAdES, PAdES, XAdES, ClickOnce, NuGet, VSIX mają ten sam kształt.

Podpisz plik .exe jednym wywołaniem

  • X-API-Key lub Authorization: Bearer — obie metody uwierzytelniania działają.
  • X-Project wybiera dzierżawcę; klucz musi być autoryzowany dla projektu.
  • Odpowiedź zawiera X-Sgcsign-Signer-Subject + X-Sgcsign-Duration-Ms do korelacji logów.
  • Tryb tylko-hash dla Authenticode: wysyłasz SHA-256, otrzymujesz małą strukturę 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

Trzy kroki do podpisanego pliku binarnego

Od świeżego hosta Windows do pierwszego podpisanego artefaktu w mniej niż pięć minut.

1

Instalacja

Uruchom dołączony kreator Inno Setup lub wrzuć ZIP do folderu. Demon rejestruje się jako usługa Windows o nazwie sgcSignServer. Powiąż z :8443 i załaduj certyfikat TLS.

2

Skonfiguruj dostawcę klucza

Dodaj dostawcę do sgcSignServer.conf.json — plik PFX, konto Azure Trusted Signing, klucz AWS KMS, użytkownika Certum SimplySign lub któregokolwiek z pozostałych dziesięciu dostawców kluczy. Nie jest wymagane ponowne uruchomienie usługi.

3

Wydaj token, wywołaj API

Otwórz /admin/apikeys, kliknij Nowy klucz API, ogranicz go do projektu, skopiuj token do sekretu runnera CI. Agent buildu wywołuje POST /api/v1/sign.

Najkorzystniejsza oferta: All-AccessWszystkie produkty eSeGeCe, ze wsparciem Premium w cenie, już od €1,059 rocznie.
Zobacz cennik All-Access

Scentralizuj podpisywanie w całej farmie buildów

Przestań kopiować certyfikaty podpisywania na każdy agent buildu. Jeden sgcSign Server, jeden punkt końcowy REST, pełny audyt i zatwierdzenia.