Digital certificates and PKI, explained simply
Public key infrastructure is the machinery behind digital signatures. It is usually described in terms of key pairs and trust chains, which is accurate and unhelpful. Here is the version that explains what you are actually buying.
The problem PKI solves
Suppose you receive a document with a digital signature. The math tells you two things: the document has not been altered since signing, and whoever signed it held a particular private key. What the math cannot tell you is who that person is. Anyone can generate a key pair; nothing about the key itself says "this is Jane Smith of Acme Corp."
A certificate is the bridge. A certificate authority binds a public key to an identity by issuing a signed statement that says, in effect: we checked who this is, and this key belongs to them. Your trust in the signature reduces to your trust in the CA.
What a certificate contains
- The subject's identity — a person, an organisation, or a device
- The public key being certified
- The issuing CA's identity
- A validity period
- A serial number and the permitted uses of the key
- The CA's own digital signature over all of the above
The trust chain
A certificate is usually not signed directly by a root CA. Instead there is a chain: the root CA signs an intermediate CA's certificate, and the intermediate signs yours. Verification walks the chain to a root the verifier already trusts. Operating systems and browsers ship with a set of trusted roots built in. This is why a signature can be verified on a machine that has never contacted the issuer.
The part that matters most: issuance
Cryptography is the reliable part of PKI. Identity proofing is where the real differences live. A certificate issued after a video call with a government ID check supports a much stronger identity claim than one issued after an email confirmation. When comparing digital signature offerings, the question to ask is not "is it cryptographic" but "what did you do to verify the person before issuing the key?"
| Proofing level | Typical method | Identity claim strength |
|---|---|---|
| Email validation | Confirm control of an inbox | Weak |
| Documentary | Photo ID reviewed | Moderate |
| In-person or video verified | ID plus liveness check | Strong |
Under eIDAS, a qualified certificate requires identity verification to a defined standard, which is exactly why the qualified tier carries stronger legal effect.
Where PKI is worth the effort
- Regulated filings that mandate a specific signature type.
- Long-lived records where someone must be able to verify the document decades later, without access to a platform that may no longer exist.
- Software and code distribution, where signing is a supply-chain control.
- High-value transactions where independent third-party verification is a requirement rather than a preference.
- Cross-border EU work requiring a qualified signature.
Where it is not
For an ordinary commercial contract, a well-configured platform signature provides the evidence you need at a fraction of the operational cost. Adding PKI means managing certificate issuance, renewal, revocation, and private key protection — real work, and new ways to fail. If a certificate expires and nobody notices, signatures made with it become harder to validate. Add PKI when a requirement demands it, not as a default.
Related: electronic vs. digital signatures · audit trails