Introduction

The purpose of this document is to describe the installation, configuration and management procedures for the Virtual Appliance (VA) named SignEngineWeb (SWS). The VA SWS was created to be manageable and ready-to-use. You should import this virtual machine (".ovf") in your infrastructure and then do the setup (for example, set up the proxy). With VA SWS, it is possible to sign, apply timestamps and verify the signature. SWS supports different types of signature devices(Sign Web Services) allow to sign and verify different document type, you can use this application only with devices enrolled by Namirial. There are multiple devices supported:

• Automatic signature
• Remote signature
• Disposable 
• Lean Disposable
• eSeal (electronic seal)

The supported signature standards areAnd there are multiple signatures supported:

• CAdES
• PAdES
• XAdES
• JAdES
• RAW signature (PKCS#1)

Additionally, it is possible to set the different levels of signature such as B, T, LT, LTV etc... These details are described in the documentation about integration with SWS.

The timestamps applied are in accordance with RFC 3161 and RFC 5544 standards.

During the verification of the signatures, SWS can verify certificates issued by all accredited Certification Authorities in the Countries of the European Community. Also, it is possible to verify signatures in any of the CAdES, PAdES and XAdES formats. 

In this guide will be described how to import the SWS appliance into VMWare workstation player.

Architectural Elements

SWS is intended to be hosted in the same environment as the applications that need to use the signature and verification services. Applications that require the signature will connect to and send the entire file content to SWS. SWS You can see a SWS like a blackbox like in this image:

Image Added

This is the flow during the signing process

While during the verify, this is the flow:

Image Added

Naturally SWS contact external services to complete the flow of signing and verify. Below will be described the external services used.

How SWS works during signing flow?

When SWS receive the file to sign, calculates the file hash and asks from to the FRA component (located in the Namirial CA datacenter) to sign it. FRA represents the system component which manages HSMs and uses the RSA algorithm-type signature.

Assuming SWS is inside the LAN (the same LAN hosting the applications that require the signature services) the documents are exchanged inside a private network. We have the confidentiality of the information contained in the hash that SWS has transmitted to FRA and a low impact on the Internet bandwidth. For each signature sent between SWS and FRA, approximatively 7KB are used, regardless of the document size. In the case of submissions of merged requests, the bandwidth usage decreases thanks to TCP, HTTPS and SOAP lower impacts.

Inflows and Outflows

SWS exposes its services via the SOAP and REST protocol.
On the other hand, it operates as a client in the following ways:

1. For signing operations it needs to contact the RAW signature services (PKCS#1 format) at https://fra.firmacerta.it
2. For timestamping operations it must be able to contact the Timestamping Authority (TSA) set in the call. In this case the supported protocols are HTTP and HTTPS. More precisely, Namirial TSA can be reached at http://timestamp.firmacerta.it and at https://timestamp.firmacerta.it
3. For signing verifications it must be able to contact the CA that issued the signer's certificate in order to prove its validity
4. For Updating TLS (TrustedList), it contacts periodically every EC national agency that supervises the Certification Authority (in Italy, this is AgID).

Minimum Requirements

For proper operation it is necessary that the virtual machine has allocated at least the following resources:

• 4 GB RAM (8 GB are suggested)
• 40 GB Hard Disk
• 2 core
• 1 network interface

1. ).

Ports and Protocols Usages (firewall rules)

Below the list of port and protocol used by SWS:

ec.europa.eu (the full link is: https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml)

Outbound communication to the Namirial FRA service are done through HTTPS, with a mutual authentication, and take place via a unique TLS certificate that Namirial distributes to every applicant, in order to identify the virtual appliance SWS caller.

Here is a table with the incoming protocols:

High Reliability Implementation

The RAW signature service (PKCS#1) is high reliability provided. The HSM and the FRA element are functional purpose redundants. The VA SWS high reliability can be achieved operating as you usually do for a generic web server: run the VA SWS setup (2 or more) and display the web services via a load balancer. Since SWS does not handle any application session, it is enough to set a load balancer policy with a same-weight Round-Robin type.

Using Apache as Reverse Proxy

A possible configuration consists in using Apache Web Server as reverse proxy and load balancer for SWS. Here is a suggestion for the configuration to use:

How SWS works during verify flow?

Type of distributions

SWS can be used in different mode:

• onPremise
• SaaS

The solution onPremise, the customer will receive the Docker image

While in SaaS solution, the customer will receive the endpoint and SSL certificate for integrate with this solution

Best practice

Namirial reccomends to have 2 instances of SWS active at same time to warranty the high reliability. Every instance is stateless and don't share session with other instance active.

Reccomandations

The SWS appliance must not be publicly displayed on the internet!!!!

Namirial don't assume responsability.

License

Below the list of library/framework used in SWS: