Public-key cryptography solves the problem of exchanging secrets without meeting, but it opens another: how do you know that a public key really belongs to whoever claims to own it? If an attacker managed to convince you that their key was your bank's, all the encryption in the world would not protect you. Digital certificates and certificate authorities exist to answer that question.
What a digital certificate is
A certificate is a small electronic document, almost always in the standard X.509 format, which mainly contains:
- the subject, meaning who the key belongs to (a domain name, a person, an organisation);
- the subject's public key;
- the issuer, meaning the authority that issued the certificate;
- the validity period, with start and expiry dates;
- the permitted uses of the key, for example authenticating a web server or signing documents;
- the issuer's digital signature over all this data.
It is the issuer's signature that gives the certificate its value. Whoever receives it verifies that signature and, if they trust the issuer, they also trust the association between subject and public key.
Certificate authorities
A certificate authority (CA) is an entity that verifies the identity of whoever requests a certificate and, if the check succeeds, signs it. The type of check depends on the certificate:
| Type | What is verified |
|---|---|
| DV (Domain Validation) | That the applicant controls the domain |
| OV (Organization Validation) | Also that the organisation exists |
| EV (Extended Validation) | More thorough checks on the organisation |
For websites the most common check is DV: the CA asks you to publish a particular value on a page of the site or in a DNS record, proving control of the domain. Services such as Let's Encrypt have made this process free and fully automatic, which is one of the reasons almost the entire web runs on HTTPS today.
Beware of a common misunderstanding: a DV certificate proves that you are talking to the domain shown, not that the site is honest. Even a phishing site can have a perfectly valid certificate for its deceptive domain.
The chain of trust
CAs do not sign website certificates directly with their most important key. The structure is layered:
- root certificate: self-signed, protected with very strict security measures, often kept offline;
- intermediate certificate: signed by the root and used for day-to-day operations;
- end-entity (leaf) certificate: the one belonging to the site or person, signed by the intermediate.
Your browser and operating system contain a list of trusted root certificates called the root store. When you visit a site, the server presents its own certificate and the intermediate ones; the browser follows the chain up to a root in its list. If the chain is complete and all signatures are valid, the connection is considered authentic.
This structure limits damage: if an intermediate certificate is compromised, it can be revoked without replacing the root on every device in the world.
When a certificate is no longer trustworthy: revocation
A certificate may need to be invalidated before it expires, for example if the site's private key has been stolen. There are two main mechanisms:
- CRL (Certificate Revocation List): lists published by the CA containing revoked certificates;
- OCSP: a service that answers in real time about the status of a single certificate.
In practice revocation has always worked imperfectly, because browsers cannot hold up every connection while waiting for an answer. This is one reason for the trend towards ever shorter certificate lifetimes: a certificate that expires within a few weeks limits the window for abuse if the key is compromised, and encourages automatic renewal.
Certificate Transparency: watching the watchers
The CA system has an obvious weak point: any CA in the root store can, in theory, issue a certificate for any domain. In 2011 the compromise of the Dutch authority DigiNotar led to fraudulent certificates being issued for very well-known domains and to that CA being removed from browsers.
To make abuse visible, Certificate Transparency was created: web certificates must be recorded in public, append-only logs that anyone can consult. A domain owner can therefore check whether someone has obtained a certificate in their name without permission. Free services exist that send an alert when a new certificate appears for your domains: switching them on is good practice.
Practical advice
- Never ignore an invalid-certificate warning on a site where you enter credentials.
- If you run a website, automate certificate renewal to avoid sudden expiries.
- Protect the server's private key with the same care as an administrator password.
- Monitor Certificate Transparency logs for your domains.
In short
- An X.509 certificate links a public key to a subject and is signed by a certificate authority.
- Trust is based on a chain leading back to a root certificate in the root store.
- A valid certificate proves the domain's identity, not the site's honesty.
- Revocation is imperfect, which is why certificate lifetimes keep getting shorter.
- Certificate Transparency makes issued certificates public and helps uncover abuse.
