What Is an SSL Certificate? TLS, HTTPS, and Trust Explained

Every time you see https:// in your browser, an SSL/TLS certificate is working behind the scenes. Despite the name — SSL certificates are now universally implemented with TLS — the term has stuck. Understanding how they work helps you configure them correctly, diagnose errors, and evaluate a site’s trustworthiness.

What an SSL Certificate Does

An SSL certificate serves two functions:

1. Authentication: Proves that the server you’re connecting to actually controls the domain in the address bar. A Certificate Authority (CA) has verified this claim and cryptographically signed the certificate.

2. Encryption: Enables TLS — the protocol that encrypts all data between your browser and the server. Without TLS, your passwords, credit card numbers, and session cookies travel in plaintext.

Without HTTPS:                    With HTTPS:
Browser ─── plaintext ──▶ Server  Browser ─── encrypted ──▶ Server
       ◀── plaintext ───          Server  ◀── encrypted ───
       (anyone on the path        (only browser and server
        can read this)             can decrypt)

How TLS Handshake Works

Before encrypted data flows, browser and server perform a handshake:

1. Client Hello  → Browser sends: TLS version, cipher suites supported, random byte string
2. Server Hello  ← Server sends: chosen cipher suite, its SSL certificate, random byte string
3. Certificate   ← Browser verifies certificate against trusted CAs
4. Key Exchange  ↔ Both parties derive the same session key (without transmitting it)
5. Finished      ↔ Encryption begins — all subsequent data is encrypted

This is TLS 1.3’s simplified 1-RTT handshake. TLS 1.2 requires 2 round trips, which is why TLS 1.3 is faster.

What’s Inside a Certificate

A certificate is a structured data file (X.509 format) containing:

Subject:        CN=example.com, O=Example Inc, C=US
Issuer:         DigiCert Inc (the CA that signed it)
Valid From:     2026-01-01
Valid To:       2026-12-31
Subject Alt Names (SAN):
  DNS:example.com
  DNS:www.example.com
  DNS:api.example.com
Public Key:     RSA 2048-bit / ECDSA P-256
Signature:      CA's digital signature over the above data

The Subject Alternative Name (SAN) extension lists all hostnames the certificate is valid for. Modern certificates use SANs rather than the older CN field.

Certificate Types

By Validation Level

DV certificates from Let’s Encrypt are free and appropriate for most sites. EV certificates cost hundreds of dollars annually and provide diminishing differentiation — Chrome and Firefox removed the visual EV indicator in 2019.

By Coverage

Wildcards cover one level: *.example.com covers www.example.com and api.example.com but not sub.api.example.com.

Certificate Authorities and Trust

Browsers ship with a built-in list of trusted root Certificate Authorities (CAs) — about 100-150 root CAs. Any certificate signed by a trusted root (directly or via intermediate CAs) is trusted by the browser.

Chain of trust:

Root CA (trusted by browsers, stored in OS/browser)
    └─ Intermediate CA (issued by Root CA)
           └─ Your certificate (issued by Intermediate CA)

Your server must send both your certificate and the intermediate certificate(s). Missing intermediates cause SSL errors on some clients.

Major public CAs:

Getting a Free Certificate with Let’s Encrypt

# Install certbot (Ubuntu/Debian)
sudo apt install certbot python3-certbot-nginx

# Obtain and install certificate for Nginx
sudo certbot --nginx -d example.com -d www.example.com

# Test auto-renewal
sudo certbot renew --dry-run

# View certificate details
sudo certbot certificates

Certbot installs a cron job or systemd timer that renews certificates automatically before expiry. No manual renewal needed.

Alternative: Caddy (auto-HTTPS by default)

# Caddyfile — that's it, Caddy handles everything
example.com {
    root * /var/www/html
    file_server
}

Checking a Certificate

# Via openssl
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | \
  openssl x509 -text -noout | grep -E "Subject:|Not After|DNS:"

# Quick expiry check
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# Check full chain
openssl s_client -connect example.com:443 -showcerts < /dev/null 2>/dev/null

In Chrome: click the padlock → Connection is secure → Certificate is valid → Details tab shows all SAN entries, issuer, and expiry date.

Common SSL Errors

TLS Configuration Best Practices

# Nginx — modern TLS config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

# HSTS — tell browsers to always use HTTPS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# OCSP stapling — faster certificate validation
ssl_stapling on;
ssl_stapling_verify on;

Test your TLS configuration at SSL Labs (ssllabs.com/ssltest/) — it grades cipher suites, protocol versions, HSTS, and more.

Certificate Transparency

All publicly trusted certificates must be logged in public Certificate Transparency (CT) logs. This means:

• Every certificate issued for your domain is publicly auditable
• You can monitor for unauthorized certificates via crt.sh or Google CT Log
• Misissuance (rogue CAs issuing certificates for your domain) is detectable

# Find all certificates ever issued for example.com
curl -s "https://crt.sh/?q=example.com&output=json" | jq '.[].name_value' | sort -u

Set up monitoring via crt.sh email alerts or services like Cert Spotter to be notified when new certificates are issued for your domain.

Summary

SSL/TLS certificates authenticate servers and enable encrypted connections. DV certificates from Let’s Encrypt are free, automated, and sufficient for most sites. Configure TLS 1.2+, enable HSTS, automate renewal, and monitor CT logs for unexpected issuance. The padlock means the connection is encrypted — it doesn’t mean the site is trustworthy. Always read the domain.