Digital Certificates and PKI Guide for Modern eSignatures
- Amila Udowita
- 12 minutes ago
- 10 min read
If you have ever signed a document online and seen a small message that says the signature is verified or backed by a trusted certificate, you have already used a digital certificate without realizing it. Digital certificates are the quiet machinery behind every secure eSignature. They prove who signed a document, that the document has not been changed, and that the signing event can be trusted in court.
This guide explains what a digital certificate is in plain English, how public key infrastructure (PKI) works, what is actually inside a certificate, and how it all fits together when you click the sign button on a platform like Falkon Sign.
Want to see PKI in action without thinking about it?
Start a free Falkon Sign trial in under two minutes.
Why Digital Certificates Matter for Anyone Signing Online
A handwritten signature on paper is only as trustworthy as the witness who watched you sign it. An electronic signature is only as trustworthy as the technology that captures it. Digital certificates are how the modern web answers a very old question, which is, can we prove this signature belongs to this person and that the document was not tampered with after the fact.
That trust is what gives an eSignature its legal weight. The difference between a simple typed name and a cryptographically protected signature comes down to whether a digital certificate is involved, and how rigorously the identity behind it was verified. For a fuller comparison of the two concepts, see eSignature vs Digital Signature, what is the difference.
What Is a Digital Certificate in Plain English
A digital certificate is an electronic ID card. It binds three pieces of information together.
An identity, such as a person, a company, or a server.
A public cryptographic key that belongs to that identity.
A digital signature from a trusted third party (a certificate authority) confirming that the first two pieces of information go together.
When you receive a document that was signed using a digital certificate, your software can read the certificate, check who issued it, confirm that it is still valid, and then verify that the signature on the document was created by the matching private key. If any part of that chain breaks, the signature is flagged as invalid.
Think of it like a passport. Your passport binds your face to your name and your nationality, and a government you trust has signed it. Anyone in the world can verify that passport because they trust the issuing authority. A digital certificate works in exactly the same way for a cryptographic key.
How Public Key Infrastructure Powers Digital Certificates
Public Key Infrastructure, almost always shortened to PKI, is the wider system that issues, manages, and verifies digital certificates. It is not a single product. It is a stack of policies, software, hardware, and trusted organizations that work together.
The Two Key Idea, Public Key and Private Key
PKI is built on a branch of cryptography called asymmetric encryption. Each user gets two keys, a private key and a public key. They are mathematically linked. Anything signed with the private key can be verified with the matching public key, and only with that matching public key.
The private key never leaves the signer. It stays on their device, in a smart card, in a hardware security module, or in a secure enclave inside a cloud service. The public key, by contrast, can be shared freely. It is the public key that goes inside the digital certificate.
When you sign a document, your private key creates a unique cryptographic value based on the contents of the document. Anyone with your public key can run a verification step that confirms two things at once. First, that the signature really was created by the matching private key. Second, that the document has not been changed by even a single character since you signed it.
How a Certificate Binds an Identity to a Public Key
A raw public key by itself does not tell anyone who it belongs to. The whole point of a digital certificate is to tie that public key to a verified identity.
The process looks like this.
The signer generates a key pair.
The signer creates a certificate signing request that includes the public key plus identity information such as their name, organization, or email.
A certificate authority verifies the identity according to its rules.
If the checks pass, the certificate authority issues a digital certificate by signing the identity and the public key with the certificate authority's own private key.
After that, the certificate is portable. The signer can attach it to documents, present it during web sessions, or embed it in eSignature workflows.
The Trust Chain, Root, Intermediate, and End Entity
A single certificate authority does not sit alone. There is a hierarchy.
Root certificates sit at the top. They are issued by the most trusted authorities and are pre-installed in operating systems, browsers, and software like Adobe Acrobat. Microsoft, Apple, Mozilla, and Adobe maintain trust lists for these roots.
Intermediate certificates sit in the middle. They are issued by the root and used to sign end entity certificates. Using intermediates means the root can stay offline and secure.
End entity certificates are what individuals and companies actually use to sign documents. They are issued by an intermediate.
When you verify a signed document, your software walks up this chain. It checks the end entity certificate, then the intermediate that signed it, then the root that signed the intermediate. If the root is on your trust list, the entire chain is trusted. If not, you will see a warning.
What Is Actually Inside a Digital Certificate
Most digital certificates follow a standard called X.509. If you opened one in a viewer, you would see fields like these.
Version: Almost always v3 today.
Serial number: A unique number assigned by the certificate authority.
Signature algorithm: The algorithm used to sign this certificate, for example SHA-256 with RSA, or ECDSA with P-256.
Issuer: The certificate authority that issued the certificate.
Validity period: A not before date and a not after date.
Subject: The identity the certificate belongs to, often a name, organization, country, and email.
Subject public key info: The actual public key and what algorithm it uses.
Extensions: Optional fields such as key usage, extended key usage, certificate policies, subject alternative names, CRL distribution points, and OCSP responders.
Certificate signature: The cryptographic signature from the issuer that ties everything above together.
This last field is the most important. It is what makes a certificate a certificate rather than just a list of facts. The issuer signs the entire payload with its own private key, so anyone who trusts the issuer can trust the certificate.
Where Digital Certificates Fit in an eSignature Workflow
Now to the question that almost no competitor article answers directly, which is, where does the certificate live and what happens when you click sign on an eSignature platform.
What Happens When You Click Sign
When you click sign on a platform like Falkon Sign, several steps happen in the background.
The document content is hashed, which produces a short, unique fingerprint of the file.
A digital certificate is selected. It might be the platform's own certificate, a certificate issued to your organization, or in regulated workflows, a personal certificate that belongs to you.
The matching private key signs the hash. The result is the digital signature.
The signature, the certificate, and a timestamp from a trusted timestamp authority are all bundled into the signed document, often inside the PDF itself.
Anyone who later opens the document can verify the certificate chain, check the timestamp, and confirm the document has not been altered.
That last step is what powers the audit trail in an eSignature platform, because the certificate and timestamp together create a cryptographic record of who signed what and when.
Whose Certificate Signs Your Document
This is one of the most common questions. The answer depends on the platform and the type of signature you need.
For everyday eSignatures under US ESIGN or UETA, most platforms apply a platform owned document signing certificate after collecting your intent to sign. Your identity is captured separately through the audit trail.
For advanced electronic signatures under eIDAS in the EU, a certificate issued to your organization or to you personally is often used.
For qualified electronic signatures under eIDAS, a personal qualified certificate issued by a qualified trust service provider must be used, and signing is typically backed by a secure signing device.
Different platforms make different defaults. The important thing is to understand which model your platform uses, because it changes what is provable about who really signed.
Types of Digital Certificates Used in eSignatures
Not all certificates are interchangeable. Here are the main types you will see.
Document Signing Certificates
These are issued to a person or an organization for the purpose of signing documents like PDFs or Word files. They are the most common type used in business workflows. They typically follow the X.509 v3 standard and have an extended key usage value of document signing.
Personal Certificates for Qualified Electronic Signatures
In Europe, a qualified electronic signature requires a personal qualified certificate issued by a qualified trust service provider. These certificates verify that the signer has been identified to a strict standard, often face to face or via video identification, and the private key is held inside a qualified signature creation device.
AATL and Adobe Approved Trust List
Adobe maintains the Adobe Approved Trust List, often called AATL. Certificate authorities on this list have signed an agreement with Adobe and meet Adobe's technical and audit requirements. When you sign a PDF using a certificate from an AATL provider, Adobe Reader and Acrobat will show a green check and treat the signature as trusted by default. This is one of the most practical signals of certificate trust in document workflows.
eIDAS Qualified Trust Service Providers
In the European Union, a qualified trust service provider is an organization that has been audited and is on the EU trusted list. They issue qualified certificates that meet eIDAS standards. If your business needs qualified electronic signatures, the certificate has to come from one of these providers.
The Digital Certificate Lifecycle
A certificate is not forever. It has a clear lifecycle, and every stage matters.
Issuance
Issuance starts with the certificate signing request and identity verification. For low assurance certificates, this might be as simple as proving control of an email address. For qualified certificates, it requires in person or video identity verification with strict documentation.
Validity Period and Renewal
Every certificate has a not before and a not after date. Document signing certificates often have a validity period of one, two, or three years. When the validity period ends, the certificate must be renewed. A well designed eSignature platform handles renewals quietly in the background.
Revocation, OCSP, and CRL
Sometimes a certificate has to be invalidated before it expires, for example because the private key was lost or the signer changed organizations. That is called revocation. Two mechanisms publish revocation status.
Certificate Revocation Lists, often called CRLs, are signed lists of revoked certificate serial numbers that the certificate authority publishes regularly.
OCSP, the Online Certificate Status Protocol, lets a verifier query the certificate authority in real time and ask whether a specific certificate is still valid.
Modern eSignature platforms automatically check revocation status as part of the signing and verification steps.
How Digital Certificates Differ from SSL and TLS Certificates
It is easy to confuse the two, because both are X.509 certificates, both involve certificate authorities, and both are everywhere. The differences are practical.
SSL and TLS certificates are issued to web servers. They protect the connection between your browser and a website.
Document signing certificates are issued to a person or organization. They protect a document, not a connection.
In short, an SSL certificate proves the website you are visiting is legitimate. A document signing certificate proves that the document you are reading was signed by a specific identity and has not been changed.
Why Digital Certificates Matter for Compliance and Court Admissibility
For most regulated workflows, the certificate is what turns a simple eSignature into something that holds up in audits and in court. The certificate plus the signed hash and a trusted timestamp create three useful properties at once.
Authenticity. You can prove who signed.
Integrity. You can prove the document was not changed after signing.
Non repudiation. The signer cannot credibly deny having signed.
This combination is exactly what regulators look for under standards such as 21 CFR Part 11 in US life sciences and eIDAS qualified electronic signatures in the EU. It is also what makes a properly captured eSignature defensible in litigation. If you want a deeper read on the broader picture, why eSignature security matters for modern businesses is a useful companion piece.
Common Questions People Ask About Digital Certificates
What is the difference between a digital signature and a digital certificate?
A digital signature is the cryptographic act of signing. A digital certificate is the credential that proves which identity owns the private key that did the signing. You cannot have a meaningful digital signature without a digital certificate behind it.
Do I need to buy my own digital certificate to use an eSignature tool?
Usually no. For everyday eSignature use under US law, most platforms apply a platform managed certificate on your behalf. You only need to obtain your own certificate if you have specific regulatory requirements, such as qualified electronic signatures under eIDAS, or industry specific compliance like 21 CFR Part 11.
Who issues digital certificates?
Certificate authorities issue them. Some are commercial, like DigiCert, GlobalSign, Sectigo, and Entrust. Others are government linked, especially in the EU where qualified trust service providers are on the official EU trusted list.
How long is a digital certificate valid?
Validity periods vary. Document signing certificates are commonly issued for one, two, or three years. Qualified certificates often have shorter validity to enforce stricter renewal and identity checks.
Is a digital certificate the same as an SSL certificate?
Both are X.509 certificates, but they serve different purposes. SSL or TLS certificates protect web connections. Document signing certificates protect documents.
What happens if my certificate expires after I sign a document?
A properly signed and timestamped document remains verifiable even after the certificate expires, because the verification step uses the certificate's status at the time of signing, captured by the trusted timestamp.
Can a digital certificate be revoked?
Yes. If the private key is lost or the signer's role changes, the issuing certificate authority can revoke the certificate. Verifiers check the revocation status using OCSP or CRL.
Closing Thoughts
Digital certificates are not a buzzword. They are the trust layer underneath every secure eSignature, and they are what separates a casual typed name from a signature that can stand up in court. The good news is that for most users, the certificate work happens quietly in the background. A well designed eSignature platform manages issuance, signing, timestamping, and revocation checks without ever asking the user to think about X.509 fields or trust chains.
If you are evaluating tools and want to understand how a platform handles these foundations, our guide on how to choose the right eSignature tool for your business is a practical place to start. The right platform should make digital certificates feel invisible to the people signing, while making the underlying trust verifiable to the people who need it.
Secure eSignatures That Hold Up
Explore how Falkon Sign combines digital certificates, timestamping, and identity verification for compliant and legally defensible signing.
Comments