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.
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.
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.
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.
Interfejs /admin oparty na Bootstrap do zarządzania użytkownikami, kluczami API, dostawcami, projektami, audytem, zatwierdzeniami, webhookami i metrykami. Operatorzy nie muszą edytować JSON.
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.
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.
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.
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.
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.
21 zdarzeń cyklu życia dostarczanych z X-Sgcsign-Signature: sha256=…. Kolejka ponownych prób (trzy próby) synchronizuje systemy SIEM, czat i tickety.
Ten sam silnik co w bibliotece, udostępniony przez REST API. Każdy profil krajowy, każdy poziom podpisu.
Podpisy XML dla VeriFactu, FatturaPA, Facturae, KSeF, e-Factura, Peppol, myDATA i unijnych umów o pracę. POST /api/v1/sign/xades.
Podpisy PDF PAdES-Basic z aktualizacjami przyrostowymi zachowującymi oryginalną treść. Widoczne lub niewidoczne podpisy. POST /api/v1/sign/pades.
Podpisy CMS / PKCS#7 odłączone lub dołączone dla dowolnych danych binarnych. Znacznik czasu + długoterminowa walidacja. POST /api/v1/sign/cades.
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.
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.
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.
Podpisuje manifesty ClickOnce (.application / .manifest), aby klienty Windows instalowały bez monitów o zaufanie. POST /api/v1/sign/clickonce.
Podpisuje pakiety .nupkg, aby klient NuGet weryfikował tożsamość wydawcy. Obsługuje podpisy autora i repozytorium. POST /api/v1/sign/nuget.
Podpisuje pakiety rozszerzeń Visual Studio, aby VS Marketplace i samo IDE akceptowały je jako zaufane. POST /api/v1/sign/vsix.
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.
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.
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.
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ą.
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.
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.
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.
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.
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.
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.
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.
# 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
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.
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ą.
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.
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.
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.
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.
/api/v1 przez HTTPS z kluczem API bearer.
/admin w dowolnej przeglądarce. Interfejs Bootstrap, ciasteczka sesji, dostęp oparty na rolach.
+----------------------------+
| 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)|
+-------------+ +---------------+ +-----------+
curlKlucz 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.
X-API-Key lub Authorization: Bearer — obie metody uwierzytelniania działają.
X-Project wybiera dzierżawcę; klucz musi być autoryzowany dla projektu.
X-Sgcsign-Signer-Subject + X-Sgcsign-Duration-Ms do korelacji logów.
# 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
Od świeżego hosta Windows do pierwszego podpisanego artefaktu w mniej niż pięć minut.
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.
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.
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.