If you have noticed HTTPS in a website's address, you have encountered encrypted web communication. People commonly call this "SSL," but modern websites use its successor, Transport Layer Security (TLS). Understanding that distinction helps you recognize a protected connection without mistaking it for a guarantee that the website itself is honest.
What is SSL?
SSL stands for Secure Sockets Layer, an older family of protocols for protecting network communications. SSL versions are obsolete and should not be enabled on a modern server. The familiar phrase "SSL certificate" usually means a certificate used with TLS, rather than an instruction to deploy the old SSL protocol.
HTTPS is HTTP carried over a TLS-protected connection. It helps protect web requests and responses against reading and modification by someone on the network path. This matters for ordinary browsing as well as passwords or payment details: an unprotected page could be altered before it reaches your browser.
Three concepts work together: confidentiality protects the content, integrity detects unauthorized changes, and authentication helps the browser establish that it is connecting to the intended service. Encryption without checking the service's identity would leave a key question unanswered: who is at the other end?
How does a modern TLS handshake work?
The following describes a typical certificate-authenticated TLS 1.3 connection at a high level. Other cases, including session resumption, have different details:
- The browser and server negotiate supported parameters and exchange key-share information.
- The server presents its certificate chain and proves possession of the corresponding private key through a signature.
- The browser checks the certificate's trust chain, validity and identity against the service it intended to reach.
- The peers derive traffic keys from the negotiated key exchange and handshake context.
- Authenticated symmetric encryption protects application data using algorithms such as AES-GCM or ChaCha20-Poly1305.
The browser does not normally need its own client certificate, and the server does not encrypt a random number with an assumed browser public key. Certificate signatures, key exchange and bulk encryption have different roles. TLS 1.3 removed the older static RSA key-transport mechanism. Its public-key key exchanges support forward secrecy: later theft of the server's long-term key does not by itself reveal previously captured sessions. See the TLS 1.3 specification.
How to check a website's connection
Check the actual address and the browser's connection information. Modern browsers do not all show the same padlock. Chrome replaced its main lock icon with a site-controls icon; the Chrome security team explains that a lock was often mistaken for a statement of website trustworthiness.
Open the browser's site or connection controls to inspect certificate information when needed. A valid certificate for a lookalike domain is still a certificate for the wrong destination. For a sensitive login, use a known bookmark or enter the correct address yourself instead of judging a page by its logo, a link label or an icon.
If a browser warns about a certificate, stop before entering information. An expired certificate, wrong hostname, incomplete trust chain, incorrect device clock or network interception can produce different errors. Investigate the actual reason; repeatedly clicking through warnings defeats the identity check you wanted.
HTTPS and plain HTTP traffic
| Property | Plain HTTP | Properly configured HTTPS |
|---|---|---|
| Content confidentiality | The HTTP message is not encrypted by HTTP itself. | TLS protects requests and responses on that connection. |
| Service authentication | No TLS certificate validation. | The browser validates the certificate and expected service identity. |
| Content integrity | HTTP alone does not prevent an on-path party from altering the message. | Cryptographic checks reject unauthenticated changes. |
| Website honesty | Not established by the protocol. | Not established by an encrypted connection either. |
Ports 80 and 443 are the conventional defaults for HTTP and HTTPS; another configured port does not determine whether encryption exists. An HTTP request sent through a VPN can be protected on the VPN portion of its route, but the HTTP connection itself still lacks TLS protection. Likewise, HTTPS does not conceal every network fact: observers can still see addresses, timing and traffic volume, with hostname visibility depending on the surrounding protocols.
When a CDN or reverse proxy terminates TLS, the protected browser connection ends there. The proxy-to-origin connection is a separate hop that needs its own appropriate protection. Avoid describing ordinary HTTPS as end-to-end encrypted messaging that makes all intermediaries or server administrators unable to read content.
Certificate validation and hostname coverage
Validation level and hostname coverage are different dimensions. DV, OV and EV describe checks performed before certificate issuance; wildcard and multi-domain describe which names are covered. Paying for a higher validation level does not automatically select a stronger TLS cipher.
Domain validation (DV)
A DV certificate establishes control of the validated domain. It does not verify that the operator is an honest shop or a particular registered business. DV can support properly configured HTTPS for sites that handle sensitive data; it is not a weaker-encryption class restricted to personal blogs. Let's Encrypt provides free DV certificates, making certificate cost a separate question from connection encryption.
Organization and extended validation (OV and EV)
OV adds organization identity checks; EV requires more extensive checks of the legal entity and applicant. These can be useful where verified organizational identity is required, but they do not certify the safety of every transaction, application or employee. The certificate issuer's explanation distinguishes the validation steps. Treat its identity claims separately from TLS's cryptographic protection.
Wildcard and multi-domain certificates
A wildcard such as *.example.com covers a single label at that level, for example shop.example.com. It does not by itself cover example.com or shop.eu.example.com. Some certificate products include the base name separately, so inspect the actual Subject Alternative Name entries instead of relying on a product label. TLS service-identity rules define the wildcard restriction.
Multi-domain certificates list multiple permitted names through Subject Alternative Names. "UCC" is another product label commonly associated with certificates covering several service names, rather than a separate stronger-encryption protocol. Choose the exact names your clients use and consider the consequences of sharing one private key across many services.
Which TLS versions should a server use?
Follow current implementation guidance for TLS 1.2 and TLS 1.3, preferring TLS 1.3 where available. The IETF's TLS recommendations prohibit negotiating SSLv2, SSLv3, TLS 1.0 and TLS 1.1. TLS 1.2 still needs suitable algorithms and settings; the version label alone does not prove a good configuration. Keep the TLS library and server software maintained instead of copying an old cipher list indefinitely.
Running HTTPS on your own site
For a public blog or homelab service, start with the hostname clients will use, a suitable certificate and a supported web-server or proxy configuration. Automate renewal and check that the running service actually loads the renewed certificate. A renewed file on disk does not help if the proxy continues presenting an expired one.
ACME validation methods have specific requirements. Let's Encrypt's challenge guide explains that HTTP-01 uses port 80 and cannot issue a wildcard, while DNS-01 can validate a wildcard and services that are not publicly exposed. Protect DNS API credentials and scope them to the records the automation needs.
Test HTTP-to-HTTPS redirects and pages that load scripts, styles or images. Mixed HTTP content can undermine an otherwise encrypted page. Once HTTPS works consistently, consider HTTP Strict Transport Security. HSTS tells browsers to require HTTPS on later visits; including subdomains also commits those names to HTTPS, so check their readiness first.
Conclusion
TLS is an essential part of protecting web communications. It helps protect data in transit and establish the service's identity, while certificate types describe different validation and hostname needs. Use HTTPS, respect connection warnings and still judge whether the destination is the one you intended to trust.
For a site owner, useful protection comes from a complete working setup: correct names, maintained TLS settings, reliable renewal and secure handling of the data after it reaches the server. A certificate supports that work; it does not replace it.
