What Is a TLS Certificate? SSL vs TLS, Setup, Checks, Errors

What is a TLS certificate? It is a small data file, signed by a certificate authority, that binds a domain name to a public key. During the TLS handshake the server presents it so the browser can confirm it is talking to the real site, then both sides agree on keys that encrypt everything that follows.

In short. TLS does three things at once: proves the server is who it claims, agrees a shared key nobody watching can derive, and detects tampering in transit. Most configuration errors weaken exactly one of the three, which is why a connection can be encrypted and still worthless.

HTTPS is simply HTTP carried inside TLS. Browsers label plain HTTP pages as "Not secure", many features (service workers, geolocation, HTTP/2 in browsers) only work over HTTPS, and Google uses HTTPS as a ranking signal. The certificate is the part that makes the whole scheme trustworthy, and it is also the part that expires, breaks and gets misconfigured.

What is inside a TLS certificate

A certificate is an X.509 structure. You can read every field below with the openssl commands later in this guide, or by clicking the site-information icon to the left of the address bar in Chrome, Edge or Firefox and opening the certificate viewer.

Field	What it holds	Why it matters
Subject Alternative Name (SAN)	Every hostname the certificate is valid for, e.g. example.com, www.example.com, *.example.com	Browsers match the address bar against the SAN list only; the old Common Name is ignored
Subject	CN and, for OV/EV, the organization name and country	Shows who the certificate was issued to
Issuer	The CA (usually an intermediate) that signed it	The starting point for building the chain of trust
Validity	notBefore and notAfter dates	Outside this window you get ERR_CERT_DATE_INVALID
Public key	RSA (2048+ bits) or ECDSA (P-256 / P-384)	The matching private key never leaves your server
Key Usage / Extended Key Usage	What the key may be used for, e.g. "TLS Web Server Authentication"	A certificate for client auth or code signing will not work for a website
SCTs	Proofs that the certificate was logged in Certificate Transparency logs	Chrome and Safari reject publicly trusted certificates without them
Signature	The CA's signature over all of the above	Any change to any field invalidates it

What a certificate does not contain is the private key or the session keys. It is public by design: every visitor receives a copy.

Is a TLS certificate the same as an SSL certificate?

Yes. There is no separate "SSL certificate" format: the same X.509 certificate works with any protocol version, and what gets negotiated depends on the server configuration, not on the file you bought. CAs still sell "SSL certificates" because that is the term people search for. SSL (Secure Sockets Layer) is the original protocol created by Netscape in the 1990s; TLS (Transport Layer Security) is its successor, and every SSL version is now prohibited.

Protocol	Year	Status
SSL 2.0	1995	Prohibited (RFC 6176)
SSL 3.0	1996	Prohibited after POODLE (RFC 7568)
TLS 1.0	1999	Deprecated; disabled in major browsers in 2020, formally deprecated by RFC 8996
TLS 1.1	2006	Deprecated; same timeline as TLS 1.0
TLS 1.2	2008	Supported; the practical minimum today
TLS 1.3	2018	Recommended: faster handshake, only forward-secret ciphers (RFC 8446)

So when someone asks "does HTTPS use TLS or SSL", the answer for any correctly configured server is TLS 1.2 or 1.3. If a scan shows SSLv3 or TLS 1.0 still enabled, that is a configuration problem to fix, not a certificate problem. The formal deprecation of the old versions is spelled out in RFC 8996.

Why use TLS instead of SSL?

Because SSL cannot be made safe. SSL 3.0 has a design flaw in its CBC padding (POODLE) that no configuration fixes. TLS 1.2 added authenticated encryption (AES-GCM, ChaCha20-Poly1305) and modern hash functions; TLS 1.3 removed RSA key exchange, static Diffie-Hellman, CBC modes, compression and renegotiation altogether, so a server cannot accidentally negotiate them.

How the TLS handshake works

When establishing an HTTPS connection, the client and server perform a TLS handshake. The certificate appears in step 2 and is checked in step 3; a detailed packet-level walkthrough is in TLS handshake explained step by step.

1. Client Hello — the client sends its supported TLS versions, cipher suites, a random value and the hostname it wants (SNI)
2. Server Hello — the server selects a TLS version and cipher suite, and sends its certificate chain
3. Certificate verification — the client checks the signature chain up to a trusted root, the validity dates, that the hostname is in the SAN list, and Certificate Transparency proofs
4. Key exchange — both parties derive a session key via ephemeral (EC)DHE; the server signs the exchange with its private key to prove it owns the certificate
5. Encrypted connection — all subsequent data is encrypted and integrity-protected with the session keys

TLS 1.3 completes this in a single round trip (1-RTT), and on reconnection it can send data immediately with 0-RTT resumption. Note that the certificate is used only for authentication; with (EC)DHE, stealing the private key later does not decrypt recorded past sessions (forward secrecy).

Certificate types

Types differ in what the CA verified and how many names are covered. Encryption strength is identical across all of them: a free DV certificate encrypts exactly as well as an EV one. The trade-offs are covered in depth in SSL certificate types: DV, OV, EV.

By validation level

Type	What the CA verifies	Issued in	Intended for
DV (Domain Validation)	Control of the domain only (HTTP-01 file, DNS-01 TXT record or email)	Minutes, fully automated	Blogs, SaaS, APIs, most business sites
OV (Organization Validation)	Domain + the legal existence of the organization	Usually days	Business websites, corporate portals, where the organization name must appear in the certificate
EV (Extended Validation)	Full organization vetting under stricter guidelines	Days to weeks	Banks and regulated industries with compliance requirements

Since Chrome 77 and Firefox 70 (2019) browsers no longer show the company name in the address bar for EV, so visitors see no difference between DV and EV unless they open the certificate viewer.

By domain count

• Single-domain — one hostname (example.com; most CAs add www for free)
• Wildcard — a domain's subdomains one level deep (*.example.com covers api.example.com but not example.com itself and not a.b.example.com)
• Multi-Domain (SAN) — several unrelated hostnames in one certificate

How do I get a TLS certificate?

For a public website the fastest route is a free DV certificate from an ACME-based CA such as Let's Encrypt. The process is the same everywhere: generate a key pair, prove to the CA that you control the domain, receive a signed certificate, install it together with the intermediate chain, and automate renewal.

1. Managed platforms (Cloudflare, Vercel, Netlify, most shared hosts) issue and renew certificates automatically once DNS points to them. Check the dashboard before installing anything by hand.
2. Your own server: use an ACME client (certbot, acme.sh, Caddy's built-in client). Step-by-step setup is in free SSL via Let's Encrypt with certbot.
3. OV/EV: create a CSR, submit it to a commercial CA, pass the organization checks, then install the returned certificate and chain.

A minimal certbot run on Debian or Ubuntu with nginx:

# Install certbot and the nginx plugin
apt install certbot python3-certbot-nginx

# Obtain a certificate and let certbot edit the nginx config
certbot --nginx -d example.com -d www.example.com

# Test automatic renewal
certbot renew --dry-run

Certbot configures nginx for HTTPS and installs a systemd timer or cron job for renewal. For a wildcard you must use the DNS-01 challenge, which means a DNS plugin or a manual TXT record.

If you need a CSR for a commercial CA:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Keep example.com.key on the server with permissions 600; only the CSR goes to the CA.

How much does a TLS cert cost?

A DV certificate can cost nothing: Let's Encrypt and ZeroSSL issue them for free, and Cloudflare provides edge certificates on every plan. Browsers trust these exactly as much as paid DV certificates. You pay for organization vetting (OV/EV), vendor support, warranties and management tooling, not for stronger encryption. Compare the real cost carefully: a free 90-day certificate with working automation is cheaper to run than a paid one renewed by hand.

How long is a TLS certificate valid?

Let's Encrypt issues 90-day certificates. For all publicly trusted certificates the CA/Browser Forum is shrinking the maximum lifetime in steps: 200 days for certificates issued from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. The practical conclusion is the same at every step: renewal has to be automated, and expiry has to be monitored, because a renewal job that silently fails is the most common cause of an expired certificate.

Where can I find my TLS certificate?

It depends on whether you are looking at a site you visit or a server you run.

Where	How to find the certificate
Chrome / Edge	Site-information icon left of the URL → "Connection is secure" → "Certificate is valid"
Firefox	Padlock → "Connection secure" → "More information" → "View Certificate"
Safari (macOS)	Click the padlock → "Show Certificate"
nginx	nginx -T | grep -E "ssl_certificate" prints the file paths the running config uses
Apache	grep -Ri "SSLCertificateFile" /etc/apache2 /etc/httpd 2>/dev/null
certbot	certbot certificates; files live in /etc/letsencrypt/live/<domain>/
Windows Server / IIS	certlm.msc → Personal → Certificates, or Get-ChildItem Cert:\LocalMachine\My in PowerShell
macOS	Keychain Access → System or login keychain → Certificates

In the certbot directory, fullchain.pem is the certificate plus intermediates (point ssl_certificate at it), privkey.pem is the private key, and cert.pem is the leaf alone.

Chain of trust

Your site's certificate is signed by an intermediate certificate, which is signed by a root certificate. The browser trusts root CAs from the operating system's or its own built-in store:

Root CA (in the browser's trust store)
  └── Intermediate CA (e.g. Let's Encrypt R11 or E6; names rotate)
        └── Your certificate (example.com)

Important: the server must send the full chain (certificate + intermediate). Desktop Chrome often papers over a missing intermediate by fetching it itself, so the site looks fine in your browser while curl, Java, Python, Android apps and payment webhooks fail with "unable to get local issuer certificate". How to confirm and fix that is in SSL certificate chain: how to verify and fix an incomplete one. Do not send the root itself; clients already have it.

Common certificate errors and what they actually mean

The same problem has a different code in each browser. Clearing the browser cache fixes none of these; the cause is almost always on the server or in the client's clock.

Chrome / Edge	Firefox	Cause	Fix
NET::ERR_CERT_DATE_INVALID	SEC_ERROR_EXPIRED_CERTIFICATE	Certificate expired or not yet valid; or the visitor's clock is wrong	Renew, reload the web server, fix the renewal job; check the device date
NET::ERR_CERT_COMMON_NAME_INVALID	SSL_ERROR_BAD_CERT_DOMAIN	Hostname not in the SAN list (classic case: certificate for example.com, visitor on www)	Reissue with every hostname; check which server block answers
NET::ERR_CERT_AUTHORITY_INVALID	SEC_ERROR_UNKNOWN_ISSUER / MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT	Self-signed certificate, missing intermediate, or a CA not in the trust store; also TLS-inspecting antivirus or corporate proxies	Serve fullchain; use a publicly trusted CA
NET::ERR_CERT_REVOKED	SEC_ERROR_REVOKED_CERTIFICATE	The CA revoked the certificate (key compromise, mis-issuance)	Obtain a new certificate with a new key
ERR_SSL_VERSION_OR_CIPHER_MISMATCH	SSL_ERROR_NO_CYPHER_OVERLAP	No common protocol or cipher; sometimes no certificate configured for this hostname	Enable TLS 1.2/1.3 and modern ciphers; check SNI config

Mixed content

The page is loaded over HTTPS but pulls scripts, styles, images or iframes over HTTP. Browsers block active mixed content (scripts, iframes) outright and try to upgrade images and media to HTTPS, blocking them if that fails; the padlock is lost either way. Fix the source: change every URL to https:// (protocol-relative // URLs are an outdated workaround), and add Content-Security-Policy: upgrade-insecure-requests as a safety net. Finding every offending URL is covered in mixed content: how to find and fix HTTP on HTTPS sites.

A sound nginx configuration

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;   # nginx 1.25.1+; older versions: listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Protocols
    ssl_protocols TLSv1.2 TLSv1.3;

    # TLS 1.2 ciphers (TLS 1.3 suites are always enabled)
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;

    # Session resumption
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # HSTS: start without includeSubDomains/preload, add them once every subdomain has HTTPS
    add_header Strict-Transport-Security "max-age=63072000" always;
}

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Two corrections to configs you will still find online. The http2 parameter on listen is deprecated since nginx 1.25.1 in favor of the http2 directive. And OCSP stapling (ssl_stapling on) does nothing for Let's Encrypt certificates any more: Let's Encrypt ended OCSP support in 2025, and nginx logs "ssl_stapling" ignored, no OCSP responder URL in the certificate. Keep stapling only if your CA still publishes an OCSP URL.

The Apache equivalent (2.4.8+):

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLProtocol -all +TLSv1.2 +TLSv1.3
</VirtualHost>

After any change run nginx -t && systemctl reload nginx (or apachectl configtest && systemctl reload apache2). A renewed certificate on disk is not served until the web server reloads.

How to check a TLS certificate

The quickest way is the enterno.io SSL checker: enter a domain and it shows the issuer, SAN list, expiry date, the chain the server actually sends and the supported protocol versions. The security scanner adds HSTS and other headers. To stop finding out about expiry from your visitors, add the domain to SSL monitoring, which alerts you ahead of the notAfter date.

From the command line:

# Subject, issuer, validity dates and SAN list
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Full chain as sent by the server
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Does the server accept TLS 1.3? TLS 1.2?
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

# Will a local certificate expire within 30 days? (exit code 1 = yes)
openssl x509 -in fullchain.pem -noout -checkend 2592000

# Do the certificate and private key match? The two hashes must be identical
openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in privkey.pem -pubout | openssl sha256

Always pass -servername: without SNI, a server hosting several sites may return a default certificate and you will debug the wrong one. curl -vI https://example.com is a fast second opinion; its verbose output names the negotiated TLS version and the certificate's subject and expiry.

SSL and TLS port numbers

TLS is not tied to one port. Each protocol either uses a dedicated TLS port (implicit TLS) or upgrades a plain connection with STARTTLS.

Service	Port	How TLS starts
HTTPS	443 (also UDP 443 for HTTP/3 over QUIC)	Implicit TLS
SMTP submission	465 / 587	465 implicit TLS; 587 STARTTLS
IMAP / POP3	993 / 995	Implicit TLS
LDAPS	636	Implicit TLS
FTPS (implicit)	990	Implicit TLS
DNS over TLS	853	Implicit TLS

The same certificate rules apply on every port: a mail server on 993 needs its hostname in the SAN and a complete chain exactly like a website does.

TLS vs HTTPS, and SSL vs SSH

TLS vs HTTPS: TLS is the secure channel; HTTPS is one protocol that runs inside it. Mail, databases, LDAP and DNS use TLS too, so "TLS certificate" is the broader term.

SSL vs SSH: unrelated protocols with similar names. SSH (port 22) is for remote shell access and file transfer, and it normally trusts server host keys on first connection instead of CA-signed X.509 certificates. You cannot use a website's TLS certificate for SSH.

FAQ

Has TLS replaced SSL?

Yes. Every SSL version is prohibited by the IETF and disabled in current browsers and servers. "SSL" survives only as a name for certificates and in configuration directives such as nginx's ssl_protocols.

Which is safer, TLS or SSL?

TLS, specifically TLS 1.3 and 1.2. SSL 2.0 and 3.0 have unfixable design flaws, and even TLS 1.0 and 1.1 are deprecated. Disable everything below TLS 1.2.

Is SSL still used?

The protocol is not, on any properly maintained public server. If a scan finds SSLv3 enabled, turn it off. The certificates people call "SSL certificates" are ordinary TLS certificates.

Does HTTPS use TLS or SSL?

TLS. A modern browser negotiates TLS 1.3 or 1.2 and refuses anything older, whatever the certificate was called when you bought it.

Can I use one certificate on several servers?

Yes, as long as each server has the certificate, the chain and the private key, and every hostname is in the SAN list. Many teams prefer issuing a separate certificate per server so a leaked key affects only one machine.

Why does my certificate work in Chrome but not in curl or an app?

Usually a missing intermediate: Chrome can fetch it on its own, most other clients cannot. Point ssl_certificate at fullchain.pem and reload.