What Is SSL/TLS? A Complete Guide to HTTPS Encryption

Last Updated: October 2026

What Are SSL and TLS?

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that provide encrypted communication between a client (typically a web browser) and a server. When you see https:// in a URL and a padlock icon in your browser's address bar, the connection is secured by TLS.

These protocols protect three critical aspects of online communication. Confidentiality ensures that data cannot be read by anyone intercepting the traffic. Integrity ensures that data cannot be altered in transit without detection. Authentication ensures that you are communicating with the legitimate server and not an impostor.

Although the terms SSL and TLS are often used interchangeably, they are technically different protocols. SSL was developed by Netscape in the mid-1990s and went through three versions (1.0, 2.0, and 3.0). TLS was introduced as the IETF-standardized successor to SSL 3.0 and has since undergone its own evolution. Today, all versions of SSL are considered insecure and have been deprecated. When people refer to "SSL certificates" or "SSL encryption," they are almost always referring to TLS.

History: From SSL 2.0 to TLS 1.3

Understanding the evolution of these protocols helps explain why certain versions are no longer safe to use and why upgrading to TLS 1.3 is important.

SSL 1.0 (1994 — Never Released)

Netscape developed the first version of SSL but never released it publicly because of fundamental security flaws discovered during internal review. It never saw production use.

SSL 2.0 (1995)

The first publicly released version. It introduced the concept of certificate-based authentication and symmetric key encryption for web traffic. However, it had serious design weaknesses including susceptibility to man-in-the-middle attacks, weak MAC construction, and the ability for an attacker to force the use of weaker ciphers. SSL 2.0 was formally deprecated in 2011 (RFC 6176).

SSL 3.0 (1996)

A complete redesign that addressed many of SSL 2.0's vulnerabilities. It served as the foundation for TLS 1.0. However, the POODLE attack discovered in 2014 (CVE-2014-3566) exploited a fundamental flaw in SSL 3.0's block cipher padding, making it insecure. SSL 3.0 was deprecated in 2015 (RFC 7568).

TLS 1.0 (1999 — RFC 2246)

The first version standardized by the IETF. While similar to SSL 3.0, it included improvements to the MAC computation and key derivation. TLS 1.0 is vulnerable to the BEAST attack and was deprecated in 2021 (RFC 8996). Major browsers dropped support in 2020.

TLS 1.1 (2006 — RFC 4346)

Added protection against CBC attacks by introducing explicit initialization vectors and changed the handling of padding errors. Despite these improvements, TLS 1.1 lacks support for modern authenticated encryption ciphers like AES-GCM and was deprecated alongside TLS 1.0 in 2021.

TLS 1.2 (2008 — RFC 5246)

Introduced support for authenticated encryption (AEAD) cipher suites like AES-GCM, SHA-256 as the default hash for the PRF, and configurable signature algorithms. TLS 1.2 remains widely supported and is still considered secure when configured with modern cipher suites. However, its handshake is more complex and slower than TLS 1.3.

TLS 1.3 (2018 — RFC 8446)

The current standard. TLS 1.3 represents a major simplification: it removed support for legacy algorithms (RSA key exchange, CBC mode ciphers, RC4, SHA-1, MD5, export ciphers), reduced the handshake from two round-trips to one (and supports 0-RTT resumption), and mandates forward secrecy through ephemeral Diffie-Hellman key exchange. The result is a faster, simpler, and significantly more secure protocol.

How the TLS Handshake Works

Before any encrypted data can be exchanged, the client and server must agree on encryption parameters through a process called the TLS handshake. This handshake authenticates the server (and optionally the client), negotiates a shared encryption key, and establishes the secure session. Here is how it works in TLS 1.3:

TLS 1.3 Handshake (1-RTT)

1. Client Hello: The client sends a message containing the TLS version it supports, a list of supported cipher suites (e.g., TLS_AES_256_GCM_SHA384), supported key exchange groups (e.g., x25519, secp256r1), and a key share — the client's half of the Diffie-Hellman exchange. This is the critical difference from TLS 1.2: the client sends its key share immediately, without waiting to learn the server's preferences.
2. Server Hello + Encrypted Extensions: The server selects a cipher suite and key exchange group, sends its own key share, and generates the shared secret. From this point forward, all communication is encrypted. The server also sends its certificate, a Certificate Verify message (proving it holds the private key for the certificate), and a Finished message.
3. Client Finished: The client verifies the server's certificate against its trust store, verifies the Certificate Verify signature, completes its own key derivation, and sends a Finished message. The handshake is now complete.
4. Application Data: Both sides can now exchange encrypted application data (HTTP requests and responses).

TLS 1.2 Handshake (2-RTT)

The TLS 1.2 handshake requires two round-trips. The Client Hello and Server Hello occur in the first round-trip to negotiate parameters. The key exchange, certificate verification, and Finished messages occur in the second round-trip. This makes the TLS 1.2 handshake noticeably slower, especially on high-latency connections. TLS 1.2 also allows RSA key exchange (where the client encrypts the pre-master secret with the server's public key), which does not provide forward secrecy.

0-RTT Resumption

TLS 1.3 supports 0-RTT (zero round-trip time) resumption for clients that have previously connected to a server. Using a pre-shared key (PSK) from a prior session, the client can send encrypted application data in the very first message. This eliminates the handshake latency entirely for returning visitors. However, 0-RTT data is vulnerable to replay attacks, so it should only be used for idempotent requests (like GET) and servers must implement replay protection.

SSL/TLS Certificates Explained

An SSL/TLS certificate is a digital document that binds a public key to a domain name (and optionally an organization). Certificates are issued by Certificate Authorities (CAs) after verifying that the applicant controls the domain. When your browser connects to a website, the server presents its certificate so the browser can verify the site's identity before establishing an encrypted connection.

Validation Levels

Certificates differ primarily in how much verification the CA performs before issuing them:

Domain Validation (DV)

The CA verifies only that the applicant controls the domain, typically through an email challenge, DNS record, or HTTP file challenge. DV certificates are issued in minutes, are the least expensive (often free via Let's Encrypt), and display a padlock in the browser. They are ideal for blogs, personal sites, and small business websites where organizational identity verification is not required.

Organization Validation (OV)

In addition to domain control, the CA verifies the legal identity of the organization (business name, address, registration). OV certificates take one to three days to issue and display the organization name in the certificate details (though not prominently in the browser UI). They are common for businesses and e-commerce sites.

Extended Validation (EV)

The most rigorous verification level. The CA conducts an extensive vetting process including legal existence, physical address, operational status, and authorization of the certificate request. EV certificates historically displayed a green address bar with the company name, but most browsers have removed this visual distinction. EV certificates are now primarily used by financial institutions and large enterprises for compliance reasons.

Wildcard and SAN Certificates

Beyond validation levels, certificates also differ in how many domains they cover:

• Single-domain certificate: Covers exactly one fully qualified domain name (e.g., www.example.com). This is the most common type for simple websites.
• Wildcard certificate: Covers a domain and all its first-level subdomains. A certificate for *.example.com would cover www.example.com, mail.example.com, and api.example.com — but not sub.api.example.com (nested subdomains).
• Subject Alternative Name (SAN) / Multi-Domain certificate: Covers multiple specific domain names listed in the certificate's SAN field. A single SAN certificate might cover example.com, www.example.com, example.net, and app.example.org. This is useful for organizations that operate multiple domains.

Certificate Authorities and the Chain of Trust

The entire SSL/TLS system relies on a hierarchy of trust rooted in Certificate Authorities (CAs). Understanding this chain is essential for troubleshooting certificate errors and understanding how browsers decide whether to trust a certificate.

Root Certificate Authorities

Root CAs are the ultimate trust anchors. Their self-signed root certificates are pre-installed in operating systems and browsers as part of a "trust store." There are roughly 150 root certificates trusted by major browsers. Examples include DigiCert, Sectigo (formerly Comodo), and the Internet Security Research Group (ISRG), which operates Let's Encrypt. Root CAs rarely issue end-entity certificates directly — they sign intermediate CA certificates instead.

Intermediate Certificate Authorities

Intermediate CAs are CAs whose certificates are signed by a root CA (or by another intermediate). They issue the actual end-entity certificates for websites. This layered approach protects the root CA's private key: if an intermediate CA is compromised, only its certificates need to be revoked, not the root's. Web servers must send the complete chain (leaf + intermediates) to clients; omitting an intermediate certificate is one of the most common causes of SSL errors.

Leaf (End-Entity) Certificates

The leaf certificate is the certificate issued for your specific domain. It contains your domain name, public key, validity period, issuer (the intermediate CA), and a digital signature from the intermediate CA. When a browser validates a certificate, it walks the chain from the leaf certificate up through intermediates to a trusted root, verifying each signature along the way.

HTTPS vs HTTP: Why Encryption Matters

HTTP (Hypertext Transfer Protocol) transmits data in plain text. Anyone with access to the network — the Wi-Fi operator, the ISP, a router along the path — can read, modify, or inject content into the data stream. HTTPS (HTTP Secure) wraps the HTTP protocol inside a TLS connection, providing three guarantees:

• Encryption: The data exchanged between your browser and the server is encrypted. Even if intercepted, it appears as unintelligible ciphertext to the eavesdropper.
• Data Integrity: TLS uses message authentication codes (MACs) to detect any tampering. If even a single byte is altered in transit, the connection is terminated.
• Authentication: The server's certificate proves its identity. Your browser verifies the certificate before sending any data, preventing man-in-the-middle attacks where an attacker impersonates the destination server.

Since 2018, Google Chrome marks all plain HTTP sites as "Not Secure" in the address bar. Google also uses HTTPS as a ranking signal in search results. Every modern website should use HTTPS regardless of whether it handles sensitive data.

How to Check If a Site Is Secure

There are several ways to verify that a website's SSL/TLS configuration is correct and trustworthy:

1. Browser padlock: Look for the padlock icon (or "tune" icon in newer Chrome versions) in the address bar. Click it to view connection details. Verify the certificate is valid, issued to the correct domain, and not expired.
2. Certificate details: In most browsers, you can click the padlock and then "Certificate" to see the full certificate chain, including the issuer, subject, validity dates, and public key algorithm.
3. Online SSL checker tools: Use a tool like our SSL Certificate Checker to verify the certificate chain, protocol version, cipher suite, and expiry date from an external perspective.
4. Command-line tools: Use openssl s_client -connect example.com:443 to inspect the certificate and TLS configuration from the terminal. This shows the full certificate chain, negotiated protocol, and cipher suite.

Common SSL Errors and What They Mean

SSL/TLS errors are among the most common issues encountered on the web. Here is what the most frequent errors mean and how to fix them:

ERR_CERT_DATE_INVALID (Certificate Expired)

The certificate's "Not After" date has passed. Certificates have a maximum validity period (currently 398 days for public certificates). The fix is straightforward: renew the certificate. If you use Let's Encrypt with Certbot, configure automatic renewal so certificates are replaced before expiry.

ERR_CERT_COMMON_NAME_INVALID (Name Mismatch)

The domain name in the browser's address bar does not match any of the domain names listed in the certificate's Common Name (CN) or Subject Alternative Name (SAN) fields. This commonly happens when visiting a site via www.example.com when the certificate only covers example.com, or vice versa. The fix is to ensure the certificate covers all domains and subdomains the site uses.

ERR_CERT_AUTHORITY_INVALID (Untrusted CA)

The browser cannot build a chain of trust from the leaf certificate to a trusted root CA. This usually means the server is not sending the required intermediate certificates, or the certificate was issued by a CA not in the browser's trust store (e.g., a self-signed certificate or an internal enterprise CA). Fix this by configuring the server to send the full certificate chain.

Mixed Content Warnings

The HTTPS page is loading sub-resources (images, scripts, stylesheets, fonts, iframes) over plain HTTP. Browsers block "active" mixed content (scripts, CSS, iframes) entirely and may warn about "passive" mixed content (images, video, audio). Fix this by updating all resource URLs to use https:// or protocol-relative URLs, and setting the Content-Security-Policy: upgrade-insecure-requests header as a safety net.

ERR_SSL_PROTOCOL_ERROR

A general error indicating the TLS handshake failed. Causes include the server supporting only outdated protocols that the browser has disabled (e.g., TLS 1.0), misconfigured cipher suites, or server-side issues. Check the server's TLS configuration and ensure it supports TLS 1.2 and TLS 1.3 with modern cipher suites.

Let's Encrypt and Free Certificates

Let's Encrypt is a free, automated, and open Certificate Authority launched in 2016 by the Internet Security Research Group (ISRG). It issues Domain Validation (DV) certificates at no cost and has fundamentally changed the SSL/TLS landscape by making encryption accessible to everyone.

Key features of Let's Encrypt include:

• Free: No cost for certificates, ever. This removed the primary barrier to HTTPS adoption for small websites and personal projects.
• Automated: The ACME (Automatic Certificate Management Environment) protocol enables fully automated certificate issuance and renewal. Tools like Certbot, acme.sh, and Caddy handle the entire lifecycle.
• Short-lived: Certificates are valid for 90 days, encouraging automation and limiting the damage window if a certificate is compromised.
• Wildcard support: Let's Encrypt issues wildcard certificates (since March 2018) using DNS-01 challenge validation.
• Trusted: Let's Encrypt's root certificate (ISRG Root X1) is trusted by all major browsers and operating systems.

As of 2025, Let's Encrypt has issued billions of certificates and secures a significant portion of the web. The encryption provided by a free Let's Encrypt DV certificate is cryptographically identical to that of a paid DV certificate from any other CA.

SSL/TLS Best Practices for Website Owners

Securing your website with SSL/TLS goes beyond simply installing a certificate. Follow these best practices to maintain strong security:

1. Use TLS 1.2 and TLS 1.3 only. Disable all SSL versions and TLS 1.0/1.1. TLS 1.3 should be the preferred protocol. Configure your server to prefer TLS 1.3 cipher suites.
2. Use strong cipher suites. Prefer AEAD ciphers like AES-256-GCM and ChaCha20-Poly1305. Disable CBC-mode ciphers, RC4, 3DES, and export-grade ciphers. Use ECDHE or DHE key exchange for forward secrecy.
3. Install the complete certificate chain. Configure your server to send the leaf certificate plus all intermediate certificates. Do not include the root certificate (browsers already have it).
4. Automate certificate renewal. Use Certbot or a similar ACME client to automatically renew certificates before they expire. Test the renewal process to ensure it works without manual intervention.
5. Enable HSTS (HTTP Strict Transport Security). Send the Strict-Transport-Security header to instruct browsers to always use HTTPS for your domain. Start with a short max-age, then increase it and add includeSubDomains and preload once you are confident.
6. Redirect HTTP to HTTPS. Configure a permanent (301) redirect from http:// to https:// for all URLs. This ensures users and search engines always reach the encrypted version.
7. Fix mixed content. Audit your pages to ensure all resources are loaded over HTTPS. Use the Content-Security-Policy: upgrade-insecure-requests header as a fallback.
8. Use OCSP stapling. Instead of requiring clients to contact the CA's OCSP responder to check certificate revocation, have your server fetch and staple the OCSP response. This improves performance and privacy.
9. Monitor certificate expiry. Set up alerting for certificates approaching expiry. Even with automation, monitoring provides a safety net against renewal failures.
10. Test your configuration. Regularly test your SSL/TLS setup using tools like our SSL Certificate Checker, Qualys SSL Labs, or testssl.sh. Aim for an "A" grade or higher.

Frequently Asked Questions

What is the difference between SSL and TLS?

SSL (Secure Sockets Layer) is the original encryption protocol developed by Netscape in the 1990s. TLS (Transport Layer Security) is its successor, standardized by the IETF. All SSL versions are now deprecated due to security vulnerabilities. When people say "SSL" today, they almost always mean TLS. The current standard is TLS 1.3, released in 2018.

How do I check if a website has a valid SSL certificate?

Look for the padlock icon in your browser's address bar and confirm the URL begins with https://. Click the padlock to view certificate details. For a thorough check, use our SSL Certificate Checker to verify the full certificate chain, protocol version, and cipher suite.

What does "Your connection is not private" mean?

This browser warning appears when the SSL/TLS certificate cannot be validated. Common causes include an expired certificate, a certificate issued for a different domain name, a self-signed certificate, or an incomplete certificate chain.

Is a free SSL certificate from Let's Encrypt as secure as a paid one?

Yes. From an encryption standpoint, a free DV certificate from Let's Encrypt provides the same level of encryption as a paid DV certificate. The cryptographic algorithms and key lengths are identical. Paid certificates may offer OV or EV validation, which verify organizational identity but do not improve encryption strength.

What is a certificate chain of trust?

The chain of trust is the hierarchy of digital certificates linking your website's certificate (leaf) back to a trusted root CA. It typically consists of three levels: the root CA certificate (pre-installed in browsers), one or more intermediate CA certificates, and the leaf certificate. Each certificate is signed by the one above it.

What is TLS 1.3 and why should I use it?

TLS 1.3 is the latest version of TLS, finalized in 2018. It offers a faster handshake, removes outdated algorithms, mandates forward secrecy, and reduces attack surface. It is supported by all modern browsers and is recommended for all websites.

What is mixed content and why is it a problem?

Mixed content occurs when an HTTPS page loads resources over plain HTTP. This undermines encryption because an attacker can intercept the insecure resources. Modern browsers block active mixed content and warn about passive mixed content.

Do I need a separate SSL certificate for every subdomain?

Not necessarily. A wildcard certificate covers all first-level subdomains. A SAN certificate can cover multiple specific domains. Choose based on your infrastructure needs.