How TLS certificates work

Encrypting a connection is the easy half of HTTPS. The hard half is knowing who is on the other end. An encrypted channel to an impostor protects nothing, so before a browser sends anything it asks the server to prove it really is the site in the address bar. The certificate is that proof.

What a certificate binds together

A certificate is a small signed document that ties a public key to one or more names. In effect it says: the holder of the private key matching this public key is entitled to answer for example.com, and this certificate authority vouches for that until this date.

The fields that matter in practice are few:

• Subject Alternative Name (SAN): the list of hostnames the certificate is valid for.
• Validity: a not-before and a not-after date.
• Public key: the key the server must prove it holds the private half of.
• Issuer: the authority that signed the certificate.
• Signature: the issuer's signature over everything above, so no field can be altered without detection.

The certificate itself is public. Anyone can copy it. What an impostor cannot copy is the private key, and during the TLS handshake the server has to use that key in a way the browser can verify. A valid certificate plus proof of the key is what establishes identity.

The chain of trust

A browser cannot know every website in advance, but it does ship with, or borrows from the operating system, a list of certificate authorities it trusts. These are root certificates. Everything else is checked by following signatures back to one of them.

• The leaf is your site's certificate. It is signed by an intermediate.
• The intermediate belongs to the certificate authority and is signed by its root. There can be more than one in a row.
• The root signs itself and is trusted only because it is in the trust store.

Authorities keep root keys offline and do day-to-day signing with intermediates. If an intermediate is compromised it can be revoked and replaced without touching the root that every device already trusts.

The consequence for anyone running a server: you must send the leaf and the intermediates. The browser already has the root, but it does not necessarily have the intermediate, and without it there is no path from your certificate to something trusted.

What the browser checks

All of these must pass. Any one failing produces a full-page warning.

• The name matches. The hostname in the address bar must appear in the SAN list. Modern browsers ignore the older Common Name field for this. A wildcard entry such as *.example.com covers exactly one label: it matches www.example.com, but not example.com itself and not a.b.example.com.
• The date is inside the validity period, judged by the clock on the visitor's device.
• The chain is complete and every signature in it verifies, ending at a trusted root.
• The certificate has not been revoked. Authorities publish revocations, and browsers consult that information in different ways, often through lists the browser vendor distributes. Coverage is uneven, which is one reason the industry keeps shortening certificate lifetimes: a stolen key stops being useful when the certificate expires, whether or not anyone revoked it.

DV, OV and EV

Certificates differ in how much the authority checked before issuing.

Domain validation (DV) proves control of the domain and nothing else. The applicant shows it by publishing a file on the site, adding a DNS record, or answering email at the domain. It is automated and is what most of the web uses.

Organization validation (OV) and extended validation (EV) add checks on the legal entity behind the request, and put its name in the certificate.

The encryption is the same in all three. Browsers also no longer give OV or EV sites prominent special treatment in the address bar, so most visitors cannot tell the difference. The broader lesson holds for every type: a valid certificate tells you which domain you are connected to. It says nothing about whether the people running that domain are honest. Phishing sites have valid certificates too.

Certificate Transparency

An authority that issues a certificate for the wrong party undermines the whole system, and for a long time nobody outside could see it happen. Certificate Transparency fixes that. Authorities submit the certificates they issue to public, append-only logs, and major browsers refuse certificates that do not come with proof of having been logged.

Two things follow. You can search the logs for your own domain and see every certificate issued for it, including any you did not ask for. And every hostname you put on a certificate becomes public. A name like staging-admin.example.com is not secret once it has a certificate.

CAA: saying who may issue

A CAA record in DNS lists the authorities permitted to issue for your domain. An authority must check it before issuing and refuse if it is not named.

example.com.  3600  IN  CAA  0 issue "ca.example.net"

Browsers do not look at CAA. It narrows who can issue in the first place. It also causes a classic self-inflicted failure: you switch certificate providers, renewal starts failing, and the reason is a CAA record that still names only the old one. The DNS record types guide covers the record's syntax.

When a certificate looks wrong

Start by reading what the server actually sends. This prints the names, issuer and dates of the leaf:

openssl s_client -connect example.com:443 -servername example.com </dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Then match what you see against the usual causes.

• Expired. The not-after date has passed. Almost always automated renewal failed quietly some weeks earlier, or it succeeded and the server was never reloaded to pick up the new file.
• Wrong name. The hostname is not in the SAN list. Common versions: the certificate covers www.example.com but not the bare domain, a new subdomain was never added, or the server is answering with a default certificate that belongs to a different site on the same machine.
• Missing intermediate. The server sends only the leaf. This one is confusing because it fails unevenly. Some browsers can fill the gap on their own, so the site works on your desktop while phones, command-line clients and other software reject it. If only some clients complain, suspect the chain. The fix is to configure the server with the full-chain file your authority provides.
• Untrusted issuer. A self-signed certificate, or one from a private authority the device has never been told to trust.
• Wrong clock. If one device shows a date error on every site, the device's clock is off, not the certificates.

What the checker on this site does

The SSL certificate checker does not connect to your server. It searches public Certificate Transparency logs for the domain you enter, straight from your browser. It lists the certificates it finds with the name, issuer and expiry date of each, marks each one as valid, expired, or expiring within 30 days, and collects every hostname that appears on them.

That makes it the right tool for three questions: when do my certificates run out, has anyone been issued a certificate for my domain that I don't recognize, and which of my hostnames are publicly visible. Keep in mind that “valid” there means only that the expiry date has not passed. Because it reads logs and not your live server, it cannot tell you about a missing intermediate or a server presenting the wrong certificate. For those, use the command above.

A certificate secures the connection. What the site does with it afterwards is a separate matter, and the guide to HTTP security headers picks up from there, starting with the header that tells browsers never to use plain HTTP for your site again.