What Is an SSL/TLS Certificate and How Does It Work?

An SSL/TLS certificate is a digital certificate that authenticates a website’s identity to a visitor’s browser. Practically, that means binding a domain name to a public key, so the browser can verify it’s talking to the right server before any protected communication starts. That verification is what your browser’s connection-security indicator reflects.

Most people still call it an “SSL certificate,” though technically that’s outdated. Modern websites run on TLS (Transport Layer Security), the protocol that replaced SSL years ago – the name just never got updated. Which is why you’ll see SSL certificate, TLS certificate, and SSL/TLS certificate used for the same thing today, often in the same sentence.

What Is an SSL/TLS Certificate?

SSL/TLS certificate is a digital credential issued by a Certificate Authority (CA). It carries the domain it covers, its public key, the issuing CA, a validity period, and a few other details the browser reads before deciding whether to trust it.

A valid certificate supports three parts of a secure HTTPS connection:

• Authentication – the browser confirms the certificate is valid for the domain it’s connecting to.
• Protected data in transit – TLS encrypts what passes between browser and server, so intercepted traffic can’t easily be read or altered.
• Trusted connection – the browser and server only proceed to a secure session once that authentication checks out.

The certificate itself isn’t continuously encrypting your site’s traffic. Its role stops at authentication and getting the session started – the actual encrypting happens afterward, once the TLS handshake finishes and temporary symmetric session keys take over.

SSL vs. TLS: What’s the Difference?

SSL stands for Secure Sockets Layer, while TLS stands for Transport Layer Security. SSL was the original protocol developed for securing internet connections. TLS succeeded it and is the protocol used by modern HTTPS websites. SSL 2.0 and SSL 3.0 are obsolete and should no longer be used.

The name, however, stuck. So when a hosting provider, Certificate Authority, or website refers to an “SSL certificate” today, it normally means a certificate used with TLS. You aren’t enabling the obsolete SSL protocol by installing one.

In simple terms:

Types of SSL/TLS Certificates by Domain Coverage

SSL/TLS certificates fall into three types based on domain coverage: single-domain, wildcard, and multi-domain (SAN). Which one you need comes down to whether you’re securing one address, a set of subdomains, or several separate domains at once.

Single-Domain SSL Certificate

A single-domain certificate protects one specified domain or hostname. If you’ve only got one site or endpoint that needs coverage, there’s nothing more to weigh here.

Wildcard SSL Certificate

A Wildcard SSL certificate can protect a domain and multiple first-level subdomains using a wildcard such as:

• *.yourdomain.com

For example, it can cover:

• shop.yourdomain.com
• login.yourdomain.com
• blog.yourdomain.com

This makes a Wildcard certificate useful when many subdomains need to be secured under the same domain.

Multi-Domain SSL Certificate

A Multi-Domain certificate or SAN SSL certificate can include multiple specified domain names in one certificate.

For example:

• yourdomain.com
• yourdomain.net
• store.yourdomain.org

This is useful when several separate domains or services need to be managed under one certificate.

SSL/TLS Certificate Validation Levels

SSL certificates come in three validation levels: Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV); and they answer a different question than domain coverage does. Coverage decides which hostnames a certificate protects; validation level determines what the CA checks before issuing it.

Domain Validation (DV)

DV SSL certificates verify that the applicant controls the domain. Because no organization identity verification is required, issuance can often be completed quickly once domain control is confirmed.

Organization Validation (OV)

OV SSL certificates add organization verification. The CA validates the applicant’s business information in addition to confirming domain control.

Extended Validation (EV)

EV SSL certificates involve more extensive checks of the requesting organization and its authority to obtain the certificate.

None of that changes the encryption. DV, OV and EV do not inherently provide different levels of TLS encryption. Their main difference is the level of identity validation performed before issuance.

What Information Is Inside an SSL/TLS Certificate?

An SSL/TLS certificate is public. Anyone connecting to an HTTPS website can inspect it.

A typical certificate contains:

• the domain name or hostnames it covers;
• organization information, when applicable;
• the Certificate Authority that issued it;
• the certificate’s public key;
• its serial number;
• its validity dates;
• the CA’s digital signature; and
• extensions defining how the certificate can be used.

What it doesn’t include is the private key. That stays with the certificate holder, off the certificate entirely – if it’s ever compromised, the certificate tied to it has to be revoked and reissued.

How Does an SSL/TLS Certificate Work?

An SSL/TLS certificate depends on two mechanisms, not one. Asymmetric cryptography authenticates the server. A separate ephemeral Diffie-Hellman exchange establishes the shared key material. Symmetric encryption takes over once both are done, since it processes far more data per second than public-key cryptography allows.

Each certificate carries a public key. The matching private key stays on the server and never leaves it. The server proves it holds that key, then pairs that proof with an ephemeral Diffie-Hellman exchange to build shared key material, all without sending a secret across the network. Browser and server derive matching symmetric keys from that material. Everything after this point, page content, logins, payment data, moves under those symmetric keys.

The TLS Handshake: Step by Step

The TLS handshake is the sequence a browser and server run through to establish a secure connection, and in TLS 1.3 it works differently than older explanations describe. Static RSA key exchange, where the browser generates a secret and encrypts it directly with the server’s public key was removed from TLS 1.3 entirely.

A typical certificate-authenticated TLS 1.3 handshake runs like this:

1. ClientHello: the browser sends the TLS versions and cryptographic options it supports, along with key-exchange information.
2. ServerHello: the server selects compatible parameters and returns its own key-exchange information. Browser and server can now establish shared key material without sending the resulting secret across the network.
3. Encrypted server messages: the server sends its certificate chain and a signature proving it holds the private key tied to that certificate, both already protected by the handshake traffic keys, not sent in the clear.
4. Browser verification: the browser checks that the certificate is valid for the requested hostname, within its validity period, and linked through a valid chain to a trusted root.
5. Server authentication: the server signs handshake data with the private key associated with its certificate, proving it controls that key.
6. Session keys: browser and server derive matching symmetric keys from the shared key material established during the handshake.
7. Encrypted communication: those session keys protect the application data exchanged from this point forward.

All seven steps normally complete before a user notices any delay.

Certificate Authorities and the Chain of Trust

A Certificate Authority, or CA, is a trusted organization that verifies a domain, and the organization behind it, before issuing an SSL/TLS certificate. Signing that certificate is how the CA vouches for it, and that signature is what browsers trust: Root CA, Intermediate CA, Website Certificate, each link signed by the one before it.

Root CA

A root certificate acts as the trust anchor. Browsers and operating systems distribute trusted root certificates through their own root stores.

Intermediate CA

Certificate Authorities generally issue website certificates through an intermediate CA rather than directly from the root.

Website Certificate

The end-entity certificate; also called the leaf certificate is what’s actually issued for the website and installed on the server.

Browsers check each of these signatures when a certificate arrives, tracing the website certificate to its intermediate and the intermediate to a trusted root. A missing intermediate breaks that chain. So does an expired certificate, a hostname that doesn’t match, or a signature that fails to verify, any one of them is enough to trigger a warning or block the connection outright.

What Is Certificate Revocation?

Certificate revocation is when a CA invalidates a certificate before its scheduled expiration date, most often because a private key has been compromised. A change in domain ownership or a mis-issued certificate can trigger it too.

Browsers confirm revocation status two ways:

• Certificate Revocation Lists (CRLs): a list of revoked certificate serial numbers, published by the CA and downloaded by browsers and clients to check against.
• OCSP (Online Certificate Status Protocol): a real-time query to the CA asking whether one specific certificate is still valid, instead of downloading an entire list.

A certificate that hasn’t been checked against either will still show the padlock, which is why revoking a compromised certificate quickly matters as much as revoking it at all.

Certificate Transparency logs serve a different purpose. They are public records of every certificate a CA issues, and domain owners use them to catch certificates issued for their domain without authorization. They do not revoke anything.

SSL/TLS Certificate Validity

Public TLS certificates issued today can carry a maximum validity of 200 days, down from 398 — a limit set by the CA/Browser Forum’s Baseline Requirements that took effect March 15, 2026, and it’s the current cap as of this writing.

The maximum is scheduled to decrease further:

The CA/Browser Forum recommends CAs issue slightly under each cap – 199, 99, and 46 days – as a buffer against accidentally exceeding the limit.

For website owners and IT teams, this changes the math on renewal. Shorter lifetimes mean more frequent deployment and monitoring, and a certificate that isn’t replaced in time will get the connection rejected outright by browsers and applications alike.

What Does HTTPS Protect?

HTTPS protects data in transit between the client and the TLS endpoint, through three core properties:

• Confidentiality: data traveling across the connection is encrypted.
• Integrity: TLS can detect unauthorized changes to protected traffic.
• Authentication: the client can authenticate the server for the domain it’s visiting.

Together, these cover login credentials, form submissions, payment information, cookies, and API requests as they move across the network.

Does HTTPS Mean a Website Is Safe?

No. A valid SSL certificate tells you about the connection, not the website behind it.

A phishing operator can obtain a valid DV certificate for a domain they control just as easily as a legitimate business can. TLS will connect your browser to that domain securely — the encryption is working exactly as designed. The website itself can still be malicious.

HTTPS isn’t an endorsement of a site’s content, products, downloads, or business practices. It only confirms the connection to that domain is genuine.

How to Install an SSL/TLS Certificate

The exact process depends on the server and hosting environment, but the basic workflow covers seven steps:

1. Choose the appropriate certificate based on the domains you need to protect and the validation level required.
2. Generate a Certificate Signing Request (CSR) and corresponding private key.
3. Submit the CSR and complete CA validation.
4. Install the issued certificate and required intermediate certificates on the server.
5. Enable HTTPS and redirect appropriate HTTP URLs to HTTPS.
6. Test the configuration for certificate-chain, hostname, protocol, and mixed-content problems.
7. Monitor expiration and renewal so the certificate gets replaced before it lapses.

With certificate lifetimes now down to 200 days and headed lower, that last step carries more weight than it used to – automated renewal and deployment stop being optional once you’re managing more than a handful of certificates.

How to Check a Website’s SSL/TLS Certificate

A website’s SSL/TLS certificate can be checked directly through the browser address bar, browser developer tools, or an online SSL checker.

Every browser’s own security indicator opens directly into a certificate viewer, with two or three clicks. It gets you the issuer and validity dates. Here’s how that looks across different browsers:

• Chrome: Click the tune icon left of the address bar. Choose Connection is secure, then open Certificate is valid.
• Firefox: Select the grey shield icon. From there, pick Connection secure, followed by More site information, and finish with View Certificate.
• Edge: Click the padlock in the address bar. Choose Connection is secure, after that, click Certificate is valid.
• Safari: Open the Safari menu bar. Select Connection Security Details, then confirm with Show Certificate.

DevTools shows the certificate one layer deeper, alongside the exact protocol and cipher suite in use. Open Inspect (F12), go to Security, then View certificate.

An SSL checker returns the same fields; issuer, validity dates, SANs, and chain without going through browser menus at all.

Checking your own website takes more than confirming HTTPS loads. Every required hostname needs to be covered, the intermediate chain needs to be configured correctly, renewal needs to be monitored, and obsolete TLS versions need to be disabled.

SSL/TLS Certificate FAQs

Conclusion

A certificate’s role is narrower than people assume: authentication. It confirms a visitor is actually connecting to the server they think they are, and that confirmation is what lets the browser and server set up the encryption that protects the data itself. Certificates aren’t a one-time install either — the maximum lifespan is 200 days now, dropping to 47 by 2029, which puts renewal automation and validity tracking on the list of things that need real attention going forward.

Related Posts:

• How 2-Way SSL Authentication Works & Differs from One-Way SSL?
• HSTS vs HTTPS: Why You Need Both for Web Security
• Self-Signed vs CA-Signed SSL Certificates: Which is Right for Your Website?
• Standard SSL vs. Wildcard SSL Certificates: Which One to Choose for Your Website?