How trust is established

Encryption is the easy part. The hard problem is knowing who you are encrypting with. Two systems solve it at different points: TLS for the connection, DNSSEC for name resolution.

What a certificate proves

A TLS certificate confirms that the public key a server presents belongs to exactly this name. It says nothing about whether the website is trustworthy, whether the company is reputable or whether the content is true. It answers a single question: am I really talking to the name I asked for.

The chain

A browser does not know every certificate, only a list of root certificates. From there a chain leads to the server certificate: the root signs an intermediate, the intermediate signs the server’s certificate.

The server has to send the intermediates along. If they are missing, the site still works in a browser that happens to have cached one, and fails in another. That is the cause behind most errors that only affect some visitors.

What is checked before signing

A certificate authority only issues after verifying something. The scope of that verification is the real difference between the products:

Domain validation (DV) checks control over the name only, usually via a DNS record or a file on the server. That takes minutes and can be automated.

Organisation validation (OV) additionally checks that the organisation exists, using official registers. That takes time and involves people, and in return the organisation’s name appears in the certificate.

Lifetime and revocation

Certificates expire, and permitted lifetimes have been getting shorter for years. The reason is the weak spot of the system: revocation before expiry only works if the other side actually checks it, and it does not do so reliably. A short lifetime therefore limits damage more effectively than revocation does. In practice: renewal belongs in automation, not in a calendar.

CAA

A CAA record is a DNS entry stating which certificate authorities may issue for a domain at all. It does not prevent anyone from requesting a certificate, but a compliant authority checks it before issuing and declines if it is not listed.

DNSSEC

TLS secures the connection but not the way there. Anyone who slips in a forged DNS answer redirects the request to a foreign server before TLS even begins.

DNSSEC signs the DNS answers. Every record gets a signature created with the zone’s key, and the level above stores a fingerprint of that key, the DS record. This creates a chain of trust from the root down to the domain, running exactly parallel to delegation.

Caution

The chain is as strict as it sounds. If the key in the zone and the DS record at the registry do not match, the domain is unreachable for every validating resolver, not merely poorly secured. This is why the order of steps matters during a change, and why both should be managed in one place.

How this works in the dash is described under DNSSEC.