EMZETT.Certificate
In short: A digital document that links a public key to an identity (e.g. a domain) and has this link confirmed by a trusted authority.
In more detail: A certificate is digitally signed by a certificate authority (CA). When establishing a TLS connection, the server presents its certificate, and the client checks the signature against a list of trusted CAs (stored in the operating system/browser). This lets the client make sure it’s really talking to the genuine server and not to an attacker (protection against spoofing/man-in-the-middle).
In Depth
At its core, a certificate always contains the same basic components, regardless of the exact format:
- The holder's public key
- The identity being confirmed (e.g. a domain name)
- The validity period (from - to)
- The issuer (which certificate authority signed it)
- The certificate authority's digital signature over all this information
The trust mechanism is based on a chain (certificate chain): a server certificate usually isn’t signed directly by a root CA, but by an “intermediate certificate authority”, whose own certificate was in turn signed by a root CA. The client verifies the entire chain up to a root CA it trusts by default (a fixed list stored in the operating system or browser) — only if the complete chain is unbroken and valid is the connection classified as trustworthy.
There are different levels of verification for how strictly a CA checks identity before issuing: domain validation (DV, only control over the domain is checked, usually automated and free, e.g. with Let’s Encrypt), organisation validation (OV, additionally verifies the organisation’s existence) and extended validation (EV, strictest, manual verification, previously highlighted with a green address bar in the browser, no longer visually distinguished by most browsers today). An expired certificate, or one issued for the wrong domain, makes the browser show a clear warning, since the basic guarantee (“this domain really belongs to this key”) is no longer assured then.
Certificate transparency as an additional layer of control
Because a compromised or malfunctioning certificate authority could theoretically issue a fraudulent certificate for someone else’s domain unnoticed, “certificate transparency” (CT) was introduced: every newly issued certificate additionally has to be published in publicly viewable, cryptographically tamper-proof logs. Domain operators can search these logs and are thereby able to discover certificates issued without authorisation for their own domain, even if the issuing CA doesn’t report the fraud itself. Modern browsers now require CT proof as a precondition for a certificate to be accepted as trustworthy at all — a certificate without a valid CT entry is rejected, even if it would otherwise be technically correctly signed.
Wildcard and multi-domain certificates
For operators with many subdomains, there are practical extensions of the simple single-domain certificate: a wildcard certificate (e.g. for *.emzett-digital.com) covers any number of subdomains of a domain at once, instead of needing a separate certificate for every single subdomain. A SAN certificate (Subject Alternative Name) goes even further and covers several completely different domain names with a single certificate, useful for example for content delivery networks that serve many different customer domains over the same infrastructure. Both variants considerably reduce administrative overhead, but also carry a concentrated risk: if the private key of a wildcard certificate is compromised, potentially ALL subdomains covered by it are affected at once, not just a single one.
See also: Certificate authorities, Signature, TLS