Learn

TLS: the lock behind HTTPS

TLS (Transport Layer Security) is the protocol that encrypts a network connection and verifies the server's identity using a certificate. When a web connection runs over TLS it becomes HTTPS (Hypertext Transfer Protocol Secure), the version with the lock icon, so nobody between the two ends can read or tamper with the traffic.

At a glance

What it is
Encryption plus identity verification for a network connection
What it gives you
HTTPS (Hypertext Transfer Protocol Secure), the lock icon, over plain HTTP
How identity is proven
A certificate, issued for a name and signed by a trusted authority
Who issues certificates free
Automated authorities like Let's Encrypt, renewed without manual work
Comparison

Plain HTTP versus HTTPS over TLS

HTTP (no TLS)
HTTPS (TLS)
Can a snooper read it?
Yes, the traffic is in the clear
No, the traffic is encrypted
Is the server's identity checked?
No, you trust the name blindly
Yes, a certificate proves the name
Browser shows
A 'not secure' warning
The lock icon

What does TLS protect, and from whom?

TLS (Transport Layer Security) wraps a connection in two guarantees. First, encryption: anyone sitting between you and the server, on the same network, at an internet provider, anywhere along the path, sees scrambled bytes instead of your traffic. Second, identity: the server presents a certificate that proves it holds the name you typed, signed by an authority your machine already trusts. A connection running over TLS is what turns plain HTTP into HTTPS (Hypertext Transfer Protocol Secure), the version browsers mark with a lock.

Without it, the connection is readable and forgeable. With it, a snooper learns almost nothing and a fake server cannot pretend to be yours.

Why do TLS problems feel sudden?

Certificates are issued for a fixed window and then expire. A site that worked for months stops one morning because nobody renewed the certificate, and the browser refuses to connect rather than trust an expired one. This is why automated issuers that renew on their own, quietly and on schedule, are the sane default for self-hosting: the failure mode of forgetting is worse than the small risk of automation.

The other classic fault is a name mismatch. A certificate issued for one name will be rejected when served for another, because that mismatch is exactly what TLS exists to catch. Check the dates and the name first, before you suspect anything deeper.

Check it yourself

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Prints the certificate's valid-from and valid-until dates. An expired date is the most common reason a TLS connection suddenly starts failing.

TLS gives you

  • Traffic nobody in the middle can read
  • Proof the server holds a certificate for that name
  • Tamper detection, so altered data is rejected
  • The HTTPS lock that browsers require for many features

TLS does not give you

  • A guarantee the server itself is honest or well-run
  • Protection once data is decrypted and stored on the far end
  • Access control; encryption is not authorisation
  • A working site if the certificate has expired or the name is wrong

Related terms

← All terms Reviewed: June 2026