How SSL Certificates Work: Chain of Trust Explained

The padlock in the address bar means two things: the connection is encrypted, and the browser is satisfied that it is talking to the real owner of the domain. Encryption comes from the TLS protocol. Proof of identity comes from the certificate. "SSL certificate" is the older name that stuck—SSL itself was retired years ago, and every modern site uses TLS.

What a certificate says

A certificate is a small signed document. Its important parts are:

• The names it covers, listed in the Subject Alternative Name (SAN) field: for example example.com and www.example.com, or a wildcard such as *.example.com.
• A public key, whose matching private key stays on your server.
• A validity period: a "not before" and "not after" date.
• The issuer: the certificate authority (CA) that vouches for it, and that CA's signature.

In effect the CA is saying: "We checked that whoever requested this certificate controls these domain names, and this public key belongs to them, until this date."

The handshake, briefly

When a browser connects to https://example.com:

1. It opens a connection to port 443 and says which hostname it wants (this is called SNI, and it lets one server host certificates for many sites).
2. The server replies with its certificate and the intermediate certificates that link it to a trusted root.
3. The server proves it holds the private key for that certificate.
4. Both sides agree on encryption keys, and the page loads over the encrypted connection.

With TLS 1.3 this takes a single round trip. Older TLS 1.2 needs two, which is one reason TLS 1.3 feels faster.

The chain of trust: root and intermediate certificates

Browsers and operating systems ship with a short list of root certificates—a few hundred CAs they trust. Roots are kept offline and rarely sign site certificates directly. Instead they sign intermediate certificates, which sign your certificate:

Root CA (in the browser's trust store)
  └─ Intermediate CA (sent by your server)
       └─ example.com (sent by your server)

Your server must send its own certificate and the intermediates. The root is already on the visitor's device. Forgetting the intermediate is one of the most common configuration mistakes—see common SSL certificate errors.

What the browser checks

Before trusting a connection, a browser verifies that:

• the hostname in the address bar appears in the certificate's SAN list (a wildcard covers exactly one label, so *.example.com covers shop.example.com but not example.com or a.b.example.com);
• every certificate in the chain is within its validity period;
• each certificate is correctly signed by the next, ending at a trusted root;
• the certificate hasn't been revoked and meets current rules for key size, algorithms and maximum lifetime.

Any failure produces a full-page warning. Most visitors leave, and API clients and apps simply refuse to connect.

Types of certificate: DV vs OV vs EV

All certificates encrypt equally well. They differ in what the CA checked before issuing:

• Domain validated (DV): the requester proved control of the domain, usually automatically through a DNS record or a file on the web server. This is what Let's Encrypt and most automated services issue, and it is what nearly all sites use.
• Organization (OV) and extended validation (EV): the CA also verified the company behind the domain. Browsers no longer display this prominently, so the practical benefit for visitors is small.

Keys and algorithms

Modern certificates use either an ECDSA P-256 key (small and fast) or an RSA key of at least 2048 bits. Signatures use SHA-256 or stronger; SHA-1 signatures are rejected by browsers.

Check a site

The SSL Certificate Checker connects the way a browser does and shows the names, chain, expiry date, key and TLS versions—and explains anything that would cause a warning.