When a browser shows a padlock, it has confirmed two things: the connection to the website is encrypted, and the server proved it is entitled to use the domain name in the address bar. The second part is the job of a certificate. People still call these "SSL certificates," but SSL itself is long obsolete; modern connections use TLS, and the certificates are the same kind either way. This guide explains how they work and why they sometimes fail.
What a certificate contains
A TLS certificate is a signed statement that binds a public key to one or more names. The main parts are:
- Subject Alternative Names (SAN): the hostnames the certificate is valid for, such as example.com and www.example.com.
- Public key: the key the server uses to prove its identity.
- Validity period: the "not before" and "not after" dates.
- Issuer: the certificate authority (CA) that signed it.
- Signature: the CA's cryptographic signature over all of the above.
The server keeps the matching private key secret. Anyone can see the certificate, but only the holder of the private key can use it.
The TLS handshake in brief
When you connect to https://www.example.com, the client and server run a short handshake before any web content is exchanged. In TLS 1.3, simplified:
- ClientHello. The browser says which TLS versions and ciphers it supports, sends key-exchange material and includes the hostname it wants in the Server Name Indication (SNI) field, so a server hosting many sites knows which certificate to present.
- ServerHello. The server picks the parameters and sends its own key-exchange material. From here on, the handshake is encrypted.
- Certificate and proof. The server sends its certificate chain and a signature made with its private key, proving it holds that key.
- Verification. The browser checks the chain, the dates and the hostname.
- Finished. Both sides confirm the handshake, and encrypted application data flows.
If verification in step 4 fails, the browser stops and shows a warning.
Certificate chains and authorities
Browsers and operating systems ship with a trust store: a list of root CA certificates they trust. Root keys are precious and kept offline, so CAs issue end-entity certificates from intermediate certificates, which are themselves signed by a root.
A typical chain looks like this:
Leaf: www.example.com (issued by Example Intermediate CA)
Intermediate: Example Intermediate CA (issued by Example Root CA)
Root: Example Root CA (in the client's trust store)
The server should send the leaf certificate and any intermediates. It does not need to send the root, because clients already have it. The client builds a path from the leaf to a trusted root and checks every signature along the way.
Before issuing, a CA must verify that the requester controls the domain, typically by having them publish a DNS record, serve a file over HTTP or respond to email at an administrative address. Domain owners can limit which CAs may issue for them with CAA records (RFC 8659); see Understanding DNS records.
How hostnames are matched
Clients compare the hostname they connected to against the certificate's SAN entries. Modern browsers ignore the older Common Name field for this purpose, so a name missing from the SAN list will not match.
Wildcard certificates cover exactly one label in the leftmost position:
*.example.commatches www.example.com and shop.example.com.- It does not match example.com itself, so the bare domain needs its own SAN entry.
- It does not match a.b.example.com, because the wildcard cannot span two labels.
Expiry and automated renewal
Every certificate has a hard expiry date, and publicly trusted certificates have become steadily shorter-lived. The CA/Browser Forum, the industry body that sets baseline rules for public CAs, has agreed a schedule that gradually lowers the maximum lifetime over the next few years, eventually to under two months. Renewing by hand is no longer realistic.
The standard answer is ACME, the Automatic Certificate Management Environment protocol (RFC 8555). An ACME client on your server or hosting platform requests a certificate, completes the domain-control challenge, installs the result and repeats the process well before expiry. Many CAs, including free ones, support it, and many hosting platforms handle it for you.
Automation removes most expiry incidents but not all. Renewals can still fail silently when DNS changes, a firewall blocks the validation request, a CAA record excludes the CA you use, or a load balancer keeps serving an old certificate. Monitoring expiry dates independently remains worthwhile.
Common certificate errors
Expired certificate
The current date is past the "not after" date. This is usually a failed or forgotten renewal. Occasionally the client's own clock is wrong, which makes a valid certificate appear expired or not yet valid.
Hostname mismatch
The name in the address bar is not in the certificate's SAN list. Typical causes: the certificate covers www.example.com but not example.com; a wildcard was expected to cover the apex or a deeper subdomain; or the server, lacking a matching SNI configuration, presented the certificate for a different site.
Incomplete chain
The server sent the leaf but not the intermediate. Some browsers can fetch or remember missing intermediates, so the site may work in one browser and fail in another, or fail in command-line tools and apps. The fix is to configure the server with the full chain file supplied by the CA.
Self-signed or untrusted issuer
The certificate was signed by itself or by a private CA not in the client's trust store. That is acceptable for internal testing or for systems where you control the trust store, but not for a public website.
Revoked certificate
The CA has withdrawn the certificate before expiry, for example because its private key was exposed. Browser handling of revocation varies, but a revoked certificate should be replaced promptly.
HSTS in one paragraph
HTTP Strict Transport Security (RFC 6797) lets a site tell browsers to use only HTTPS for it in future, via a response header:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Once a browser has seen this, it refuses plain HTTP to that site and does not let users click through certificate warnings. That is good for security, but it means a certificate error on an HSTS site becomes a hard outage. Only enable includeSubDomains, or submit a domain to browser preload lists, when every subdomain is reliably served over valid HTTPS.
Check it yourself
- SSL Checker connects to a host, shows the certificate chain, SAN names and expiry date, and flags mismatches, missing intermediates and untrusted issuers.
- HTTP Status Checker confirms that the site responds correctly over HTTPS and how plain HTTP requests are handled.
- CAA Checker shows which certificate authorities are permitted to issue for your domain, a common reason for a renewal being refused.