Certificates for eSignatures: What Do I Need—and Why?

In our current “remote first” world where many employees now work from home on a regular basis, the business case for replacing wet signatures with digital ones is clearer than ever.

But implementing eSignatures can be complicated. Data residency regulations or specifications on choosing a recognized certificate authority that prevents the use of an established Software as a Service provider for all desired use cases—can create an implementation obstacle course.

Let’s demystify some of the requirements and technical terminology for hosting your own eSignature service using Kofax SignDoc, including the types certificates you'll need and any additional costs associated with using them.

What’s a Digital Certificate?

To replace wet signatures on documents or contracts, you’ll need to:

· Identify the parties that will sign the document

· Prove that the people signing the document did in fact sign the document

· Ensure the document cannot be changed once it is signed

· Ensure the signed document is legally valid in the event of any dispute

Provide secure access to the eSignature solution and promote its adoption within your organization.

Digital certificates use globally agreed-upon technology standards to address these needs—the same infrastructure that secures e-commerce websites and online payments (we’ll explain that below). When applied to documents, digital signatures lock the document in question so it can’t be changed once it’s signed, and they identify the parties who participated in the signing ceremony or transaction. Using certificates based on this widely used infrastructure in turn improves trust, helping drive adoption of your service.

Common Terminology for Digital Certificates

The following section introduces some of the terms you are likely to encounter when discussing digital certificates.

Public-key cryptography: A cryptographic system where documents can be encrypted, or locked, using a digital key. There are two types of keys, used together as a “key pair.” •

· Private key: Known only to the certificate holder, which can be used to uniquely encrypt content so it can only be unlocked or accessed using the corresponding public key in the pair.

· Public key: Widely distributed and allows people to verify the source/sender and integrity of messages encrypted with a private key.

When a private key is combined with someone else’s public key and vice versa (known as a “key exchange”), this creates a unique pair of keys that allows encrypted communication between the two parties.

Public Key Infrastructure (PKI): Mentioned above, all the roles, software, processes and policies used to manage the creation, distribution and use of public-private key pairs.

Digital certificate: An electronic document that provides the identity of the certificate’s holder by embedding the public key and thus allowing encryption and verification of communication using PKI.

Certificate Authority (CA): A trusted organization that’s able to issue new certificates and key pairs. Certificates and key pairs are created using a hierarchy, with the certificate authority holding the “root” or “top level” certificate.

Businesses or individuals can buy certificates from a Certificate Authority. Their certificates are linked back to the CA’s certificates as part of the hierarchy. This creates a chain of trust. The company or individual’s certificate is trusted because it’s part of the same chain of certificates as the top-level CA.

When issuing certificates, the CA will undertake due diligence checks to ensure they only issue certificates to legitimate and trustworthy companies. There are different “trust levels” for the certificates the CA will issue, which in turn depend on the level of background checks the CA have undertaken:

· Extended Validation Certificates: The highest level of validation of the organization’s identity, including extensive vetting prior to issuing the certificate, in turn providing greater trust and confidence in the certified organization.

· Organization Validated (OV) Certificates: The organization’s business location and domain name are included in the certificate.

· Domain Validated (DV) Certificates: The certificate is linked to the domain name in use, proving the certificate owner does have control over than internet domain.

• Trust Service Provider (TSP): a Certificate Authority that is regulated and recognized by a government to provide certificates for that country for use in legally defined use cases. Certificates from a TSP are required for some, but not all, types of legal transactions.

This ebook explores the legal recognition of digital signatures in various countries.

Self-Signed Certificate: It’s possible to create a “self-signed” certificate using the PKI standards, however this certificate will not be automatically trusted because it hasn’t been issued by a Certificate Authority. While documents signed with a self-issued certificate are locked and encrypted, browsers or PDF software used to view the document will display warnings because the signer is not trusted.

Adobe Approved Trust List (AATL): A separate scheme managed by Adobe that builds on top of PKI, for users of Adobe Acrobat products. When PDF documents signed with certificates that are not part of the AATL trust chain are opened in Adobe Acrobat, the users see a warning.

Hardware Security Module (HSM): A piece of computer hardware designed to securely hold a private key on a server, for use in signing and encrypting content. It’s typically installed as a tamper proof card in a server or as a plugin device (e.g., USB), and using recognized industry standards such as FIPS 140 (Federal Information Processing Standards). Directly attached to the physical server, it ensures that the security implementation and algorithms in use on that server haven’t been compromised.

Depending on the HSM being used, a plugin is needed as part of the SignDoc installation to access the key on the HSM. Extensive documentation and template code is provided with SignDoc to create this plugin.

Considerations When Selecting a Certificate for SignDoc

Kofax SignDoc allows companies and business process outsourcers to host their own digital signature infrastructure and service.

While SignDoc can be installed and configured using a self-signed certificate, in most use cases it is preferable to configure the service to use a certificate from a Certificate Authority. If the digital signature service will be available publicly (i.e., to other users outside your own company), using a certificate issued by a trusted CA is essential.

As you can see, there is much to consider in choosing the most appropriate Certificate Authority for your organization. Kofax can help. Contact your Sales Representative or click below to learn more.