An SSL/TLS certificate is a digital document that proves a website's identity and lets your browser set up an encrypted HTTPS connection with it. It binds a domain name to a public key and is signed by a certificate authority (CA) that browsers already trust.
Whenever you see https:// and a padlock or similar indicator in the address bar, a certificate was checked a fraction of a second earlier. Certificates do two jobs at once: they authenticate the server, so you know you are talking to the real example.com and not an impostor, and they enable encryption, so nobody on the network path can read or alter what you send.
SSL vs TLS: what is the difference?
SSL (Secure Sockets Layer) was the original protocol, developed by Netscape in the 1990s. It was succeeded by TLS (Transport Layer Security), and every version of SSL is now considered insecure and has been formally deprecated. TLS 1.0 and 1.1 were deprecated too, in RFC 8996 (2021), so modern connections use TLS 1.2 or TLS 1.3.
The name "SSL certificate" stuck, however. The certificate itself is not tied to a protocol version; the same certificate works with any TLS version. "SSL certificate", "TLS certificate" and "HTTPS certificate" all mean the same thing.
How the TLS handshake works
Before any web page data is exchanged, the browser and server perform a handshake. Simplified, a TLS 1.3 handshake looks like this:
- Client hello. The browser connects, usually on port 443, and says which TLS versions and cipher suites it supports. It includes the hostname it wants (via the Server Name Indication extension, so one IP address can host many sites) and its share of a key exchange.
- Server hello. The server picks the parameters, sends its own key share, and presents its certificate along with a signature proving it holds the matching private key.
- Verification. The browser checks that the certificate covers the hostname, is within its validity dates, and chains up to a trusted root CA.
- Session keys. Both sides derive the same symmetric session keys from the key exchange. All further traffic is encrypted with them.
The private key never leaves the server. Public key cryptography is used only to authenticate and agree on keys; the bulk data is encrypted with fast symmetric ciphers such as AES-GCM or ChaCha20-Poly1305. TLS 1.3 completes this in a single round trip, compared with two for TLS 1.2.
What is inside a certificate
A certificate follows the X.509 standard and contains, among other fields:
- Subject Alternative Names (SANs): the hostnames the certificate is valid for. Browsers check this list, not the older Common Name field.
- Public key: the server's RSA or ECDSA public key.
- Issuer: the CA that signed the certificate.
- Validity period: "Not Before" and "Not After" dates.
- Serial number and signature: a unique identifier and the issuer's signature over all of the above.
SAN and wildcard certificates
A single certificate can cover many names by listing them as SANs, for example example.com, www.example.com and shop.example.com. A wildcard such as *.example.com covers any single label at that level, so it matches www.example.com and api.example.com, but not example.com itself and not deeper names like a.b.example.com. That is why wildcard certificates usually list the bare domain as an extra SAN.
DV, OV and EV certificates
Certificates differ in how thoroughly the CA checked the applicant before issuing:
| Type | What is verified | Typical use |
|---|---|---|
| Domain Validated (DV) | Only that the applicant controls the domain, via a DNS record, a file on the website or an email | Most websites; issued automatically in seconds |
| Organization Validated (OV) | Domain control plus the organization's legal existence | Businesses that want the company name in certificate details |
| Extended Validation (EV) | A stricter, standardized check of the legal entity | Some banks and large companies |
All three provide exactly the same encryption strength. The difference is only in identity information. Major browsers stopped giving EV certificates a special green company-name display around 2019, so for most sites a DV certificate is the practical choice.
The chain of trust
Your operating system and browser ship with a root store: a list of root CA certificates they trust. Root CAs rarely sign website certificates directly. Instead, they sign intermediate certificates, which sign the leaf (server) certificate:
Root CA (in the browser's trust store)
└── Intermediate CA (sent by the server)
└── www.example.com (leaf certificate, sent by the server)The server must send its leaf certificate and the intermediates. The browser then verifies each signature up to a root it already trusts. This arrangement lets root keys stay offline and well protected. To guard against mis-issuance, publicly trusted certificates are also logged in public Certificate Transparency logs, and domain owners can restrict which CAs may issue for them with a CAA DNS record, described in our guide to DNS record types.
Let's Encrypt and certificate lifetimes
Let's Encrypt, a nonprofit CA, made free DV certificates mainstream. Its certificates are valid for 90 days and are designed to be renewed automatically using the ACME protocol, with clients such as Certbot or features built into many web servers and hosting panels. Most hosting providers and CDNs now issue and renew certificates without any manual steps.
Lifetimes across the industry are getting shorter. Under CA/Browser Forum ballot SC-081, the maximum validity of publicly trusted TLS certificates is being reduced in stages, starting with 200 days from March 2026 and stepping down further in later years. The exact schedule may still evolve, but the direction is clear: automate renewal, because manually renewing certificates will become increasingly impractical.
Common certificate errors and how to fix them
Expired certificate
Browsers show errors such as NET::ERR_CERT_DATE_INVALID. Renew the certificate and reload the web server. Then find out why automatic renewal failed, which is often a firewall blocking validation, a DNS change or a broken cron job. An incorrect clock on the visitor's device can cause the same error, so check the date if only one device complains.
Name mismatch
Errors like ERR_CERT_COMMON_NAME_INVALID mean the hostname in the address bar is not in the certificate's SAN list, such as a certificate for www.example.com being served for example.com. Reissue the certificate to include every hostname you serve, or redirect visitors to a covered name.
Incomplete chain
If the server sends only the leaf certificate without its intermediates, some browsers cope by fetching or caching the missing piece while others, along with many command-line tools and apps, fail. Configure the server with the full chain file (often called fullchain.pem).
Self-signed or untrusted issuer
NET::ERR_CERT_AUTHORITY_INVALID means the chain does not lead to a trusted root, typically because the certificate is self-signed or from a private CA. That is fine for internal testing but not for a public site; replace it with a certificate from a public CA. The same error can appear when antivirus software or a corporate proxy intercepts HTTPS.
Mixed content
The certificate is valid, but the page loads scripts or images over plain http://. Update those URLs to HTTPS, and consider an HSTS header so browsers always use HTTPS.
openssl s_client -connect example.com:443 -servername example.com prints the full chain the server sends.Frequently asked questions
Does HTTPS mean a website is safe?
No. HTTPS means your connection to the site is encrypted and the site controls the domain shown. Phishing sites can and do have valid DV certificates. Always check the domain name itself.
Are free certificates less secure than paid ones?
No. A free DV certificate from Let's Encrypt provides the same encryption as a paid one. Paid certificates may add identity validation (OV/EV), warranties or support, but not stronger encryption.
How long does an SSL certificate last?
Let's Encrypt certificates last 90 days. Other public CAs are bound by the CA/Browser Forum maximum, which is being shortened in stages from 200 days in 2026. Automated renewal is the safest approach.
Which port does HTTPS use?
HTTPS uses TCP port 443 by default, while plain HTTP uses port 80. See our guide to common network ports for more.