Blog

What is SSL?

Key Takeaways

  • People still say “SSL,” but modern HTTPS uses TLS. SSL itself is obsolete.
  • TLS provides confidentiality, integrity, and server authentication—not just encryption.
  • Certificates help authenticate a server’s name and public key; symmetric traffic keys protect application data.
  • Prefer TLS 1.3, retain securely configured TLS 1.2 where needed, and automate certificate issuance and renewal.

SSL stands for Secure Sockets Layer, the obsolete predecessor of Transport Layer Security (TLS). People still use “SSL” as shorthand for secure connections and certificates, but modern HTTPS uses TLS, not the old SSL protocol. TLS protects communication between a client, such as your browser, and a server across an untrusted network.

What is TLS? SSL vs TLS in 2026

TLS succeeded SSL; it wasn’t simply a new name for an unchanged protocol. TLS 1.0 was standardized in January 1999, based on SSL 3.0 but with changes that made the protocols distinct. Our SSL vs TLS comparison explains the terminology in more detail.

ProtocolStatus for web deployments
SSL 2.0 and SSL 3.0Insecure and obsolete; do not enable them.
TLS 1.0 and TLS 1.1Deprecated; do not enable them.
TLS 1.2Still relevant for compatibility, with secure cryptographic settings.
TLS 1.3Preferred when both endpoints support it.

Supporting TLS 1.2 doesn’t mean enabling every algorithm that version permits. Use your platform’s maintained TLS configuration rather than copying an old cipher list. The IETF’s deployment guidance recommends preferring TLS 1.3 and disabling obsolete protocol versions.

How does SSL/TLS work?

TLS starts with a handshake: an exchange that negotiates security settings, authenticates the server, and establishes keys. For a normal, full certificate-based TLS 1.3 handshake, the sequence looks like this:

  1. Negotiate: The browser sends a ClientHello with supported versions, cryptographic options, and an ephemeral key share. The server selects compatible parameters and returns its key share in ServerHello.
  2. Derive handshake keys: Each endpoint combines its private key-agreement material with the other endpoint’s public share to calculate a shared secret and derive handshake keys.
  3. Authenticate the server: The server sends its certificate chain and a CertificateVerify signature over the handshake transcript. The browser validates the certificate and signature.
  4. Confirm the handshake: Finished messages let the endpoints check the handshake’s integrity and confirm possession of the derived secrets.
  5. Protect application data: The endpoints derive symmetric traffic keys and use them to protect subsequent application messages.
Browser                                      Server
   |--- ClientHello + key share ---------------->|
   ||
   ||

This diagram omits optional messages and resumption, which can reuse secrets established by an earlier connection. TLS 1.2 with ephemeral key agreement uses different messages and ordering, but the same basic division of responsibilities: negotiate, authenticate, agree on secrets, and protect data. See how TLS works for a deeper explanation.

Understanding SSL encryption: three different jobs

Modern TLS combines several cryptographic mechanisms. Treating them all as “public-key encryption” hides the part each one plays:

  • Digital signatures authenticate. In a certificate-based TLS 1.3 handshake, the server signs handshake information with its certificate’s private key. The browser checks that signature using the public key in the certificate.
  • Key agreement establishes secrets. Ephemeral Diffie–Hellman, commonly its elliptic-curve form, lets the endpoints calculate shared secrets without transmitting those secrets directly.
  • Symmetric encryption protects traffic. Derived traffic keys encrypt application data and provide integrity protection against undetected modification.

The certificate public key is public; the corresponding private key must remain protected. A digital signature is not “encryption with the private key,” and the certificate itself does not encrypt your HTTP requests.

These mechanisms deliver three separate properties: confidentiality keeps transmitted data private, integrity detects tampering, and authentication helps establish whom you’re communicating with. Encryption without proper server authentication can still leave you talking securely to an impersonator.

SSL certificates and validation

What does an SSL certificate contain?

A web server’s TLS certificate binds a public key to names and certificate metadata through an issuer’s digital signature. It includes the public key, issuer information, validity dates, and extensions that describe names and permitted uses.

Modern certificates identify DNS names through the Subject Alternative Name (SAN) extension. A domain-validated (DV) certificate establishes that the applicant demonstrated control of the domain; it does not establish the applicant’s legal business identity. Organization-validated (OV) certificates add verified organization information, but neither type guarantees honest behavior or safe content.

How does a browser validate an HTTPS certificate?

A browser doesn’t trust a certificate merely because it contains a plausible name. It checks several independent conditions:

  • Hostname: The requested DNS name must match an appropriate name in SAN.
  • Certificate chain: Certificate signatures must validate along a suitable path to a trusted root—a trust anchor accepted by the client.
  • Validity: Certificates in the validated path must be within their validity periods.
  • Constraints: Key usage, extended key usage, CA permissions, name constraints, and other applicable restrictions must allow the intended use.
Site certificate: example.com
        |
        | signed by
        v
Intermediate CA certificate
        |
        | signed by
        v
Trusted root / trust anchor
        ^
        | accepted by the client's trust configuration
Browser or operating-system trust store

The server normally sends its site certificate and needed intermediate certificates. Trust comes from the client’s trusted root configuration, not from the server declaring its own root trustworthy. Certificate-chain validation and hostname matching are separate checks; passing one does not replace the other.

Signature verification uses public keys locally; it does not require asking the issuing CA to approve every connection. Clients may fetch missing intermediates or use certificate-status information, but revocation checking is a separate concern whose mechanisms and behavior vary by browser and policy.

What happens when certificate validation fails?

An expired certificate fails date checks; a certificate for another hostname fails name matching. A missing intermediate can prevent chain building, while an unknown root or an unconfigured self-signed certificate can leave the client without a trusted issuer. Browsers generally display a certificate warning or block the connection when validation fails.

Public certificates versus private trust

A public website needs a certificate chain accepted by its visitors’ browsers without custom setup. For internal systems, you can operate a private public-key infrastructure (PKI)—your own system for issuing certificates and distributing trust. Clients must explicitly trust the private issuer.

A self-signed certificate is signed with its own private key rather than a separate issuer’s key. It can support secure TLS in controlled testing or internal deployments when clients deliberately trust it and still perform the other validation checks. For multiple internal services, a managed private CA is usually easier to operate than distributing trust for each individual self-signed certificate.

How TLS works with HTTPS

HTTP defines application behavior: requests, methods, headers, status codes, and response bodies. TLS provides security for the communication carrying those messages. HTTPS is HTTP secured using TLS; TLS also protects other application protocols, so it isn’t an HTTP-only feature.

With HTTPS, HTTP headers and bodies are protected in transit between the TLS endpoints. Ordinary unencrypted HTTP provides no equivalent confidentiality or tamper protection. HTTP/3 uses QUIC, which incorporates TLS 1.3, rather than the familiar TLS-over-TCP arrangement.

The endpoint boundary matters. If a reverse proxy terminates TLS, that proxy can read the decrypted traffic. The proxy-to-application connection needs its own protection; browser-to-proxy HTTPS doesn’t automatically secure that next hop.

Certificate issuance and renewal in 2026

A certificate signing request (CSR) is a signed request document, not the name of the entire issuance process. A typical automated workflow is:

  1. The operator, certificate client, or managed platform generates a key pair.
  2. The client prepares a CSR containing the public key and requested names, signed with the corresponding private key.
  3. The applicant completes the CA’s domain-control validation.
  4. The CA issues a signed certificate, and the deployment installs it with the appropriate intermediate certificates.
  5. Automation renews and deploys replacement certificates before expiration.

ACME—the Automatic Certificate Management Environment protocol—automates interactions with a CA for issuance and renewal. The private key is not submitted to the CA as part of the CSR; protect it with appropriate access controls and keep it out of source control and logs.

For publicly trusted TLS subscriber certificates issued on or after March 15, 2026 and before March 15, 2027, the CA/Browser Forum maximum validity is 200 days. That is a ceiling, not a promised lifetime; a CA may issue shorter-lived certificates. These public-web requirements are not a universal lifetime rule for private PKI.

Automate renewal, allow time for retries, and monitor both renewal failures and the certificate actually served by the live endpoint. A replacement certificate on disk isn’t useful if your proxy still serves the old one. Managed HTTPS reduces certificate-management work, but you should still know who owns renewal and how failures are detected.

Inspect an HTTPS endpoint with OpenSSL

With OpenSSL installed and an appropriate CA trust store configured, run this in a terminal to inspect a TCP-based HTTPS endpoint:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error \
  -showcerts

Inspect the negotiated protocol and cipher, certificate verification result, and presented certificates. Press Ctrl+C when you’re finished.

  • -servername supplies Server Name Indication (SNI), allowing the server to select the intended virtual host.
  • -verify_hostname checks the expected hostname; sending SNI alone is not hostname verification.
  • -verify_return_error stops on certificate verification errors instead of continuing for debugging.
  • -showcerts displays certificates sent by the server, not a guaranteed complete or verified chain.

OpenSSL’s trust configuration may differ from your browser’s. Investigate verification failures rather than assuming that a successful connection means the certificate was accepted securely.

Common Mistakes

  • Disabling certificate verification to fix an outage. Correct the trust or deployment problem instead.
  • Protecting only the main page. Scripts, stylesheets, and other resources also need HTTPS; HTTP subresources create mixed content.
  • Assuming HTTPS secures the whole application. TLS protects transport, not authorization logic, stored data, or every application vulnerability. Use it alongside application security controls.
  • Treating encryption as an endorsement. An authenticated, encrypted connection does not make the website’s operator trustworthy.

Keep TLS libraries patched and test the deployed configuration—not just the configuration file you intended to deploy.

FAQ

Is SSL still used in 2026?

“SSL” remains common terminology, but modern HTTPS uses TLS. SSL 2.0 and SSL 3.0 are obsolete; prefer TLS 1.3 and use securely configured TLS 1.2 where compatibility requires it.

What does an SSL certificate actually do?

A TLS certificate binds a public key to server names and issuer-signed metadata. Together with proof of private-key possession during the handshake, it helps authenticate the server; it does not itself encrypt HTTP data.

How does a browser validate an HTTPS certificate?

The browser checks the requested hostname against SAN, validates a certificate path to a trusted root, and checks validity dates and applicable constraints. Revocation checking is separate, and its behavior varies by browser and policy.

Does HTTPS mean a website is safe?

No. HTTPS protects communication with the authenticated endpoint, but it does not guarantee that the operator is honest, the content is harmless, or the application is free of vulnerabilities.

Are self-signed certificates secure?

A self-signed certificate can support secure TLS when clients explicitly trust it and validate the hostname and other constraints. It is not publicly browser-trusted by default, so it suits controlled testing or internal deployments rather than an unrestricted public website. Configure trust deliberately instead of disabling verification.

Further Reading

Written by Sam Erickson

Software engineer. I write every article on StackChief myself. More about me

Related reading