What is Secure Sockets Layer (SSL)?

Definition: Secure Sockets Layer (SSL)

Secure Sockets Layer (SSL) is the original protocol that enabled encrypted, authenticated connections between a client (like a web browser) and a server. SSL provided confidentiality, integrity, and server identity so credentials and data weren’t exposed in transit. SSL itself (notably SSLv2 and SSLv3) is deprecated and insecure today; the industry standard is Transport Layer Security (TLS)—often still called “SSL” in everyday speech. In practice, when people say “SSL certificate”, they mean a TLS server certificate used by HTTPS.

‍

TLS vs. SSL: what changed and why it matters

Think of TLS as SSL’s secure successor. It fixes design flaws, removes weak cryptography, and streamlines the handshake.

• Protocol lineage: SSLv2/SSLv3 → TLS 1.0 → 1.1 → 1.2 → 1.3 (current best practice).
• Stronger cryptography: TLS eliminates obsolete algorithms (e.g., RC4, MD5) and supports modern suites like AES-GCM and ChaCha20-Poly1305.
• Forward secrecy: Ephemeral Diffie-Hellman (ECDHE) makes stolen server keys useless for decrypting past traffic.
• Faster handshakes: TLS 1.3 reduces round trips and removes risky legacy features, improving page load times.

Bottom line: disable SSL and older TLS versions and run TLS 1.2 and 1.3 only.

‍

How HTTPS works (in plain English)

When you visit https://…, your browser and the site perform a TLS handshake:

1. Hello & negotiation: The browser proposes TLS versions and cipher suites.
2. Identity: The server sends its certificate (issued by a trusted Certificate Authority, or CA).
3. Validation: The browser verifies the cert’s signature, validity window, and hostname and that a trusted CA chain signs it.
4. Key agreement: Both sides derive shared session keys (e.g., via ECDHE).
5. Encrypted traffic: Requests and responses are now private and tamper-evident.

Performance features like session resumption and 0-RTT (TLS 1.3) further reduce latency for repeat visitors.

‍

Certificates 101: DV, OV, EV, SAN, and wildcards

TLS relies on public key infrastructure (PKI): CAs validate control of a domain and issue X.509 certificates that assert identity.

• DV (Domain Validation): Proves control of a domain (fast, automated). Best default for most sites.
• OV (Organization Validation): Adds vetted org information to the cert (useful for B2B/B2G assurance).
• EV (Extended Validation): Stricter business verification with legal entity details (UI indicators have diminished over time).

SAN (Subject Alternative Name) lets a single cert cover multiple hostnames (e.g., www.example.com, api.example.com). Wildcards (e.g., *.example.com) cover all first-level subdomains—handy for multi-tenant or elastic environments. Choose RSA 2048/3072 or ECDSA (P-256) keys; ECDSA gives smaller, faster handshakes.

Pro tip: Automate certificate lifecycle (issuance, install, renewal) using ACME (e.g., Let’s Encrypt) to prevent expirations.

‍

SNI and name-based hosting (many HTTPS sites, one IP)

Historically, each HTTPS site needed its own IP because the server had to pick a certificate before knowing the requested hostname. Server Name Indication (SNI) fixes that: the browser includes the hostname early in the handshake, so one listener/IP can serve the right certificate for many domains. If you’re evaluating multi-site hosting, see Name Based SSL Virtual Hosting for patterns and gotchas (legacy clients without SNI, certificate sprawl, and ALPN/HTTP-2 considerations).

‍

Configuration best practices (modern and measurable)

A short overview first: the goal is strong security with great performance—and evidence you can audit.

Protocols & ciphers

• Enable: TLS 1.2 and 1.3.
• Disable: SSLv2, SSLv3, TLS 1.0, TLS 1.1.
• Prefer ECDHE key exchange and AES-GCM / ChaCha20-Poly1305 ciphers.
• For certificates, prefer ECDSA where client population allows; otherwise offer dual-stack (RSA + ECDSA).

Server features

• HTTP/2 and HTTP/3 (QUIC): Better multiplexing and latency; both use TLS.
• HSTS: Enforce HTTPS and preload where appropriate to prevent downgrade/strip attacks.
• OCSP stapling: Improves revocation checks and latency.
• Session resumption: Tickets or IDs to reduce handshake cost.
• mTLS (mutual TLS): Require client certificates for admin planes, B2B partner APIs, or sensitive internal services.

Edge and origin

• If you terminate TLS at a CDN or load balancer, maintain TLS from the edge to origin (re-encrypt) for end-to-end confidentiality.
• Standardize on infrastructure-as-code for consistent cipher and protocol policies across fleets.

Monitoring & evidence

• Track cert expiration, handshake failure rates, TLS version distribution, OCSP stapling status, and HSTS preload readiness.
• Send logs and metrics to SIEM so your SOC can investigate anomalies (e.g., sudden TLS errors or cipher downgrade attempts).

For architecture choices that intersect DNS, CDN, and edge placement, see DNS Providers Offer Assistance in Forming Content Delivery Plans. For governance and audit needs (key custody, revocation, evidence), see Data Protection Program: Strategy, Privacy & Audit Tips.

‍

Common pitfalls (and the quick fixes)

• “We have SSL,” but old protocols are still on. Fix: disable TLS 1.0/1.1 and SSL; enforce TLS 1.2/1.3 only.
• Mixed content: Pages load over HTTPS but embed HTTP assets. Fix: update asset URLs or use Content-Security-Policy (upgrade-insecure-requests).
• Self-signed in production: Browsers won’t trust it. Fix: use a public CA and proper chain.
• Certificate sprawl: Many teams, many certs, no inventory. Fix: centralize issuance and automate renewals (ACME).
• TLS offload with no re-encryption: Traffic is cleartext inside the data center. Fix: TLS to origin or private service mesh/mTLS.
• Weak ciphers enabled “just in case”: Attack surface increases. Fix: curate cipher suites; test with external scanners.
• SNI blind spots: Legacy clients break on name-based hosting. Fix: separate VIPs for critical legacy populations or enforce modern clients.

‍

Beyond the browser: where “SSL” shows up elsewhere

• Email: SMTP over TLS (SMTPS, STARTTLS) protects mail in transit; align with SPF/DKIM/DMARC for identity.
• APIs & microservices: mTLS authenticates services to each other; service meshes can automate cert rotation.
• VPNs and apps: Many VPNs, database drivers, and message brokers use TLS under the hood—enforce up-to-date versions and certificates there, too.

‍

Implementation roadmap (fast wins to long-term discipline)

1. Inventory & baseline. Discover all public hostnames, VIPs, and origins. Capture current TLS versions, ciphers, and cert expiration dates.
2. Raise the floor. Disable SSL, TLS 1.0, and 1.1. Enable TLS 1.2/1.3 and a curated cipher list. Turn on OCSP stapling and HSTS (start with short max-age).
3. Fix cert lifecycle. Move to ACME where possible; create alerts 30–45 days before expiry. Consolidate to SAN or wildcard certs judiciously to cut sprawl.
4. Harden the edge. If using CDN/WAAP, enforce strong TLS at the edge and origin. Validate HTTP/2/3 and ALPN behavior with your load balancers.
5. Protect admin and B2B flows. Require mTLS for control planes and sensitive partner APIs; store private keys in HSM/KMS.
6. Prove it. Add TLS checks to CI/CD and APM/observability dashboards. Stream events to SIEM. Document policies for audit—key sizes, rotation, revocation steps, and incident playbooks.
7. Review quarterly. Re-scan posture, rotate weak remnants, and refresh cipher/feature policy (e.g., nudge more traffic to TLS 1.3).

‍

Performance notes (speed without sacrificing safety)

• TLS 1.3 + HTTP/2/3 often improves speed versus old stacks.
• Prefer ECDSA where client support is broad; fall back to RSA to cover older devices.
• Use session resumption and TLS false start (where safe) to shave round-trips.
• Terminate close to users with a CDN and keep persistent, encrypted connections from edge to origin.

‍

Governance, privacy, and audit

An effective program treats TLS as part of your data protection strategy, not just a webserver setting:

• Document roles and responsibilities (who can request certs, who approves SAN/wildcards, who holds keys).
• Keep key material in HSM/KMS; restrict export and log administrative actions.
• Maintain an asset-to-certificate map and change records; collect certificate transparency (CT) logs for rogue issuance checks.
• Align policy to frameworks (e.g., PCI DSS requires TLS 1.2+; HIPAA expects encryption-in-transit for ePHI).

For policy templates and evidence practices, revisit Data Protection Program: Strategy, Privacy & Audit Tips.

‍

Related Solutions

SSL/TLS shines when paired with the right edge, delivery, and monitoring stack. Web Application and API Protection (WAAP) adds bot mitigation and OWASP protections on top of strong TLS, while DDoS Mitigation keeps encrypted endpoints available under volumetric attack. Distribute certificates and terminate close to users with a Cloud Content Delivery Network (CDN), and steer traffic smartly using Cloud Connect to keep latency low. For user access to SaaS and the open internet, Secure Service Edge (SSE) enforces encryption and acceptable-use policies, while Application Performance Monitoring and Observability (APM) tracks handshake times and error rates so your encrypted apps stay fast and trustworthy.