Skip to content

DSS Services

The {{ product_name }} DSS Services provide remote electronic signing and signature validation for both the EU eIDAS regulation (910/2014) and the Swiss ZertES / VZertES framework. They are built on the EU Digital Signature Service (DSS 6.5) library and integrate with the {{ product_name }} tenant, license, HSM and OIDC subsystems.

What this section covers

  • What each app is for — pick the right one for signing or validation.
  • How to deploy each app (prerequisites, build/run, ports).
  • How authentication works for each app.
  • For the validator: the validation flows and modes (EU vs Swiss, AdES levels, qualifications).

The three apps at a glance

App What it does Where it runs Who calls it
DSS Signing Server Central, hash-only eIDAS remote signing over an HSM partition pool. The document never reaches the server — only its digest. Central {{ product_name }} infrastructure Server-to-server, with a client-signed JWT (typically the DSS proxy)
DSS Proxy ("Alpine Sign") On-prem, single-tenant signing portal. Hashes documents locally and sends only the hash to the signing server; operators sign PDFs through a browser UI. Inside the tenant's own network Operators & admins, via OIDC browser login
DSS Validator Central, multi-tenant validation of signed documents at all AdES levels for EU eIDAS and Swiss ZertES. Central {{ product_name }} infrastructure Users (browser UI) & applications (JSON REST), authenticated per tenant via OIDC

How they fit together

The signing apps form a privacy-preserving chain, while the validator stands alone:

Signing (privacy-preserving — document bytes stay on-prem):

  Operator ──upload PDF──▶ DSS Proxy ──hash only──▶ DSS Signing Server ──▶ HSM
  (browser)               (on-prem, tenant network)  (central)              (keys)
       ◀────────────── signed PDF (assembled on-prem) ──────────────┘

Validation (independent):

  User / App ──upload signed document──▶ DSS Validator ──▶ verdict (EU eIDAS or Swiss ZertES)

Figure: the DSS proxy keeps document bytes inside the tenant network and forwards only hashes to the central signing server; the validator is a separate, standalone service.

Two independent 'hints' in the validator — do not conflate them

The validator decides the legal framework (EU eIDAS vs Swiss ZertES) automatically from the signing certificate's trusted-list anchor in the document — it is never supplied by the caller. The tenant identity (for authentication and licensing) is separate, and is supplied by the request (a URL parameter for the UI, a token claim for the API). A German tenant can validate a Swiss signature and vice versa. See DSS Validator.

Choose your page

Goal Start here
Understand and deploy the central signing service DSS Signing Server
Give a tenant an on-prem signing portal DSS Proxy
Validate eIDAS / Swiss signatures (UI or REST) DSS Validator
Provision a tenant's DSS instance, HSM partition and licenses provision command group

Shared prerequisites

All DSS apps assume the following baseline. App-specific prerequisites are listed on each page.

  • Java 25 only (see Deployment overview).
  • PostgreSQL 18 — the signing server and validator read a {{ product_name }} control database (read-only) for tenant OIDC providers and license entitlements; the proxy keeps its own dss_proxy schema.
  • An OIDC provider for user or tenant authentication.
  • The {{ product_name }} Admin CLI to provision tenants, DSS instances, HSM partitions and licenses: provision, tenant oidc, tenant license.

FAQ

What is the difference between signing and validation here?

The signing server and proxy create electronic signatures (they hold or authorize the private keys). The validator checks existing signed documents against the EU and Swiss trusted lists and reports whether each signature is valid and how it is qualified. They are independent services — you can deploy the validator without the signing apps and vice versa.

Why is there both a signing server and a proxy?

The signing server is central and holds the HSM-backed keys. The proxy runs inside a tenant's own network so that document bytes never leave the premises — the proxy hashes each document locally and sends only the hash to the signing server, then assembles the signed document on-prem. One proxy is deployed per tenant; the signing server is shared.

Does the validator support Swiss signatures as well as eIDAS?

Yes. The validator loads both the EU List of Trusted Lists (LOTL) and the Swiss Trusted List, and detects the applicable framework automatically per signature. For Swiss signatures it additionally computes the ZertES qualification and the CO Art. 14 handwritten-equivalence verdict. See Validation modes.

How does a caller choose EU vs Swiss validation?

It does not — the framework is detected from the document's signing-certificate trusted-list anchor and is never passed in the request. The only thing a caller supplies is its own tenant identity for authentication and licensing.