This lesson's interactive features are locked, please to keep using them

Certificates and Trust

Encryption isn't helpful if your encrypted connection is with an attacker! In TLS, an X.509 certificate binds a public key to a domain identity. When a browser connects to wikipedia.org, it checks:

wikipedia.org appears in the certificate's Subject Alternative Names
The certificate is currently within its validity period
The certificate chain leads back to a trusted root Certificate Authority (CA)
The server proves it controls the matching private key during the TLS handshake

If any check fails, the browser shows a warning or blocks the connection entirely.

Chain of Trust

Browsers and operating systems maintain root stores containing trusted root CAs. A server's certificate is usually issued by an intermediate CA, which chains back to a trusted root.

A trusted root CA signs an intermediate CA's certificate.
The intermediate CA signs the server's leaf certificate.
The server presents its leaf certificate and required intermediates during the TLS handshake.

A server presents its leaf certificate and the required intermediates so clients can validate the chain without finding additional certificates elsewhere. If the server omits a required intermediate and the client doesn't already have another copy, validation fails even when the leaf certificate is otherwise valid.

Getting and Renewing Certificates

Let's Encrypt issues free certificates through the Automated Certificate Management Environment (ACME) protocol. Certbot is one of the most popular ACME clients.

Public certificates expire, so production servers renew them automatically to prevent outages. If HTTPS terminates at a cloud load balancer or CDN, that infrastructure often handles certificate issuance and renewal for you. If you're running your own VPS or server, you should absolutely set up automated renewal with a cron job or something similar.