SSL certificates explained: types and full lifecycle

The encryption itself does not need a certificate. What needs one is the question of who you are talking to, and that is the only question a certificate answers.

What a certificate contains

Six things matter to anyone operating a site, and the rest is detail.

• The names it covers

  A list of hostnames the statement applies to. This is the field browsers compare against, and it is the one that causes the most errors when it does not include what someone typed.

• The public key

  The half of a key pair that anyone may hold. The private half never appears in the certificate and never leaves your control.

• The validity period

  A start and an end, after which the statement no longer stands.

• The issuer

  Which authority signed it, which is what connects it to the chain of trust described on certificate chains.

• The signature

  The authority's cryptographic statement over everything above.

• The subject

  Historically the primary identifier, now largely vestigial: browsers read the name list instead, for the reasons on SAN certificates.

What an authority checks before issuing

This is the part that gives a certificate its meaning, and it is narrower than most people assume.

A publicly trusted authority verifies control of the name, and for the common type of certificate that is all it verifies. It does not check who you are, whether your business is legitimate, or whether your site is safe. Demonstrating that you can change what a name resolves to, or place a file where that name serves it, is sufficient.

Two consequences follow.

Anyone who controls a domain can obtain a certificate for it, including someone who obtained that control improperly. A certificate proves control, not virtue.

And whoever controls DNS effectively controls certificate issuance, which is why DNS account security is a certificate concern as much as a naming one.

You can constrain which authorities are permitted to issue for your domain by publishing a record that says so. That record lives in DNS rather than in any certificate, and it is covered on the DNS layer; the certificate side of the arrangement is that compliant authorities check it before issuing and refuse if they are not listed.

The lifecycle

Four stages, and most operational trouble happens at the transitions.

• Request

  You generate a key pair and a signing request stating the names you want covered. What goes into it is on certificate signing requests.

• Validation and issuance

  The authority verifies control and signs.

• Service

  The certificate is installed and presented to clients, along with the intermediate certificates that connect it to a trusted root. That second half is skipped often enough to be the most common installation fault.

• Expiry or replacement

  The statement ends on schedule, or is withdrawn early if it should no longer be trusted. See renewal and revocation.

Choosing between the kinds

Certificates differ along two independent axes, and conflating them is the usual source of confusion.

• By validation

  What the authority checked before issuing: control of the name only, or additional checks about the organisation. The practical differences, and what browsers do and do not display about them, are on certificate types.

• By coverage

  How many names one certificate covers: a single name, a list of names, or one level of subdomains. The trade-offs are on SAN and wildcard certificates.

A certificate has a position on both axes. Asking "should I use a wildcard or an organisation-validated certificate" is asking about two different questions at once.

What certificates do not do

Four things, each of which someone expects and none of which is true.

A certificate does not make a site trustworthy. It states that the name is controlled by whoever holds the key, which says nothing about their intentions.

It does not protect the server. Compromise of the machine is unaffected by the certificate on it, and a compromised server serves attacker content over a perfectly valid encrypted connection.

It does not encrypt anything by itself. The encryption comes from the protocol; the certificate lets you know who you negotiated it with.

And it does not confirm identity in the everyday sense unless the authority checked identity, which for the common type it did not.

Why validity periods keep getting shorter

Certificates have become shorter-lived over the years, and the reasoning is straightforward: revocation does not work reliably. When a certificate must be withdrawn early, telling every client in time is not something the system does well, so the alternative is to limit how long any certificate remains valid in the first place. A short lifetime achieves by expiry what revocation is supposed to achieve by announcement, and it requires no client to check anything.

The consequence for operators is a shift in what counts as normal. Manual renewal was a plausible practice when certificates lasted a long time; at current lifetimes it is a recurring task with a deadline that produces an outage when missed, and the only sane response is automation.

That is also why questions of the form "how long should I buy for" have become less interesting. The maximum permitted period is set by the rules authorities operate under and has moved several times; building a process that does not care what the number is protects you from the next change.

Reading a certificate yourself

Every browser lets you inspect the certificate a site presents, through the padlock or the warning page. The fields above are all visible there, and the two worth reading first are the name list and the validity period, because they account for most errors.

For a certificate you hold as a file rather than one being served, a decoder tool renders the same fields in readable form, which is faster than interpreting the encoded original.

FAQ