Every time a browser displays the padlock in the address bar, it is confirming that an end-to-end encrypted channel exists between the client and the server. That channel is provided by TLS (Transport Layer Security), the protocol that inherited and replaced the older SSL. Although the term "SSL certificates" has persisted out of habit, SSL 3.0 has been obsolete and prohibited since RFC 7568 (2015): what actually protects connections today is TLS, and understanding how it works is essential for any systems administrator who wants to guarantee the confidentiality, integrity and authentication of data in transit.
What TLS actually guarantees
TLS delivers three security properties simultaneously. Confidentiality prevents a third party that intercepts traffic from reading it, through symmetric encryption. Integrity ensures that data has not been altered in transit, through message authentication codes (MAC) or authenticated encryption (AEAD). And authentication verifies that the server is who it claims to be, through digital certificates signed by a trusted certification authority (CA). Without that last property, encryption would be pointless: we would be speaking privately with an attacker.
The TLS handshake step by step
The protocol solves an elegant problem: how two parties that have never met agree on a secret key over a public channel that anyone can eavesdrop on. The solution combines asymmetric cryptography (to establish trust) with symmetric cryptography (to encrypt data, which is far faster). In TLS 1.3 the process is:
- ClientHello. The client announces the protocol versions and cipher suites it supports and sends its side of an ephemeral Diffie-Hellman key exchange (ECDHE).
- ServerHello. The server selects the cipher suite, sends its certificate and its part of the Diffie-Hellman exchange.
- Key derivation. Both parties independently calculate the same symmetric session key, which never travels across the network.
- Finished. The integrity of the handshake is verified and encrypted data exchange begins.
The major improvement of TLS 1.3 (RFC 8446, 2018) over TLS 1.2 is the reduction of the handshake to a single round trip (1-RTT), with an optional 0-RTT mode for session resumption, which noticeably improves latency. It also removes legacy insecure algorithms: RSA key exchange is no longer permitted (making forward secrecy mandatory), and RC4, MD5 and vulnerable CBC modes are eliminated.
The difference between the two versions is not just about speed; it is about attack surface. TLS 1.2 allowed negotiating cipher suites that are now considered insecure, and many historical attacks (BEAST, POODLE, Lucky 13) exploited precisely those obsolete combinations or version downgrade negotiation. TLS 1.3 drastically reduces the catalogue of permitted suites to a small set of modern options with authenticated encryption (AEAD), making it impossible to accidentally choose a weak combination through misconfiguration. This simplification is itself a security improvement: fewer options means fewer ways to go wrong.
Forward secrecy: why ephemeral key exchange matters
Perfect Forward Secrecy (PFS) is one of the most important and least understood properties. With ephemeral key exchange (ECDHE), each session generates unique keys that are discarded once the session ends. This means that even if an attacker captures encrypted traffic today and steals the server's private key five years from now, they will not be able to decrypt past sessions. Without PFS, compromising a single private key retroactively exposes the entire historical record of communications. TLS 1.3 makes PFS mandatory.
Digital certificates: types and the chain of trust
An X.509 certificate binds an identity (a domain) to a public key, and that binding is signed by a CA that browsers trust out of the box. There are three validation levels:
| Type | Validation | Typical use |
|---|---|---|
| DV (Domain Validation) | Domain control only | Blogs, personal sites, internal APIs |
| OV (Organization Validation) | Domain + legal existence of the organization | Corporate, e-commerce |
| EV (Extended Validation) | Thorough legal verification | Banking, regulated sectors |
The chain of trust runs from the server certificate through one or more intermediate certificates and finally to a root certificate that the operating system or browser already has pre-installed. Misconfiguring the chain (forgetting to include the intermediate) is one of the most common causes of "untrusted certificate" errors even when the leaf certificate itself is valid. Initiatives such as Let's Encrypt have democratized free, automated DV certificates through the ACME protocol.
Revocation: when a valid certificate is no longer trustworthy
A certificate can lose its trustworthy status before its expiry date — for example, if its private key is compromised. Several revocation mechanisms exist to handle this. CRLs (Certificate Revocation Lists) are lists that the client is supposed to download to check whether a certificate has been revoked, but their size and latency make them impractical. The OCSP (Online Certificate Status Protocol) allows the status of a specific certificate to be queried in real time, though it introduces a privacy concern and additional latency because the browser contacts the CA on every connection.
The modern solution is OCSP stapling: the server itself periodically fetches a signed, timestamped OCSP response from the CA and attaches ("staples") it to the TLS handshake. The client therefore receives proof of validity without contacting the CA, eliminating the privacy leak and the latency. Enabling OCSP stapling is one of the most worthwhile performance and privacy optimizations for any serious deployment.
HSTS, certificate pinning and hardening
Having TLS active is not enough; you also need to prevent an attacker from forcing a downgrade to HTTP. The HSTS header (HTTP Strict Transport Security) tells the browser to connect only over HTTPS for a defined period, eliminating the attack window created by the first redirect. Certificate pinning goes further: the application (especially on mobile) memorizes which specific certificate or public key to expect from the server, rejecting any other even if it is signed by a valid CA, thus mitigating attacks that involve a compromised CA. Pinning must be managed carefully, because a misconfiguration can render an application inaccessible when the certificate is renewed.
Implementation and verification steps
- Generate a strong private key (RSA 2048+ or, preferably, ECDSA P-256) and the CSR.
- Obtain the certificate from a trusted CA and install the full chain (leaf + intermediates).
- Configure the server to accept only TLS 1.2 and TLS 1.3, disabling SSL 3.0, TLS 1.0 and TLS 1.1.
- Select cipher suites that guarantee forward secrecy (ECDHE) and AEAD (AES-GCM or ChaCha20-Poly1305).
- Enable HSTS, a 301 redirect from HTTP to HTTPS and, where applicable, OCSP stapling.
- Automate renewal (public certificates are trending toward shorter validity periods) and monitor expiry.
- Verify the configuration with external analysis tools before considering the deployment complete.
Common mistakes
The first is letting the certificate expire: this causes total service outages and, worse, trains users to dismiss security warnings. The second is keeping obsolete protocols active for compatibility with legacy clients, which reopens known vulnerabilities. The third is serving mixed content: an HTTPS page that loads resources over HTTP breaks the security guarantees and the browser marks it as insecure. The fourth is protecting only the front end while leaving internal service-to-service traffic unencrypted, a practice incompatible with zero-trust security models.
Frequently asked questions
Are SSL and TLS the same thing? No. SSL is the predecessor protocol, now obsolete and insecure. TLS is its successor. The term "SSL certificate" persists as a commercial convention, but the certificates serve TLS.
Does an EV certificate improve SEO ranking? Not directly. Search engines value HTTPS usage, but they do not differentiate between DV, OV and EV for ranking purposes. Certificate type is chosen based on trust and compliance requirements, not SEO.
Is Let's Encrypt secure despite being free? Yes. Security comes from the TLS protocol and key strength, not from the price of the certificate. A free DV certificate offers exactly the same encryption as a paid one of the same level.
Should I also encrypt traffic between internal microservices? Yes. Current best practice recommends end-to-end TLS even within the network (mTLS, mutual authentication), because the network perimeter is no longer considered a reliable trust boundary.
Conclusion
Encryption in transit has moved from being an optional extra to being the minimum requirement for any service that moves data across a network. However, "having HTTPS" and "having TLS properly configured" are very different things: the difference lies in enforcing TLS 1.3 with forward secrecy, maintaining the complete certificate chain, enabling HSTS and automating renewals so that no expired certificate takes the service down. The cryptography protecting these connections is solid; incidents almost never stem from the algorithm itself, but from outdated configurations and poorly managed certificates. At Summum we audit TLS deployments, eliminate legacy protocols and leave the renewal process automated and monitored, so that the padlock in the browser means exactly what the user believes it means.