SSL/TLS Certificates Explained

Every time you visit a website that starts with https://, an SSL/TLS certificate is working behind the scenes. It encrypts the connection between your browser and the server, verifies the server's identity, and ensures data cannot be tampered with in transit. This guide covers how certificates work, the different types, how the trust chain operates, and how to get and maintain a certificate for your own domain.

1. What is SSL/TLS?

The short version

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that encrypt communication between a client (usually a browser) and a server. TLS is the modern successor to SSL. SSL 2.0 and 3.0 are deprecated and insecure, and even TLS 1.0 and 1.1 are no longer supported by major browsers. Today, TLS 1.2 and TLS 1.3 are the standards.

What it protects

• Confidentiality - encrypts data so eavesdroppers on the network cannot read it
• Integrity - detects any tampering or modification of data in transit
• Authentication - proves the server is who it claims to be, preventing impersonation

Why the name "SSL" stuck

Even though SSL itself is obsolete, the industry still uses "SSL certificate" as a generic term. When someone says "SSL certificate," they almost always mean a certificate used with TLS. The two terms are used interchangeably in practice.

2. How certificates work

The TLS handshake

When your browser connects to a server over HTTPS, a TLS handshake occurs before any data is exchanged:

1. Client Hello - your browser sends the TLS versions and cipher suites it supports
2. Server Hello - the server picks a TLS version and cipher suite, then sends its certificate
3. Certificate verification - your browser checks that the certificate is valid, not expired, and issued by a trusted Certificate Authority (CA)
4. Key exchange - both sides generate a shared session key using asymmetric cryptography (in TLS 1.3, this uses Diffie-Hellman)
5. Encrypted session - all subsequent data is encrypted with the shared session key using symmetric encryption

What a certificate contains

• Subject - the domain name (e.g. www.example.com) the certificate is issued for
• Issuer - the Certificate Authority that signed the certificate
• Public key - the server's public key, used during the handshake
• Validity period - the "Not Before" and "Not After" dates
• Subject Alternative Names (SANs) - additional domain names covered by the certificate
• Signature - the CA's cryptographic signature proving the certificate is authentic

3. Certificate types: DV, OV, and EV

Certificate Authorities offer three validation levels. All three provide the same encryption strength. The difference is how much the CA verifies about the certificate requester.

For most websites, a DV certificate is sufficient. Browsers no longer display the green address bar for EV certificates (this was removed in 2019), so the visible difference between DV and EV is minimal to end users. The encryption is identical regardless of type.

Wildcard and multi-domain certificates

• Wildcard - covers a domain and all single-level subdomains (e.g. *.example.com covers www.example.com, api.example.com, etc.)
• Multi-domain (SAN) - a single certificate that lists multiple distinct domains in the Subject Alternative Names field

4. Certificate chains and trust

How trust works

Your browser does not trust your server's certificate directly. Instead, it follows a chain of trust:

1. Root CA certificate - a self-signed certificate pre-installed in your browser or operating system's trust store. Root CAs are a small set of highly audited organizations.
2. Intermediate CA certificate - signed by the root CA. Intermediates issue the actual server certificates. This layer protects the root key (if an intermediate is compromised, only that intermediate is revoked, not the root).
3. Server (leaf) certificate - your domain's certificate, signed by the intermediate CA.

Your browser validates the chain by checking that each certificate's signature was made by the certificate above it, all the way up to a root it trusts. If any link in the chain is missing, expired, or revoked, the connection fails.

Common chain problems

• Missing intermediate - the server only sends the leaf certificate, and the browser cannot build the chain. This causes trust errors in some browsers but not others.
• Wrong order - intermediates are sent in the wrong order, confusing some TLS implementations
• Expired intermediate - the intermediate CA certificate has expired, breaking the chain even if the leaf certificate is still valid

Use the free certificate chain checker to verify your server sends the correct chain.

5. How to get a certificate

Let's Encrypt (free, automated)

Let's Encrypt is a free, automated Certificate Authority that issues DV certificates. It uses the ACME protocol to verify domain ownership and issue certificates without manual intervention. Certificates are valid for 90 days and should be renewed automatically using a client like certbot.

Certbot handles renewal automatically via a systemd timer or cron job. Most hosting providers (Vercel, Netlify, Cloudflare, AWS) also provision Let's Encrypt certificates automatically with zero configuration.

CDN and hosting providers

If you use Cloudflare, AWS CloudFront, Vercel, or similar services, they provision and renew certificates for you automatically. In most cases, you do not need to install or manage a certificate yourself. Just point your DNS to the provider and enable HTTPS.

Commercial CAs

For OV or EV certificates, or for organizations that need specific features (warranty, dedicated support, longer validity on some platforms), commercial CAs like DigiCert, Sectigo, and GlobalSign are common choices. The process typically involves:

1. Generate a Certificate Signing Request (CSR) on your server
2. Submit the CSR to the CA along with organization documentation
3. Complete domain validation (DNS or email)
4. Receive the signed certificate and install it on your server

6. Common SSL/TLS errors and how to fix them

7. SSL/TLS best practices

• Automate renewal - expired certificates are the most common cause of SSL errors. Use Let's Encrypt with auto-renewal or a provider that handles it for you.
• Use TLS 1.2 and 1.3 only - disable TLS 1.0, TLS 1.1, and all SSL versions. They have known vulnerabilities and are no longer supported by modern browsers.
• Enable HSTS - forces browsers to always connect over HTTPS, preventing downgrade attacks. Consider HSTS preloading for maximum protection.
• Send the full chain - always configure your server to send the leaf certificate plus all intermediate certificates. Omitting intermediates causes trust failures in some browsers.
• Use strong cipher suites - prefer ECDHE key exchange and AES-GCM or ChaCha20-Poly1305 encryption. Disable RC4, 3DES, and CBC-mode ciphers.
• Monitor your certificate - set up monitoring to alert you before your certificate expires. Run regular scans to catch configuration drift.
• Enable CAA records - DNS CAA records specify which CAs are allowed to issue certificates for your domain, reducing the risk of mis-issuance.
• Use OCSP stapling - your server can attach a signed OCSP response to the TLS handshake, allowing the browser to verify the certificate has not been revoked without making an extra request to the CA.

Check your SSL certificate

Use the free SSL checker to test your certificate, protocol versions, and cipher suites. Check your certificate chain to make sure intermediates are configured correctly. Or run a full domain scan to audit SSL alongside DNS, email authentication, headers, and more.