Public Key Infrastructure (PKI), Explained: The Certificates Behind a Digital Signature
Every digital signature rests on public key infrastructure (PKI): pairs of keys, certificates that tie a key to a name, and authorities that vouch for the certificates. If your organization is choosing a signing platform, or deciding whether to accept digitally signed documents, this is what sits under the signature.
Two keys, one job each
PKI starts with a key pair. The private key is kept secret by its owner and used to sign. The public key is shared with anyone and used to check.
Signing a document doesn’t mean encrypting it. The signing software computes the document’s hash, a short fingerprint of every byte in the file, and uses the private key to turn that hash into a signature. Anyone with the public key can then confirm two things: that the signature was made with the matching private key, and that the document still produces the same hash. Change a comma after signing and the second check fails.
So a digital signature proves integrity on its own. What it can’t prove on its own is identity. A public key is just a long number, and it says nothing about who holds the private key behind it.
Certificates: who owns the key
That is the job of a certificate. An X.509 certificate, the standard format, binds a public key to a name, which can be a person, an organization, or a platform. It also states when it is valid and what it may be used for, and it is itself digitally signed by the certificate authority (CA) that issued it.
When you open the signature panel of a signed PDF, the name you see comes from the certificate. The real question is whether you trust the authority that issued it.
Chains of trust
Certificate authorities are arranged in chains. A root CA, whose key is guarded closely and used rarely, signs the certificates of intermediate CAs. The intermediates issue the certificates that actually sign documents. Software that checks a signature follows the chain upward until it reaches a root it already trusts.
Which roots it trusts is decided by whoever maintains its trust list. Operating systems and browsers keep their own. Adobe keeps one for Acrobat and Acrobat Reader, the Adobe Approved Trust List, covered in our AATL explainer. An organization can also run a private CA and trust it within its own systems. A certificate from a public CA is recognized widely by default, while one from a private CA is recognized wherever its root is trusted.
Expiry, revocation, and time
Certificates don’t last forever. Each one expires, usually within a few years, and a CA can revoke one early if its key is lost or misused. CAs publish revocation status through certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP).
That raises a practical question: what happens to a contract signed today, once the certificate behind it expires? Two more pieces answer it. A trusted timestamp under RFC 3161, issued by a timestamp authority, fixes when the signature was made, so the check becomes whether the certificate was valid at that moment. Long-term validation (LTV) embeds the revocation evidence from that moment in the file, so the check still works when the CA’s services have moved on. Our post on long-term validation goes into both.
How Twala uses PKI
On Twala, nobody needs to buy a certificate or carry a token to sign. Signers sign with Twala’s secure digital signature, and the document as a whole is sealed with certificates that sit in layers:
| Seal | Available on | What it does |
|---|---|---|
| Twala Platform Seal | Every plan | A digital signature with Twala’s X.509 certificate, from Twala’s own certificate authority, over the finished PDF. It is applied last, so it covers every other signature and seal on the file. |
| Business verified digital seal | Business, Business Plus, and Enterprise | The organization’s own verified seal on the documents it sends, applied before the Platform Seal. |
| PKI digital seal | Enterprise | An organization-level PKI seal, for institutions with their own certificate requirements. |
Each signature carries an RFC 3161 timestamp, and long-term validation evidence is embedded when every signature on the document has it. Before sealing, the document is converted to PDF/A-2b, the archival PDF standard.
Because these are standard X.509 signatures, any PDF reader that checks digital signatures, such as Adobe Acrobat, can confirm whether the file has changed since it was sealed. Twala’s verify page goes further: it checks the certificate chain against Twala’s trust registry and traces the document’s fingerprint to its anchor on the Polygon blockchain.
PKI and the law
Philippine law doesn’t require PKI for a valid electronic signature. The Electronic Commerce Act (R.A. 8792) recognizes electronic signatures generally. Where PKI earns its place is in proof. Under Rule 6 of the Supreme Court’s Rules on Electronic Evidence, one way to authenticate an electronic signature is by evidence that a method or process was used to establish a digital signature and verify it. A PKI signature with a trusted timestamp is that method, written into the file itself.
Questions to ask about any platform’s PKI
- Which certificate authority issues the certificates behind your documents, and which readers recognize it?
- Does every signature carry a trusted timestamp?
- Is revocation evidence embedded, so signatures still verify after certificates expire?
- Can our organization seal documents under its own name?
- Can a recipient verify a document without an account, or without the vendor at all?
For the layer that doesn’t depend on any certificate authority, see how HashOrigin anchors documents on a public blockchain. The standards Twala uses are listed on the HashOrigin technology page.
Twala is a Supreme Court-accredited Electronic Notarization Facility (ENF). HashOrigin™ is a trademark of Ohelio Inc.
