TLS certificates explained

When you visit a website over HTTPS, your browser uses Transport Layer Security (TLS) to protect the connection. A TLS certificate is a digital document with a signature that links a public key to a website’s name. It helps the browser verify which site it reached and establish a protected connection.

A valid certificate does not prove a website is honest or safe. It shows that the site passed specific checks, such as proving control of its domain. Check the website’s address and claims as well as its HTTPS connection before trusting it.

What a TLS certificate contains

A website certificate contains a public key and information about the names that key is meant to represent. It also identifies the certificate’s issuer and includes dates that mark when the certificate becomes valid and when it expires. The certificate lists website names in a field called Subject Alternative Name.

The public key is one half of a key pair. The server keeps the matching private key secret. During a TLS connection, the server uses the private key to prove it controls the key named in the certificate. In TLS 1.3, the server signs part of the handshake, the exchange that starts the connection. The browser checks that signature.

The certificate itself does not create the encrypted connection. TLS handles encryption and checks whether data has been altered in transit. The certificate helps TLS verify the server’s identity and connect to the right server.

How browsers check certificates

When a browser connects to a site, the server sends its certificate and typically other certificates that link it to an issuer. The browser checks that the certificate covers the requested website name, is within its validity dates, and has a signature it can verify. It also checks the chain of certificates that links the site’s certificate to a trusted certificate, and whether the certificate is suitable for the connection.

A familiar issuer name alone does not make a certificate valid. The browser needs to build a path from the site’s certificate to a trust anchor, a certificate or key the browser or device already accepts. That trust anchor is supplied independently; the server does not have to send it along with the site certificate.

If the browser cannot validate the certificate, it displays a warning or blocks the connection. Common causes include a name mismatch, an expired certificate, or a missing certificate needed to complete the chain. A warning means the browser could not verify the certificate, though it does not by itself show that someone is attacking the connection. Do not enter sensitive information after bypassing one unless you understand and trust the reason for the warning.

Why certificates form a chain

A website’s certificate is often issued by an intermediate certificate authority, an authority between the website and a trusted authority. Another issuer signs that authority’s certificate. These certificates form a chain that leads to a trust anchor the browser accepts.

Think of the chain as a series of signed links between the website’s public key and a source of trust already known to the device. If a server leaves out a needed intermediate certificate, some browsers may fail to build the chain even when the site’s own certificate is valid. The root certificate, which often acts as the trust anchor, is not necessarily sent by the server.

What DV, OV, and EV mean

Certificate authorities use different validation levels to describe what they checked before issuing a public website certificate.

These labels describe identity checks. They do not mean that OV or EV certificates use stronger TLS encryption than DV certificates, and they do not show that a business is trustworthy. A scam site can use an encrypted HTTPS connection, too.

How authorities verify domain control

A certificate authority needs evidence that the applicant controls the domain before issuing a DV certificate. One common approach is to ask the applicant to place a temporary token on the website. The authority checks for that token at a specified address.

Another approach uses DNS, the service that maps domain names to information such as server addresses. The applicant adds a value derived from the token to a DNS record, an entry in the system that maps domain names to information. The authority checks that entry. DNS validation also supports wildcard certificates, which cover a domain and its subdomains. A successful check demonstrates control under the authority’s process; it does not establish who owns the site or whether its business claims are true.

Expiration, renewal, and revocation

Every certificate has a validity period. After its end date, it fails the date check that browsers use to validate certificates. A certificate authority can also revoke a certificate before it expires, for example if its private key is compromised or the certificate was issued incorrectly.

Browsers and other clients do not all handle revocation checks in the same way on every connection. Revocation lets an authority report that a certificate should no longer be trusted. Browsers do not all detect that report immediately.

Site operators need to renew certificates before they expire and install the renewed certificates on the servers that handle traffic. Many use automated renewal to reduce the risk of an outage caused by an expired certificate. Let’s Encrypt, for example, documents ACME, a system that automates certificate issuance and renewal.

What HTTPS does not tell you

HTTPS protects data traveling between your browser and the site named in the address bar. It does not verify that the site’s content is accurate, that its operator is who you expect, or that its business is legitimate.

Before sharing information or making a purchase, check the full domain name. A convincing page on a lookalike address can still have a valid certificate because the operator controls that domain. HTTPS is evidence of a protected connection to that address, not an endorsement of the site.