🔏 E-Signature Integration

The one who signs the document and the one who verifies it are in the same system

The module sets up four signing paths together: qualified electronic signature with a smart card or a USB token, mobile signature over a GSM line, a wet signature drawn on screen and a wet signature image uploaded from a file. Every signed document is written to the ledger and can be queried back with a verification code.

  • The signing key never reaches the browserThe qualified signature is taken through the local signing service running on the user's own computer. The card PIN and the private key never leave the device; only the signed output goes to the server side.
  • The signature record is bound to the documentEvery signing event is written to the ledger with the signer, the document title, the document type, the signature type, the signing time, the SHA-256 digest of the file and a sixteen-character verification code.

Request a Demo

Supported signature types

The four below are set up as separate tabs in the module. A signature type that is not on this list does not exist in this module.

Qualified electronic signature

Signing with a smart card or a USB token. The local signing service finds the device, reads the certificate, verifies the PIN and produces the signed output; the digest algorithm is SHA-256.

Mobile signature

Signing through the mobile signature infrastructure tied to a GSM line. The subscription of the number is queried, a signing request lands on the phone, and the transaction is polled while approval is awaited.

Drawn wet signature

A signature drawn on a canvas with a mouse, a pen or a touch screen. The pen colour can be chosen and the drawing cleared and redone; the result is stored as a PNG in the form of the user's default signature.

Uploaded wet signature

Uploading an existing signature image from a file. PNG and JPEG are accepted, at most 5 MB; the image is resized on the server to a 600×200 bound and converted to PNG.

Signature formats

The format is chosen according to the type of the file being signed; the module picks the right one by looking at the file extension.

Format For which document How it is chosen
PAdES-BESPDF documentsSelected automatically when the extension is .pdf; exported reports are signed with this format.
XAdES-BESXML documentsSelected automatically when the extension is .xml.
CAdES-BESOther file typesThe default format for every file other than PDF and XML.

In all three formats the digest algorithm is SHA-256. The signed output is downloaded as a separate document alongside the file that was signed; the source file is not modified.

Qualified e-signature flow

Each of the six steps appears on screen as its own state; the user reads which step is being waited on and where it got stuck.

  1. Service checkFirst the network connection and then the local signing service running on the computer are probed. If the service is closed the screen shows both the start link and the retry button.
  2. Device scanConnected smart card readers and USB tokens are listed. If there is no device an insert the card warning appears; if there is more than one device you can switch between them.
  3. Reading the certificateThe certificate of the selected device is read; the certificate holder, the identity number, the issuing authority, the validity range and the device model appear on screen.
  4. PIN verificationThe PIN consists of digits only, is at most eight characters long and cannot be pasted into the field. A warning appears while Caps Lock is on; the entered value can be made visible on request.
  5. SigningThe progress bar shows three stages: verifying the PIN, signing, completed. The signing request is held for at most thirty seconds and returns as an error if no result arrives.
  6. Result and recordThe signed output is produced and the signing event is written to the ledger. After the first signature, storing the PIN bound to that device is offered; the offer can be declined.

Mobile signature flow

The mobile signature works asynchronously: the request is sent, the approval is given on the phone, and the system waits by polling for the result.

  1. Subscription queryWhether the entered number is a mobile signature subscriber is queried. If it is not, the flow stops before it starts and the reason is written on screen.
  2. Signing requestThe request is sent together with the description text that will appear on the phone; the user reads on their own screen which document they are approving.
  3. Transaction idWhen the request is accepted asynchronously a transaction id is returned and the screen moves into the awaiting approval on your phone state.
  4. Status pollingThe result is asked for every three seconds and waited for at most ninety seconds. If the time runs out the transaction closes with a timeout and has to be started again.
  5. ResultThree results are handled separately: signed, cancelled by the user, timed out. When a PDF is signed, the signature is embedded into the document and a signed copy is produced.

Situations met in the field

The module is built on the assumption that signing rarely finishes on the first attempt; eight situations are handled one by one.

Storing the PIN

With the user's consent the PIN is stored bound to the serial number of the device. The field is no longer empty on the next signature; the stored PIN can be deleted in one step.

Wrong PIN

When a wrong PIN is entered the warning is shown together with the number of attempts left; on the last attempt the warning is emphasised further.

Locked card

When the PIN is locked the screen moves to a warning state, the retry button is disabled and how to unlock the card is explained.

Caps Lock warning

While Caps Lock is on, a warning icon and a short explanation appear next to the PIN field; a mistyped PIN is prevented before it burns an attempt.

Card removed

Connected devices are probed every five seconds. If the card is removed during the operation the screen returns to the device scan and states that the connection was lost.

Second tab lock

If a second tab in the same browser starts signing, the other tab is locked; a single device is prevented from meeting two requests at once.

Certificate expiring

A warning is raised when fewer than thirty days remain to the end of the certificate and a critical warning when fewer than seven days remain or it has expired; signing does not open with an expired certificate.

Transient device error

On transient errors such as a dropped card session the operation is retried twice without showing an error to the user. If the error persists it is written together with its error code.

Signature ledger and verification

Who signed what and when can still be queried after the signed document has been downloaded.

  • Ledger recordEvery signing event is written with the signing user, the organisation, the document type, the document title, the signature type, the signing time, the IP address and the browser information.
  • File digestThe SHA-256 digest of the document is recorded; when queried with the same digest, the signature record the document belongs to is found.
  • Verification codeA sixteen-character verification code in four blocks is generated for every record; letters and digits that are easily confused are not used in the code.
  • Verification by QR codeA QR code carrying the verification address is printed on the exported document; when the code is scanned the validity of the record is queried.
  • Ledger listSignature records are filtered by document type, signature type and user; they are searched over the document title and the verification code.

Signing in with an e-signature

The same infrastructure is set up for authentication as well as for document signing.

Sign-in with a certificate

The identity number or the e-mail address extracted from the signing certificate is matched against the user record; if there is no match no session is opened.

Sign-in with a mobile signature

The sign-in request lands on the phone and the session opens when it is approved; if the request is not signed or is cancelled the sign-in is refused.

Session cookie

At the end of verification the session token is issued in a cookie only the server can read and is valid for a limited time.

Frequently asked

The five questions asked most often about signature types, setup and verification.

Which signature types are supported?
Four: qualified electronic signature with a smart card or a USB token, mobile signature over a GSM line, a wet signature image drawn on screen and a wet signature image uploaded from a file. No signature type other than these exists in the module.
Does anything have to be installed on the computer for a qualified signature?
Yes. The local signing service that talks to the card reader has to be running on the user's computer. The module probes the service at start-up; if it is closed, a start link and a retry button appear on screen.
Does a wet signature image replace a qualified signature?
No. A drawn or uploaded image is a record stamped onto the document as a visual signature. A cryptographic signature is produced only through the qualified electronic signature and mobile signature paths; the signature type is kept separately in the ledger so the two are never mixed.
How is the authenticity of a signed document queried?
There are two ways: the verification code on the document, or the SHA-256 digest of the file. Both are searched in the ledger; when a record is found, the document title, the document type, the signature type, the signing time and the signer are returned.
What happens if the user does not approve a mobile signature?
The transaction closes with one of three states: cancelled by the user, timed out, or an error returned by the infrastructure. If no approval arrives within ninety seconds the request times out and has to be started again.
🔏 E-Signature Integration

See the signing flow with your own document

Contact us to talk through which documents will be signed and how verification will be set up.

Talk to an Expert