What Is HTTPS? Encryption, Certificates and TLS Explained Simply (2026)

What is HTTPS? HTTPS stands for Hypertext Transfer Protocol Secure. It is the encrypted version of HTTP, the protocol your browser uses to load web pages. Technically, HTTPS is nothing more than ordinary HTTP sent through an encrypted tunnel. That tunnel is called TLS (Transport Layer Security), formerly SSL. It does three things: nobody along the way can read along, nobody can change the data without being noticed, and your browser knows it is really talking to the right server.

Everyone knows the padlock in the address bar. Surprisingly few people know exactly what it promises, and even fewer know what it does not promise. That’s what this article is about, and not just in theory. We run a whole bunch of websites on our own server, and on October 30, 2026 we measured what HTTPS actually does in practice. Three findings up front:

1. We sent the same request with a made-up password to our server once over HTTP and once over HTTPS, and captured the network traffic. Over HTTP, passwort=geheim123 (“password=secret123”) showed up three times in plain text in the capture. Over HTTPS: zero hits. The only readable word left was the domain name.

2. The encrypted handshake costs us roughly 17 milliseconds. That’s the whole price.

3. Our server holds 1,042 certificates, all renewed automatically. Even so, we once had a site go down after a server move, because a certificate was copied over instead of being set up properly. More on that below.

What is HTTPS? The short version in five sentences

1. HTTP is the language browsers and web servers speak. It was designed in the early 1990s, when nobody worried about eavesdroppers, and it sends everything in plain text.
2. HTTPS wraps exactly that conversation in an encrypted channel. The channel is provided by TLS, the successor to SSL.
3. Before the actual page flows, browser and server negotiate a shared secret key in a short handshake, without ever sending that key over the wire.
4. A certificate proves along the way that the server really belongs to the domain you typed. It is issued by a certificate authority that your browser trusts.
5. HTTPS protects the connection. It says nothing about whether the website itself is honest.

Remember the fifth point. It’s the source of most misunderstandings about the padlock.

HTTP vs HTTPS: what’s the difference?

The difference between HTTP and HTTPS isn’t what gets transmitted, but how. The request itself is identical: GET /blog/ HTTP/1.1, a few headers, maybe some form data. With HTTP, those bytes travel as they are across every cable, every Wi-Fi router and every network hop between you and the server. Anyone with access along the way can read them and even change them.

With HTTPS, exactly the same bytes are encrypted first. Along the way, all anyone sees is noise.

Our capture: what goes over the wire without HTTPS

Instead of just claiming this, we tried it. We ran tcpdump, a tool that records network packets, on our server. Then we sent two requests, one unencrypted and one encrypted, both with a made-up password in the URL:

# start capturing
tcpdump -i lo -s0 'tcp port 80 or tcp port 443' -w https-demo.pcap &

# once without, once with encryption
curl -s "http://getmind.io/?passwort=geheim123"
curl -s "https://getmind.io/?passwort=geheim123"

# how often does the password appear in the capture?
tcpdump -r https-demo.pcap -A 'tcp port 80'  | grep -ac geheim123   # → 3
tcpdump -r https-demo.pcap -A 'tcp port 443' | grep -ac geheim123   # → 0

The result is clear-cut. In the HTTP part, the password was readable three times: once in the request (GET /?passwort=geheim123 HTTP/1.1), plus twice in the response, because our server redirects HTTP to HTTPS and sends the full URL back in the redirect. A nice detail: even the redirect to HTTPS gives away whatever was requested unencrypted first. The redirect simply comes too late.

In the HTTPS part: zero hits. Not the password, not the path, not the headers, not the content of the page. Exactly one thing was visible, getmind.io, and only once. Why the domain name in particular leaks is explained further down under SNI.

We ran this test locally on the server so nobody else was affected. On public Wi-Fi, an attacker with the same tool sees exactly the same thing. That’s why logging in over HTTP in a coffee shop used to be the textbook example. In 2010, the Firefox add-on Firesheep showed how trivial it was to hijack other people’s Facebook and Twitter sessions that way. Shortly afterwards, the big platforms switched to HTTPS.

How does HTTPS work? The TLS handshake step by step

HTTPS has a chicken-and-egg problem to solve. For browser and server to talk in encrypted form, both need the same secret key. But they can’t just send it to each other, because the connection is exactly what’s insecure. The solution is one of the most elegant ideas in cryptography: key exchange.

Here’s what a TLS 1.3 handshake looks like, simplified:

1. Client Hello. Your browser says: “Hi, I want getmind.io, I speak TLS 1.3 and these cipher suites, and here’s my half of the key exchange.”
2. Server Hello. The server answers: “Okay, TLS 1.3 with this cipher, and here’s my half.” From the two halves, both sides independently compute the same secret key. An eavesdropper who sees both halves still can’t compute it. That’s the Diffie-Hellman principle, today usually in its elliptic-curve variant (ECDHE).
3. Certificate and signature. From this point on, everything is already encrypted. The server sends its certificate and signs the handshake so far with its private key. That proves it is the real owner of the certificate.
4. Browser check. Your browser checks: does the name in the certificate match the domain? Is it still valid? Was it signed by an authority I trust? Is the signature correct?
5. Finished. Both sides confirm they saw the same thing. After that, completely normal HTTP flows, just encrypted.

With TLS 1.3, all of this needs just one round trip between browser and server. The older TLS 1.2 needed two. On repeat visits, it can even work without an extra round trip.

Our connection in detail

With openssl you can inspect the handshake of any website yourself. Here’s what ours looks like:

echo | openssl s_client -connect getmind.io:443 -servername getmind.io 2>/dev/null \
  | grep -E "Protocol|Cipher|Server public key|Verify return"

Protocol  : TLSv1.3
Cipher    : TLS_AES_128_GCM_SHA256
Server public key is 256 bit
Verify return code: 0 (ok)

In plain English: the connection runs over TLS 1.3. The actual data is encrypted with AES-128 in GCM mode, a scheme that encrypts and detects tampering at the same time. The server key is a 256-bit elliptic-curve key (ECDSA). If 256 bits sounds small: a 256-bit ECDSA key is considered roughly as strong as a classic 3,072-bit RSA key, but it’s much faster.

We also checked which protocol versions our server accepts at all:

That’s exactly how it should be. TLS 1.0 and 1.1 were officially deprecated in 2021 (RFC 8996), and all major browsers have turned them off. TLS 1.2 stays allowed for older devices. By the way, we didn’t configure any of this: it’s simply the default in Caddy, our web server.

What is an SSL certificate, and what does it prove?

Without a certificate, encryption would be worthless. You’d have an encrypted connection, but you wouldn’t know who it’s with. An attacker on the same Wi-Fi could simply sit in the middle, build one encrypted channel with you and a second one with the real server. That’s called a man-in-the-middle attack.

The certificate prevents exactly that. It’s a digital document that basically says: “Public key X belongs to the domain getmind.io. Signed: Let’s Encrypt.” Ours looks like this:

echo | openssl s_client -connect getmind.io:443 -servername getmind.io 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

subject=CN = getmind.io
issuer=C = US, O = Let's Encrypt, CN = YE1
notBefore=Sep  6 09:45:18 2026 GMT
notAfter=Dec  5 09:45:17 2026 GMT
X509v3 Subject Alternative Name:
    DNS:getmind.io

Three things stand out. First, the certificate is issued only for getmind.io, nothing else. Second, it’s valid for exactly 90 days. Third, it was issued by Let’s Encrypt, a non-profit certificate authority that has handed out free certificates since 2015 and made most of the HTTPS boom possible in the first place.

The chain of trust

How does your browser know it can trust Let’s Encrypt? Through a chain. Our server sends not only its own certificate but also the intermediate certificates:

0  getmind.io            ← issued by YE1
1  Let's Encrypt YE1     ← issued by Root YE
2  ISRG Root YE          ← issued by ISRG Root X2
3  ISRG Root X2          ← issued by ISRG Root X1

At the end of the chain is a root certificate. Root certificates are built into your operating system or browser, around 150 of them. The browser climbs from our certificate link by link up to a root it knows. If that works, the chain is valid. If it doesn’t, you see the red “Your connection is not private” warning.

A small side observation: the chain Let’s Encrypt serves in autumn 2026 is longer than it used to be and runs through new intermediate and root certificates (YE1, Root YE). For visitors, nothing changes. For admins who have to support old devices or very old Java versions, a switch like this can be the reason individual clients suddenly throw errors. The question is almost always whether the device already knows the root in question.

DV, OV, EV: are there “better” certificates?

Certificates come in three validation levels:

The encryption is exactly as strong with all three. The only difference is how thoroughly the owner was checked. Browsers used to show the company name in green in the address bar for EV certificates. Chrome and Firefox dropped that in 2019 because studies showed users didn’t notice the difference anyway. For a blog, a small shop or a company site, a free DV certificate is completely sufficient today. We use nothing else for any of our sites.

What HTTPS does not protect

The padlock is an honest symbol, but people tend to overrate it. Here are the most important limits.

HTTPS says nothing about whether a website is legitimate. Phishing sites nearly always have a valid certificate these days, since it costs nothing and takes seconds. The padlock only means you’re talking securely to the server of paypa1-login.example. Whether that’s a good idea, it doesn’t decide. That’s exactly why Chrome replaced the padlock with a neutral “tune” icon in 2023. Google itself had found that many users misread the padlock as “this site is trustworthy”.

The domain name usually stays visible. Remember our capture? The only readable thing in the HTTPS part was getmind.io. The reason is called SNI (Server Name Indication). Our server hosts over a thousand domains on the same IP address. So the server knows which certificate to present, the browser names the domain at the very start of the handshake, still unencrypted. Your ISP or the coffee-shop Wi-Fi can therefore see which site you visit, but not what you do there. The Encrypted Client Hello (ECH) extension is meant to encrypt that too, but it isn’t everywhere yet. On top of that, the DNS lookup also gives the name away if it isn’t encrypted. We showed how DNS works in What is DNS?.

As a side effect, our capture confirmed exactly that: in packets from other connections that happened to pass through the server at the same moment, readable domain names showed up as well, and only the names.

HTTPS doesn’t protect against attacks on the server itself. If a website has a security hole or its database stores unencrypted passwords, an encrypted line to it doesn’t help. How quickly that can happen is described in our article on IT security vulnerabilities.

HTTPS doesn’t protect against malware on your device. A trojan reads along before the data is encrypted.

Inside your server, things are often plain text again. Many setups terminate encryption at a reverse proxy and talk to the application behind it unencrypted. On the same machine that’s fine, across someone else’s network it isn’t. How that works is explained in What is a reverse proxy?.

Does HTTPS make a website slower?

This used to be a serious argument against HTTPS. Not anymore. We measured five times in a row how long it takes to connect to getmind.io:

curl -s -o /dev/null -w "%{time_connect} %{time_appconnect}\n" https://getmind.io/

# TCP connected   TLS done
0.0015 s          0.0188 s
0.0014 s          0.0195 s
0.0013 s          0.0186 s
0.0012 s          0.0192 s

The TCP connection is up after just over a millisecond, and the TLS handshake finishes roughly 17 to 18 milliseconds later. (The very first run needed an extra 170 ms for the DNS lookup, which has nothing to do with HTTPS.) For comparison: loading a single image on a typical website takes longer.

On top of that, HTTPS often makes websites faster in practice, not slower. Every browser supports HTTP/2 and HTTP/3 only over encrypted connections. These newer versions load many files at once over a single connection instead of one after another. Our server actively advertises HTTP/3:

HTTP/2 200
alt-svc: h3=":443"; ma=2592000
server: Caddy

So anyone sticking with HTTP/1.1 to avoid HTTPS loses more time than they save. The CPU load on the server is barely measurable on modern processors with AES acceleration.

Is HTTPS required?

There’s no law that literally says “use HTTPS”. In practice, though, you can’t get around it:

• GDPR Article 32 (in the EU) requires “appropriate technical measures” to protect personal data. As soon as your site has a contact form, a login, a newsletter or a shop, personal data is transmitted. European data protection authorities have treated unencrypted forms as a violation for years, and fines have already been issued for it. Similar expectations exist under other privacy laws.
• Browsers label HTTP sites “Not secure”. Chrome warns even more prominently about forms on HTTP pages. Many visitors leave right there.
• Google has used HTTPS as a (small) ranking signal since 2014.
• Payment providers like Stripe or PayPal and the card industry standard PCI DSS require encrypted connections.

In short: for any website that does anything with user data, HTTPS is effectively mandatory. For everyone else it’s the standard, and there’s no good reason left to skip it. According to Google’s Transparency Report, well over 90 percent of all page loads in Chrome now happen over HTTPS.

Setting up HTTPS on your own server

The good news: these days it’s neither expensive nor complicated. There are two common routes.

Route 1: a web server that does it automatically

Our web server Caddy fetches certificates from Let’s Encrypt entirely on its own as soon as a domain appears in its config. The config for one site is literally three lines:

getmind.io {
    root * /var/www/getmind
    file_server
}

On first request, Caddy obtains a certificate, automatically redirects HTTP to HTTPS and renews the certificate well before it expires, without you doing anything. That’s how our server currently manages 1,042 certificates. We haven’t touched a single one by hand.

Route 2: nginx or Apache with certbot

If you use nginx or Apache, you’ll usually reach for certbot, the official Let’s Encrypt tool:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

certbot verifies that you control the domain, gets the certificate, adds it to the nginx config and sets up a timer for automatic renewal. To test whether renewal works:

sudo certbot renew --dry-run

How to set up nginx as a reverse proxy with HTTPS in general is covered in our nginx reverse proxy guide. If you’re still deciding which web server suits you, see Apache vs nginx.

The trap we fell into ourselves

Let’s Encrypt certificates expire after 90 days. That’s on purpose: short lifetimes force automation, and a stolen key isn’t usable for years. The industry is going further still. In 2025, browser vendors and certificate authorities agreed to cut the maximum lifetime step by step to 47 days by 2029.

But that also means: a certificate without working renewal is a time bomb on a 90-day fuse. That’s exactly what happened to us. During a server move, one website’s certificate was copied to the new server as a file. The site worked, the padlock was there, everything looked fine. What didn’t come along was the renewal configuration. Three months later the certificate expired, and the site was unreachable for a few hours until a new one was issued.

The lesson we’ve followed on every move since:

1. Never just copy certificates. Either have them re-issued on the new server, or take the whole /etc/letsencrypt directory with you, including renewal/*.conf.
2. Run certbot renew --dry-run right after the move. It’s the only proof that the next renewal will work.
3. Note the expiry date and monitor it. A green padlock today says nothing about the padlock in three months.

A simple check you can run from a cron job:

# days until expiry
end=$(echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
echo $(( ( $(date -d "$end" +%s) - $(date +%s) ) / 86400 )) days

For our getmind.io certificate, that returned just over 35 days at the time of writing. Caddy renews once a third of the lifetime is left, so within the next few days. How to run checks like this on a schedule is shown in our cron job guide.

Redirecting HTTP to HTTPS

Once you have HTTPS, don’t just switch HTTP off; redirect it. Otherwise visitors who type the address without https:// land on an error page. Our server answers HTTP like this:

HTTP/1.1 308 Permanent Redirect
Location: https://getmind.io/
Server: Caddy

The 308 (or 301) code tells browsers and Google that the page has moved permanently. In nginx, the matching rule looks like this:

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

HSTS: the step many people forget

Remember that detail from our capture? The redirect from HTTP to HTTPS came too late. The first request went out unencrypted, password in the URL and all. An attacker on the same network could intercept exactly that first request and simply never let the visitor reach HTTPS. That’s called SSL stripping.

The countermeasure is HSTS (HTTP Strict Transport Security). The server sends a header telling the browser: “From now on, only talk to me over HTTPS, no matter what gets typed.” From the second visit on, not a single unencrypted request goes out. Here’s the header GitHub sends:

strict-transport-security: max-age=31536000; includeSubdomains; preload

And now the honest part: getmind.io doesn’t send this header. We measured it while writing this article (curl -sI https://getmind.io/ | grep -i strict → no match). Caddy handles certificates and redirects automatically, but not HSTS. You have to add it yourself:

getmind.io {
    header Strict-Transport-Security "max-age=31536000; includeSubDomains"
    ...
}

It’s now on our list. One important thing first, for us too: HSTS is hard to undo. If you set max-age to a year and then run a subdomain without HTTPS, you lock visitors out for a year. So start with short values (say max-age=300), check every subdomain, and only then increase it. Only add preload (inclusion in a list built into browsers) once you’re absolutely sure.

Common HTTPS errors and what they mean

“Your connection is not private” / NET::ERR_CERT_DATE_INVALID. The certificate has expired, or the clock on your device is wrong. As a visitor: check the time. As an operator: fix renewal, see above.

NET::ERR_CERT_COMMON_NAME_INVALID. The certificate is for a different name. Typical case: it was issued only for example.com, but www.example.com is being requested. Fix: include both names in the certificate.

NET::ERR_CERT_AUTHORITY_INVALID. The chain doesn’t end at a known root. Either the certificate is self-signed or the server isn’t sending the intermediates. In nginx, ssl_certificate must point to fullchain.pem, not cert.pem. We see this mistake in forums all the time.

Mixed content. The page itself loads over HTTPS but pulls images or scripts via http://. Browsers then block insecure scripts completely and the padlock disappears. Fix: switch all internal links to https:// or relative paths. On WordPress, a search-and-replace in the database helps.

Redirect loop. Typical behind Cloudflare or another proxy: the proxy talks to your server over HTTP, the server redirects to HTTPS, the proxy calls again over HTTP. Fix: choose “Full (strict)” mode at the proxy so it also encrypts towards your server.

Frequently asked questions

What is HTTPS in simple terms?

HTTPS is the encrypted version of HTTP, the language your browser uses to fetch web pages. Everything that goes back and forth between you and the website is packed so that nobody along the way can read or change it. A certificate also makes sure you’re really talking to the site you typed.

What is the difference between HTTP and HTTPS?

HTTP sends everything in plain text, HTTPS encrypts the data with TLS. In our test, a password showed up readable three times in the network capture over HTTP and not once over HTTPS. HTTPS also verifies the server’s identity with a certificate. HTTP uses port 80, HTTPS port 443.

What is the difference between SSL and TLS?

SSL is the old name, TLS the current one. SSL 2.0 and 3.0 have been insecure and disabled for years. What’s sold today as an “SSL certificate” is really a certificate for TLS; the term SSL just stuck in everyday language. The current versions are TLS 1.2 and TLS 1.3.

Is a website with HTTPS automatically safe?

No. HTTPS only secures the connection. Scam sites almost always have a valid certificate too, because it’s free. The padlock tells you nobody is listening in, not that the site is trustworthy. Always check the exact domain in the address bar as well.

How much does an SSL certificate cost?

A certificate that verifies your domain (DV) is free from Let’s Encrypt or ZeroSSL. For encryption, it’s just as good as a paid one. Organization or EV certificates cost roughly $50 to $500 a year and also vet the company, but since 2019 they’ve brought visitors hardly any visible benefit.

How can I tell if a site uses HTTPS?

The address starts with https://. Depending on the browser, you’ll see a padlock or a neutral settings icon, while HTTP sites show “Not secure”. Click the icon to view the certificate: which domain it’s for, who issued it and until when it’s valid.

Can my internet provider see which sites I visit?

Which domain you open, usually yes, through the name in the TLS handshake (SNI) and through the DNS lookup. Which page on that site, what you search for, what you type and what the page shows, no. That’s all encrypted. Encrypted DNS and, once widespread, Encrypted Client Hello add more privacy.

Is HTTPS required for my website?

There’s no law with the word HTTPS in it. But as soon as your site has forms, logins or a shop, privacy laws like the GDPR require secure transmission, which in practice means HTTPS. Apart from that, browsers warn about HTTP sites and Google slightly favors HTTPS in rankings.

Does HTTPS slow down my website?

Barely measurably. On our server, the TLS handshake takes about 17 milliseconds. Because HTTP/2 and HTTP/3 only work over HTTPS, a site often ends up faster overall.

How long is an HTTPS certificate valid?

Let’s Encrypt certificates are valid for 90 days and renew automatically. Paid certificates currently last at most about a year. Under an industry decision from 2025, the maximum lifetime will drop step by step to 47 days by 2029, which makes automatic renewal no longer optional.

Conclusion: what is HTTPS, and what should you do?

HTTPS is the invisible foundation of almost every website. It encrypts the connection, prevents unnoticed tampering and makes sure you’re talking to the right server. Our capture shows the difference quite soberly: password in plain text three times versus zero. The price is about 17 milliseconds and, thanks to Let’s Encrypt, zero dollars.

If you’re a visitor: look for https://, but don’t blindly trust the padlock. It protects the line, not you from scammers.

If you run a website:

1. Set up HTTPS, easiest with Caddy or certbot.
2. Permanently redirect HTTP to HTTPS (301 or 308).
3. Test automatic renewal, don’t just assume it. And test again after every server move.
4. Add HSTS, starting with a short max-age.
5. Turn off TLS 1.0 and 1.1 if your server still offers them.

While writing this article, we learned that one item was missing on our side too: HSTS. That might be the most important takeaway of all. A green padlock feels finished, but it isn’t always. If you want to harden your server step by step, setting up a Linux server and setting up a UFW firewall cover the next steps.