What is SSL/TLS & HTTPS?

When you visit a website and see a padlock icon in the address bar, that padlock means your connection is encrypted. The technology behind that padlock is called TLS, and HTTPS is just normal web traffic (HTTP) wrapped inside TLS. As someone setting up a server, you need to understand this because nobody trusts a site without the padlock anymore, and browsers actively warn users away from sites without it. This page explains what TLS does, what a certificate proves, and how the pieces fit together so the Let’s Encrypt pages later make sense.

SSL vs TLS — clearing up the names

You will see two acronyms used almost interchangeably: SSL and TLS. Here is the honest truth.

• SSL (Secure Sockets Layer) was the original protocol from the 1990s. Every version of SSL is now old, broken, and disabled. Nobody should use it.
• TLS (Transport Layer Security) is the modern replacement. The current versions are TLS 1.2 and TLS 1.3 (TLS 1.3 is the newest and fastest, released in 2018).

So when people say “SSL certificate” or “install SSL”, they almost always mean TLS. The word “SSL” stuck around out of habit, like calling all tissues “Kleenex”. Throughout these docs we use TLS for the actual protocol and TLS certificate for the file, but if a tool or company says “SSL”, just read it as TLS.

The protocol named “SSL” is genuinely insecure and disabled in all modern servers and browsers. If a tutorial tells you to enable SSLv3, ignore it — that advice is dangerous and badly out of date.

What TLS actually does

TLS gives your traffic three protections at the same time:

Protection	What it means	Why you care
Encryption	The data is scrambled so anyone in between (your ISP, a coffee-shop Wi-Fi, an attacker) sees only gibberish.	Passwords and credit cards stay private.
Integrity	If anyone tampers with the data in transit, the connection breaks instead of delivering altered content.	No one can silently inject ads or malware.
Authentication	You can prove the server is really example.com and not an impostor.	You are not handing your password to a fake site.

That third one — authentication — is where certificates come in.

What a certificate proves

A TLS certificate is a small file that lives on your server. Its job is to prove that this server really is allowed to serve traffic for this domain name. It is a bit like a passport: a trusted authority issues it, it has an expiry date, and it is very hard to forge.

To understand certificates you need two more ideas.

Public key and private key

TLS uses public-key cryptography, which relies on a pair of keys that are mathematically linked:

• The private key is a secret file you keep on your server and never share. On Ubuntu it usually lives somewhere like /etc/letsencrypt/live/example.com/privkey.pem.
• The public key can be handed out freely. It is included inside the certificate.

The magic is that data scrambled with the public key can only be unscrambled with the matching private key. So a visitor can use your public key to send a secret that only your server (holding the private key) can read. If your private key leaks, your security is gone — guard it carefully.

Certificate Authority (CA) and the chain of trust

Anyone can generate a key pair, so how does a browser know to trust your certificate? The answer is a Certificate Authority (CA) — a trusted organisation whose job is to verify you control a domain and then digitally sign your certificate. Let’s Encrypt is a free, automated CA, and it is the one we use in these docs.

Your browser does not trust your certificate directly. Instead it trusts a small set of root CAs that ship built into the operating system and browser. Those roots vouch for intermediate CAs, which in turn sign your certificate. This linked sequence is called the chain of trust:

Root CA (trusted by your browser)
   └── Intermediate CA (signed by the root)
          └── Your certificate for example.com (signed by the intermediate)

As long as every link is valid and unexpired, the browser shows the padlock. If any link is broken, expired, or self-signed (signed by you instead of a real CA), the browser shows a scary warning instead.

The TLS handshake, at a high level

Before any real data flows, the browser and server perform a quick negotiation called the handshake. You do not write code for this — the web server and browser do it automatically — but it helps to know roughly what happens.

1. The browser says hello and lists the TLS versions and encryption methods it supports.
2. The server replies and sends its certificate (including the public key and the chain).
3. The browser checks the certificate: Is it signed by a trusted CA? Is the domain name correct? Is it still valid (not expired)?
4. If the checks pass, the two sides use public-key cryptography to agree on a temporary shared secret.
5. From then on, all traffic is encrypted with that fast shared secret.

With TLS 1.3 this whole exchange takes a single round trip, which is why modern HTTPS feels just as fast as plain HTTP.

HTTP vs HTTPS — when to use which

	HTTP	HTTPS
Port	80	443
Encrypted	No	Yes
Needs a certificate	No	Yes
Browser padlock	No (often “Not secure”)	Yes
When to use	Never for real sites	Always

The honest answer in 2026 is: always use HTTPS. There is no real reason to serve a public site over plain HTTP, because certificates are now free and automatic. The only time you might use plain HTTP is a private service on your own machine that never leaves localhost.

Checking a certificate from the command line

You do not need to set anything up to inspect a live site’s certificate. Ubuntu ships with the openssl tool. Try it against any HTTPS site:

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

Output:

issuer=C=US, O=Let's Encrypt, CN=R11
subject=CN=example.com
notBefore=Apr  2 00:00:00 2026 GMT
notAfter=Jul  1 23:59:59 2026 GMT

This shows you who issued the certificate (the CA), which domain it covers (the subject), and exactly when it expires. Notice the gap between notBefore and notAfter is about 90 days — that is the standard Let’s Encrypt lifetime, which is why auto-renewal matters.

If you want to make sure your own server is using a modern protocol, you can ask which TLS version a connection negotiated:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | grep -E "Protocol|Cipher"

Output:

Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384

Seeing TLSv1.3 (or at least TLSv1.2) is what you want. Anything older should be turned off.

Best Practices

• Always serve public sites over HTTPS and redirect plain HTTP to HTTPS — never leave port 80 serving real content.
• Use a real CA such as Let’s Encrypt; only use self-signed certificates for local testing, never in production.
• Keep your private key secret — restrict its file permissions and never commit it to Git or paste it anywhere.
• Disable old protocols (SSLv3, TLS 1.0, TLS 1.1) and offer only TLS 1.2 and TLS 1.3.
• Automate renewal so a certificate never expires by surprise — a lapsed certificate breaks the whole site.
• Serve the full chain (your certificate plus the intermediate), not just the leaf certificate, or some clients will reject it.

Related Topics

• Pointing your domain to a server
• Let’s Encrypt
• Securing Nginx with Certbot
• Auto-renewing certificates
• Redirecting HTTP to HTTPS