eIDAS SignServer: Typical setup and basic terms

We have introduced the eIDAS package for the SignServer and explained the different assurance levels of signatures including applicability in Introduction to eIDAS package for SignServer.

When engaging with similar projects, usually the first steps begin with design and architecture of the remote signing solution. A good design in the beginning can help you save money and time during implementation, so its definitely something that should not be overlooked. You should spend more time designing the correct solution rather than redesigning multiple times during the project.

Let’s take a look into a typical remote signing setup and the components in the solution. We will focus our point of view on the logical architecture of the solution rather than the network infrastructure.

Signing, sealing, timestamping

We are using different terms in order to distinguish between different types of digital signatures. There are typically three terms you should be aware of:

Although signing, sealing, and timestamping are used for different purposes, technically they are produced using the same principle. Asymmetric cryptography and public/private key pairs play the main roles here . In simple terms, data to be signed is hashed and encrypted using the private key, that produces the digital signature. Public key is then used for validation whenever that digital data is valid.

We’ll use the term signature or digital signature interchangeably in this article and in the next series. Meaning, that it applies to all types of signatures mentioned above, if not specifically mentioned otherwise.

Logical architecture

The following diagram represents a typical logical architecture of the remote signing solution:

Building a remote signing solution can be simple or complex, depending on the design and the technology used. SignServer, together with eIDAS package are the core of the solution here, enabling advanced qualified assurance level signatures. However, to built a complete remote signing service, other components are needed as well:


Solution is used by users. However, there are different user types, with different roles and responsibilities:

  • End users – end users expect to have a solution which is easy to use, fast, and provides the same legal assurance as if they use a handwritten signature. User experience is very important for the solution if its to be used by a large quantity of end users.
  • Operators – personnel that has the responsibility to operate the solution in a compliant and secure way. There are typically different operator roles across the solution components. Whenever help desk or security officers they have to ensure the security of the performed operations. Operators are mainly in contact with the end users. A good example is a case of identification and registration of the end user into the system.
  • Administrators – administrators take care of the technical solution. They have to ensure that the remote signing solution works correctly. Perform tasks like backup, updating and patching of the solution, functional and security monitoring, etc.


A presentation layer is what the users see and how they interact with the remote signing solution. From the end user perspective, we have typically the following options:

  • Web, mobile, or desktop application, which handles the signature process
  • Standard interface like Windows KSP/CSP (used by desktop applications)
  • Document management systems

Remote signing solution usually has different options for technical integration. These can be used to create various front-ends and provide the remote signature options to users in any application they use in day to day task (for example Document management system):

  • SOAP Web Services
  • Proprietary protocols and SDKs

Signing Logic

This the brain cortex of the remote signing solution. Signing logic is typically implemented as a set of rules and configuration items in a signing back-end. It controls the process of the signing, communicates with different components in the solution and mediates information between them. For example:

  • Configuration of assurance rules, enforcing security controls
  • Setting of different supporting systems to work with the solution
  • Definition of signing process and workflow
  • Compliance checking, audit trail, evidence
There are many more tasks that are being done here. The signing logic is in control of the whole remote signing solution and provides the necessary agility, that is driven with rapid changes in technologies.

Supporting Systems

As you already know, the remote signing solution consists of a number of integrated systems and components. Each of them provides a different function in the ecosystem. Together they form a mature service with required assurance . The role of the SignServer is the provision of a central signing functionality. As an example, it supports and enables different signing formats and management of cryptographic keys, however it does not issue certificates, or authenticate users.

The supporting systems provide all necessary functions that are needed. Some typical supporting systems are listed below:

  • Identity Provider – identifies users, securely stores identities and provides identity verification (authentication) of the users
  • Authorization Solution – defines roles and permission for identified users, provided authorization proof of the users requesting signing operation
  • Certification Authority – issues certificates for users, that serve as a digital identity (for physical or legal persons), can also issue timestamping authority certificates
  • Document Management System – manages the life-cycle of the documents, and may also provide archiving, providing interface for end users to interact with the signing solution

eIDAS SignServer

This is the main signing functionality. eIDAS compliant signing formats with advanced qualified assurance level. SignServer manages the signing process. As an input it requires authorization, the data to be signed and requested format. Based on that it outputs the signed data, that are typically presented for end user, or stored for archiving purposes.

SignServer main role is to provide:

  • Digital signatures and seals in a requested format (for example, AdES formats)
  • Timestamping authority producing digital timestamps

Other functions it provides are for example:

  • managing the cryptographic keys for signing
  • providing certificate signing requests for certification authorities
  • enforcing security policy on who and how is able to request the signature
  • validate the certificates and signed data
  • monitoring and reporting on the signing services

Cryptographic Keys and Secure Storage

We need to protect all cryptographic keys, that are used in the solution. That’s why there should be a Hardware Security Module (HSM) for each remote signing solution. HSMs protect signing private keys, and all other cryptographic keys related to identity protection, authentication, authorization and integrity.

There are many vendors of HSMs, and it’s important to choose one, that has a standard interfaces, valid security certification according to Common Criteria Protection Profiles and does not introduce vendor lock for the solution.

For non-cryptography-related data, we need a database. Data in the database should be integrity protected. This can be achieved by signing or MACing the data inside the database. A good practice is to enable a database encryption, if the  technology in use support it.

Keep in mind that the database can contain the cryptographic keys as well as data encrypted by them. If mis-configured, a security loophole can be created with a risk of potential data breach.

Need help?

Do not hesitate to get in touch with us!

Get in touch with us!

security | data intelligence | consulting

Contact us!