TLS certificates explained

The padlock in the browser means two separate things: the connection is encrypted, and the server you reached is really the one the name belongs to. Encryption alone would be useless if anyone could pretend to be bank.example; the certificate is what ties the encryption key to the name.

A certificate is a signed statement

A TLS certificate is a small file saying roughly: “the holder of this public key is www.example.com, valid from this date to that date, and we, the issuer, vouch for it.” The issuer, a certificate authority (CA), adds a digital signature. Your browser or operating system ships with a list of trusted CAs (the root store); a certificate counts if it leads back to one of them.

The server has a matching private key. During the TLS handshake it proves it holds that key, and the client checks that the certificate’s name matches the host it asked for, that the dates are valid, that the signature chain is good and that the certificate has not been revoked. Fail any check and you get a browser warning or, in curl, an error such as SSL certificate problem.

The chain

CAs rarely sign server certificates with their root key directly. The root signs an intermediate certificate, and the intermediate signs yours. The server must send its own certificate plus the intermediates (together: the full chain, fullchain.pem in Let’s Encrypt terms); the client supplies the root from its own store. A server that sends only its leaf certificate often works in browsers, which cache intermediates, and fails in command-line tools and mobile apps: the classic “works in Chrome, fails in curl” problem.

What is on the certificate

• Subject Alternative Names (SAN): the host names it is valid for. A certificate for example.com is not valid for www.example.com unless both are listed. A wildcard *.example.com covers one label level, not example.com itself and not a.b.example.com.
• Validity: not before and not after. Let’s Encrypt certificates last 90 days and are meant to be renewed automatically; the industry maximum for publicly trusted certificates is shrinking in steps towards 47 days by 2029, which makes automation mandatory rather than convenient.
• Issuer: which CA signed it.
• Public key and the signature algorithm, today usually ECDSA P-256 or RSA 2048.
• Validation level: domain validated (DV) certificates prove control of the name, which is what Let’s Encrypt issues. OV and EV add checks of the organization, but browsers no longer show them differently.

Read a certificate yourself

# what a server presents, and whether the chain verifies against the local root store
openssl s_client -connect example.com:443 -servername example.com </dev/null

# just the facts
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# a certificate file on disk
openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -text | less

# does this private key belong to this certificate? (compare the two outputs)
openssl x509 -in cert.pem -noout -pubkey | sha256sum
openssl pkey -in privkey.pem -pubout | sha256sum

-servername matters: most servers host several names on one address and pick the certificate based on the name the client sends (SNI). Without it you may get a default certificate and a false alarm. In the s_client output, Verify return code: 0 (ok) means the chain is trusted; unable to get local issuer certificate usually means a missing intermediate on the server or a missing root on your machine.

Self-signed and private CAs

A certificate can sign itself. That gives encryption but no proof of identity, so every client warns. For internal services the better pattern is your own small CA: create one root, install it in the root store of the machines that need it, and sign internal certificates with it. Tools such as mkcert (development) and step-ca (servers) make this painless. Never teach users to click through warnings; once they do it for the internal wiki, they will do it for a phishing site.

Common failures and what they mean

• certificate has expired: renewal did not run. Check the timer or cron job, not the certificate.
• hostname mismatch / NET::ERR_CERT_COMMON_NAME_INVALID: the name you typed is not in the SAN list.
• unable to get local issuer certificate: incomplete chain on the server, or a very old client without the current roots.
• certificate is not yet valid: the client’s clock is wrong.
• self-signed certificate: exactly that; decide whether you trust it out of band.

Official documentation

• Let’s Encrypt: how it works
• openssl-s_client(1)
• openssl-x509(1)