SSL (Secure Sockets Layer) is the original protocol that enabled encrypted communication on the internet. Today succeeded by TLS, the term SSL remains ubiquitous. This guide explains what changed from SSL to TLS, how the handshake works, which certificate types exist, how to deploy TLS 1.3 in production, and how to avoid the misconfigurations that cause outages and security breaches.
SSL, short for Secure Sockets Layer, is the protocol that originally made encrypted communication on the internet possible. When Netscape introduced SSL in the mid-1990s, it solved a fundamental problem: how to transmit sensitive data between a browser and a server without anyone in between being able to read or tamper with it. Every time you see a padlock icon in your browser's address bar, you are benefiting from the work that SSL started.
Today, the protocol has evolved. The SSL protocol was succeeded by TLS (Transport Layer Security), which fixes the security weaknesses found in every version of SSL. Yet the term "SSL" persists everywhere: in product names, in documentation, and in everyday conversation. When someone says "SSL certificate" or "SSL security," they almost always mean a certificate used with TLS. Understanding this distinction, and understanding how the underlying protocol actually works, is essential for anyone responsible for securing web applications, APIs, or infrastructure.
This guide covers the complete picture: what changed from SSL to TLS, how the TLS handshake establishes a secure connection, the different types of SSL certificates available, what TLS 1.3 brings to production environments, and the most common misconfigurations that leave organizations exposed. Whether you manage a single domain or thousands, this is the practical knowledge you need to certify SSL deployments with confidence.
SSL (Secure Sockets Layer) was developed by Netscape and went through three versions. SSL 2.0, released in 1995, had serious design flaws including susceptibility to man-in-the-middle attacks. SSL 3.0, released in 1996, addressed many of those issues but was itself broken by the POODLE attack in 2014. None of these versions are safe to use today.
In 1999, the IETF took over and renamed the protocol to TLS (Transport Layer Security). TLS 1.0 was technically SSL 3.1, a modest upgrade. TLS 1.1 followed in 2006, and TLS 1.2 in 2008 introduced authenticated encryption modes and SHA-256 support. TLS 1.3, finalized in 2018 as RFC 8446, is a significant redesign that removes legacy cryptographic baggage entirely.
The key differences between SSL and TLS are not cosmetic. TLS replaced SSL's MAC-then-encrypt construction with authenticated encryption (AEAD ciphers like AES-GCM and ChaCha20-Poly1305), eliminated support for insecure algorithms like RC4, MD5, and export-grade ciphers, and introduced a more robust handshake mechanism. Every version of SSL and TLS prior to 1.2 is now formally deprecated by RFC 8996.
When people refer to an "SSL certificate" or "SSL digital certificate," they mean a standard X.509 certificate used to authenticate a server during a TLS handshake. The certificate itself is protocol-agnostic: the same SSL cert works with TLS 1.2 and TLS 1.3. What matters is which protocol version the server and client negotiate.
The TLS handshake is the process by which a client and server agree on cryptographic parameters and establish an encrypted channel. In TLS 1.2, this requires two round trips. TLS 1.3 reduces it to one.
In TLS 1.3, the handshake completes in a single round trip (1-RTT), cutting connection setup latency in half compared to TLS 1.2. A 0-RTT mode exists for resumed sessions, though it sacrifices replay protection and should be used carefully.
The client sends a message listing supported TLS versions, cipher suites, and a random value. In TLS 1.3, this message also includes key shares for supported groups (typically X25519 or P-256), enabling the server to compute the shared secret immediately.
The server selects the cipher suite and TLS version, sends its own random value, and presents its SSL certificate chain. In TLS 1.3, the server also sends its key share, and from this point forward all communication is encrypted.
The client validates the server's SSL certificate: it checks the digital signature against the issuing certificate authority, verifies the certificate has not expired, confirms the hostname matches the Subject Alternative Name, and checks revocation status via OCSP or CRL.
Both sides derive session keys from the shared secret using HKDF. Each side sends a Finished message containing a MAC over the entire handshake transcript, proving neither side's messages were tampered with. The secure channel is now established.
Not all SSL certificates are the same. They differ in validation level, scope, and use case. Choosing the right type affects both security posture and operational overhead.
The CA verifies only that the requester controls the domain, typically through a DNS record or HTTP challenge. DV certificates are issued in minutes and are ideal for blogs, internal tools, and APIs where organizational identity does not need to be displayed. They are the type issued by Let's Encrypt and most ACME-based flows.
The CA verifies the legal existence and identity of the organization requesting the certificate. OV SSL certificates include the organization name in the certificate's Subject field, providing users with a verifiable identity beyond the domain name. Common for corporate websites and SaaS platforms.
The most rigorous validation level. The CA performs in-depth checks of the organization's legal status, physical address, and operational existence. EV SSL certificates were once indicated by a green address bar in browsers; today, the visual distinction is less prominent, but EV remains a compliance requirement in some regulated industries.
A wildcard certificate protects a domain and all its first-level subdomains using a single SSL cert. For example, a certificate for *.example.com covers www.example.com, api.example.com, and mail.example.com, but not sub.api.example.com. Wildcard certificates reduce operational complexity but increase blast radius if the private key is compromised.
A single certificate that covers multiple distinct domain names using the Subject Alternative Name extension. One SSL certificate might protect example.com, example.net, and app.example.org. Useful for organizations managing multiple brands or services on shared infrastructure.
TLS 1.3 is not just a version bump. It is a meaningful security and performance improvement that removes entire categories of vulnerabilities present in earlier versions of the SSL protocol and TLS.
The cipher suite negotiation is simplified: TLS 1.3 supports only five cipher suites, all based on AEAD encryption. RSA key exchange is gone, meaning every connection now uses ephemeral Diffie-Hellman, guaranteeing forward secrecy by default. If a server's private key is compromised in the future, past recorded sessions cannot be decrypted.
Static RSA, CBC-mode ciphers, SHA-1, RC4, DES, 3DES, compression, and renegotiation are all removed. This eliminates the attack surface exploited by BEAST, CRIME, Lucky13, Sweet32, and other protocol-level attacks that plagued earlier versions.
In production, TLS 1.3 adoption requires verifying that your entire stack supports it: load balancers, reverse proxies, CDNs, application servers, and any middleware that terminates or inspects TLS. Most modern platforms (Nginx 1.13+, Apache 2.4.37+, HAProxy 2.0+, all major cloud providers) support TLS 1.3 natively. The main compatibility concern is older clients; some enterprise Java applications running older JDK versions or legacy IoT devices may not support TLS 1.3.
A practical migration strategy is to enable TLS 1.3 alongside TLS 1.2 and monitor connection telemetry. Once the proportion of TLS 1.2 connections drops below your threshold, disable it.
Most TLS security failures are not cryptographic breaks. They are configuration mistakes that leave known vulnerabilities exposed.
The single most common cause of TLS-related outages. When an SSL certificate expires, browsers and clients reject the connection outright. High-profile incidents at organizations like Microsoft, Spotify, and Equifax have been traced to a single forgotten certificate. Automated monitoring and renewal are the only reliable prevention.
A server must present not only its own certificate but also the intermediate certificates that link it to a trusted root. Missing intermediates cause validation failures on some clients but not others, making the problem difficult to diagnose. Always configure the full chain.
Leaving legacy cipher suites active (RC4, DES, export ciphers, CBC without mitigation) exposes the server to known attacks. Audit your cipher configuration regularly and disable anything not required by your client base.
Both are officially deprecated and are flagged by PCI DSS, NIST, and most compliance frameworks. Disabling them is a straightforward configuration change, but requires testing to confirm no critical clients depend on them.
Without HTTP Strict Transport Security, a user's first visit to your site may occur over plain HTTP, creating an opportunity for downgrade attacks. Set the Strict-Transport-Security header with a long max-age and include the includeSubDomains directive.
Using the same private key for SSL certificates in development, staging, and production increases the probability of key compromise. Generate unique key pairs for each environment and each certificate.
Managing a handful of SSL certificates manually is feasible. Managing hundreds or thousands is not. As organizations adopt microservices, multi-cloud architectures, and zero-trust models, the number of SSL certificates in any given environment grows exponentially.
The challenges compound. Certificate lifespans are shrinking: the CA/Browser Forum has moved from multi-year to 398-day maximum validity, and the industry is trending toward 90-day and even 47-day lifespans. Shorter lifespans improve security by limiting exposure time if a key is compromised, but they make manual renewal operationally impossible at scale.
Effective certificate lifecycle management requires four capabilities. First, discovery: knowing every SSL certificate deployed across your infrastructure, including shadow certificates provisioned by individual teams. Second, policy enforcement: ensuring every certificate meets organizational standards for key algorithm, minimum key length, approved CAs, and naming conventions. Third, automated renewal: integrating with protocols like ACME, EST, and SCEP to renew SSL certificates before they expire without human intervention. Fourth, auditability: maintaining a complete record of every certificate event for compliance reporting under frameworks like NIS2, DORA, and PCI DSS.
Without centralized management, organizations inevitably face outages caused by expired certificates, security gaps from unknown certificates using weak cryptography, and audit failures from incomplete certificate inventories.
Complete SSL certificate inventory — Evertrust CLM discovers every SSL certificate across your networks, cloud environments, containers, and endpoints, giving you a single source of truth for your entire certificate estate.
Automated lifecycle management — From enrollment to renewal to revocation, Evertrust automates the full lifecycle of your SSL certificates via ACME, EST, SCEP, and REST APIs, eliminating manual workflows and preventing expiration-related outages.
Policy enforcement at issuance — Define organizational rules for key algorithms, minimum key sizes, validity periods, approved CAs, and naming conventions. Evertrust rejects non-compliant certificate requests before they reach production.
Crypto-agility for the future — As the industry transitions to post-quantum cryptography, Evertrust PKI enables you to re-issue SSL certificates at scale with new algorithms across all your CAs and environments, ensuring your secure sockets layer infrastructure stays ahead of emerging threats.
