Signing Certificates

The Signing Certificates configuration defines how elDoc applies certificate-based digital signatures to completed eSignature documents.

elDoc can digitally sign resulting PDF documents using a certificate and corresponding private key stored either:

• in a PKCS#12 keystore file;
• on a hardware cryptographic token accessed through PKCS#11;
• on one or more dedicated signing nodes in a clustered deployment.

It is also possible to run eSignature without applying a certificate-based digital signature, although in that case the resulting documents are not cryptographically signed by elDoc.

The signing configuration is defined in the elDoc configuration file using the eSign.keyStore.* properties.

Signing Architecture

elDoc supports several signing deployment models:

• Local file-based signing – the certificate and private key are stored in a PKCS#12 file on the elDoc node.
• Hardware-token signing – the private key remains on a hardware cryptographic token and is accessed through a PKCS#11 provider.
• Dedicated signing nodes – one or more nodes in a clustered deployment perform signing.
• No-sign mode – eSignature workflows remain available, but elDoc does not apply a certificate-based digital signature (for test environments).
• Non-signing application node – the node does not contain signing credentials and delegates signing to configured signing nodes.

This architecture allows elDoc to be deployed in environments ranging from a single application node to highly controlled enterprise PKI environments with isolated signing infrastructure.

Fully On-Premises Operation

Signing can operate entirely on-premises, including in closed or air-gapped environments.

No external cloud signing service is required when the organization provides its own signing certificate and private key.

The private key can remain:

• inside the organization's infrastructure in a protected PKCS#12 keystore; or
• on a hardware token (e.g. USB-token) or HSM-compatible PKCS#11 device.

This makes the signing architecture suitable for environments with strict requirements for:

• data residency;
• private-key custody;
• network isolation;
• internal PKI;
• regulatory controls;
• restricted external connectivity.

eSign.keyStore.type

The eSign.keyStore.type property defines the signing mode used by the current elDoc node.

Supported values are:

file

Uses a certificate and private key stored in a local PKCS#12 keystore file.

Example:

eSign.keyStore.type=file

Additional properties are required:

eSign.keyStore.pwd=
eSign.keyStore.alias=
eSign.keyStore.file.path=

token

Uses a hardware cryptographic token through a PKCS#11 provider.

Example:

eSign.keyStore.type=token

Additional properties are required for the token and PKCS#11 configuration.

nosign

Disables certificate-based digital signing.

Example:

eSign.keyStore.type=nosign

eSignature workflow functionality can still be used, but resulting documents are not digitally signed with the configured certificate.

Empty value

An empty eSign.keyStore.type means that the current node is not a signing node.

The node does not load a signing certificate or private key and delegates signing operations to one of the configured signing nodes in the cluster.

This mode is used in clustered deployments where signing responsibility is separated from general application processing.

File-Based Signing

File-based signing uses a PKCS#12 keystore containing both:

• the signing certificate;
• the corresponding private key.

The keystore file must use the .p12 format.

A typical configuration is:

eSign.keyStore.type=file
eSign.keyStore.pwd=<keystore-password>
eSign.keyStore.alias=<certificate-alias>
eSign.keyStore.file.path=/path/to/eldoc-signing.p12

eSign.keyStore.pwd

Defines the password used to open the PKCS#12 keystore.

Example:

eSign.keyStore.pwd=<password>

The password must be protected as part of the server configuration and should not be exposed to unauthorized users.

eSign.keyStore.alias

Defines the alias used to locate the certificate and private key inside the keystore.

Example:

eSign.keyStore.alias=eldoc-signing

The configured alias must correspond to an entry containing both the certificate and private key.

eSign.keyStore.file.path

Defines the path to the PKCS#12 keystore file.

Example:

eSign.keyStore.file.path=/opt/eldoc/security/eldoc-signing.p12

The file must:

• be readable by the elDoc runtime account;
• be protected from unauthorized access;
• contain the signing certificate;
• contain the corresponding private key;
• use PKCS#12 format.

Hardware Token Signing

Hardware-token signing allows elDoc to use a certificate and private key stored on a hardware cryptographic device.

The device is accessed using the Java PKCS#11 provider.

A typical configuration is:

eSign.keyStore.type=token
eSign.keyStore.pwd=<token-pin>
eSign.keyStore.alias=<certificate-alias>

eSign.keyStore.token.name=elDoc-eSign-Token
eSign.keyStore.token.library=/usr/lib64/libeTPkcs11.so
eSign.keyStore.token.slot=0

PKCS#11 Token Properties

Properties beginning with:

eSign.keyStore.token.

are used to build the PKCS#11 provider configuration required to communicate with the hardware token.

eSign.keyStore.token.name

Defines the logical name of the PKCS#11 provider.

Example:

eSign.keyStore.token.name=elDoc-eSign-Token

eSign.keyStore.token.library

Defines the path to the vendor PKCS#11 library.

Example:

eSign.keyStore.token.library=/usr/lib64/libeTPkcs11.so

The exact library depends on the hardware token, HSM, and vendor software installed on the server.

eSign.keyStore.token.slot

Defines the PKCS#11 slot containing the required token.

Example:

eSign.keyStore.token.slot=0

The correct slot value must match the token configuration reported by the installed PKCS#11 middleware.

Hardware Token Security

When hardware-token signing is used, the private key remains on the cryptographic device and is not exported to the elDoc application.

elDoc sends the required signing operation to the PKCS#11 provider, which performs the private-key operation on the token.

This provides stronger private-key protection than storing the private key in a file-based keystore.

Hardware-token signing is suitable for environments where security policy requires:

• non-exportable private keys;
• centralized key custody;
• hardware-backed signing;
• stronger separation between application and cryptographic material.

Clustered Deployment

elDoc supports certificate-based signing in a clustered environment.

Not every application node needs access to the signing private key.

A recommended deployment can separate nodes into:

• general application nodes;
• dedicated signing nodes.

General nodes can process user requests, workflows, and eSignature packages without storing signing credentials.

When a certificate-based signing operation is required, the request is delegated to a signing node.

A simplified architecture is:

User / eSignature Request
        ↓
elDoc Application Node
        ↓
Signing Request
        ↓
Dedicated Signing Node
        ↓
PKCS#12 Keystore or Hardware Token
        ↓
Digitally Signed PDF

Dedicated Signing Nodes

A dedicated signing node is configured with one of the active signing modes:

eSign.keyStore.type=file

or:

eSign.keyStore.type=token

A general application node that should not sign locally leaves the signing type empty.

For example:

eSign.keyStore.type=

This indicates that the node delegates signing to available signing nodes.

This design reduces the number of servers that require direct access to private signing keys.

High Availability

Multiple signing nodes can be used in a clustered deployment.

This allows signing capability to remain available if one signing node becomes unavailable.

Signing nodes can use:

• separate protected copies of the same PKCS#12 material where permitted;
• separate hardware tokens;
• shared enterprise cryptographic infrastructure;
• another approved PKI deployment model.

The exact architecture depends on the organization's certificate policy and private-key custody requirements.

No-Sign Mode

To operate eSignature without certificate-based PDF signing, configure:

eSign.keyStore.type=nosign

In this mode:

• eSignature packages can still be created;
• recipients can sign, view, and receive copies;
• workflow and audit information remains available;
• resulting documents are not digitally signed by elDoc using a certificate/private key.

This mode can be useful for:

• testing;
• non-production environments;
• deployments where certificate-based signing is not required;
• environments where external signing is performed later by another system.

For production environments requiring verifiable digital signatures, configure either file-based or token-based signing.

Certificate Requirements

The certificate used for signing must be suitable for document-signing purposes according to the organization's PKI policy.

The certificate should:

• be valid;
• contain the corresponding private key;
• be trusted according to the intended validation environment;
• have an appropriate key usage and extended key usage where required;
• remain within its validity period;
• be issued by a trusted internal or external Certification Authority, depending on the deployment.

The exact certificate requirements depend on the applicable organizational, legal, and regulatory policies.

Resulting Signed Documents

When certificate-based signing is enabled, elDoc applies a digital signature to the resulting PDF documents after the eSignature workflow is completed.

The digital signature provides cryptographic integrity protection for the signed PDF.

A compatible PDF signature-validation tool can verify whether:

• the document has been modified after signing;
• the digital signature is valid;
• the certificate chain is valid according to the verifier's trust configuration;
• the signing certificate was valid at the applicable signing time.

This is separate from the visible signature, initials, or stamp placed on the document during the eSignature workflow.

The visible representation identifies the signer in the document layout, while the certificate-based digital signature protects the integrity of the resulting PDF.

Example Configuration – File-Based Signing

# ****************************************************************************************
# eSignature Settings
#
eSign.keyStore.type=file
eSign.keyStore.pwd=<password>
eSign.keyStore.alias=eldoc-signing
eSign.keyStore.file.path=/opt/eldoc/security/eldoc-signing.p12

Example Configuration – Hardware Token

# ****************************************************************************************
# eSignature Settings
#
eSign.keyStore.type=token
eSign.keyStore.pwd=<token-pin>
eSign.keyStore.alias=eldoc-signing

eSign.keyStore.token.name=elDoc-eSign-Token
eSign.keyStore.token.library=/usr/lib64/libeTPkcs11.so
eSign.keyStore.token.slot=0

Example Configuration – No Certificate Signing

eSign.keyStore.type=nosign

Example Configuration – Non-Signing Cluster Node

eSign.keyStore.type=

The node does not load signing credentials and delegates signing to dedicated signing nodes.

Security Recommendations

For production deployments:

• restrict filesystem access to PKCS#12 files;
• avoid storing signing material in locations accessible to general users;
• protect keystore passwords and token PINs;
• prefer hardware-backed keys where private-key protection requirements are high;
• limit signing credentials to dedicated signing nodes where practical;
• monitor certificate expiration;
• maintain a controlled certificate-renewal procedure;
• use trusted time synchronization on signing nodes;
• back up configuration without exposing private-key material;
• test certificate validation before production use.

Certificate Renewal

Signing certificates have a finite validity period and must be renewed before expiration.

When replacing a certificate:

1. obtain a new signing certificate and corresponding private key;
2. update the PKCS#12 keystore or hardware token;
3. update the configured alias, path, or token settings where required;
4. restart or reload the signing node according to the deployment procedure;
5. perform a test eSignature transaction;
6. verify the resulting PDF digital signature with an independent PDF signature-validation tool.

Existing signed documents remain associated with the certificate used when they were originally signed.

Summary

elDoc eSignature supports several certificate-signing deployment models:

This allows elDoc eSignature to support simple single-node deployments as well as fully on-premises, air-gapped, clustered, and hardware-backed enterprise PKI environments while keeping certificate-based document signing under the organization's control.