Behind the padlock there are two distinct mechanisms worth keeping separate, because confusing them is the origin of the web’s most widespread misunderstanding:
- encryption, which makes what you exchange unreadable;
- the certificate, which establishes who you are exchanging it with.
The first protects the content. The second protects you from the mistake of talking to somebody else. Both are needed, and together they still do not say the site is honest — we come back to that at the end.
It expands on the recommendation browsing only over HTTPS.
The starting problem
Two parties who have never met have to exchange confidential information over a public channel, observable by anybody.
It looks impossible: encrypting requires a shared key, but sharing the key would require a channel that is already secure. It is a circular problem, and it was solved in the 1970s with an elegant idea.
Public-key encryption. Each party has two mathematically linked keys: a public one, which can be given to anybody, and a private one, which stays secret. What is encrypted with the public key can be decrypted only with the private one.
That breaks the circle: the public key can travel in the clear, because knowing it allows nothing to be read.
What happens when you open a site
Four steps, in a fraction of a second.
1. The browser says hello. It contacts the server and states which encryption methods it can use.
2. The server introduces itself with the certificate. A digital document containing the domain name, the server’s public key, the expiry date and a certification authority’s signature.
3. The browser verifies the certificate. Three checks: is the authority’s signature valid and recognised? Has the certificate not expired? Does the domain name match the one you typed? If a single one fails, a warning appears.
4. A session key is agreed. Using public-key encryption, the two parties establish a shared temporary key, used for the rest of the conversation because it is much faster.
From that moment all the traffic is encrypted with a key that exists only for that session and that no observer saw pass.
Step 3 is what holds the whole structure up, and it deserves explaining.
Without verification, anybody could present a certificate declaring “I am your bank”. Somebody has to vouch — an authority that, before issuing a certificate for a domain, checks that whoever asks for it really controls it.
The chain of trust works like this:
- your device holds a list of authorities considered trustworthy, updated with the operating system and the browser;
- every certificate is signed by one of those authorities, directly or through intermediaries;
- the browser follows the chain up to an authority on the list.
If the chain breaks or leads to an unknown authority, the warning appears. It is why home devices always produce a warning: their certificate is signed by nobody — they made it themselves.
What a certificate actually verifies
It is the central point of the whole unit.
The certificate attests one thing only: that whoever answers really controls the domain written in the address. It does not attest:
- that whoever controls that domain is honest;
- that the site handles data correctly;
- that the domain is the one you meant to reach.
The last line is the most important. If you type bank-com.net instead of bank.com, the certificate for bank-com.net is perfectly valid — because that domain really is controlled by whoever answers you. The system worked correctly and took you exactly where you asked to go.
Obtaining a certificate today is free and automated. That was a positive change — it made the web encrypted by default — but it also removed every economic barrier for whoever sets up a fraudulent site.
The practical conclusion: the certificate solves the interception problem, not the deception problem.
How modification gets detected
A less known aspect of modern encryption: it protects not only from reading, but from alteration.
Every block of data travels accompanied by a value computed on the content and on the session key. If something is changed along the route, the value no longer matches and the browser refuses the data instead of showing it.
It is the technical reason why, over an encrypted connection, nobody can insert content into a page or replace a file being downloaded. Not because they cannot read it, but because any modification is detected.
What stays visible to an observer
Technical honesty: encryption does not make everything invisible.
| What | Visible to whoever watches the network? |
|---|---|
| The content of the pages | No |
| Data entered into forms | No |
| Credentials | No |
| Which site you are contacting | Largely yes |
| The amount and rhythm of traffic | Yes |
| The duration of the connection | Yes |
The fourth row needs a clarification: resolving the site’s name and some data from the initial negotiation can reveal the destination. Technologies exist that reduce that exposure, but they are not yet universal.
Hence a useful distinction: HTTPS protects the content, not entirely the fact that you are visiting a certain site. It is exactly the space the recommendations on VPNs address.
The three kinds of certificate, and why they no longer matter
The distinction used to be relevant and browsers showed it visually. Today they do not, and knowing why saves you looking for information that is no longer there.
| Type | What the authority verifies | Cost |
|---|---|---|
| Domain validation | Only that the applicant controls the domain | Free, automatic |
| Organisation validation | Also the organisation’s existence | Paid |
| Extended validation | An in-depth documentary check | Paid, more expensive |
Until a few years ago, extended-validation certificates produced a green bar with the company’s name. That indication has been removed by every major browser, for a concrete reason: studies showed users did not notice it, and that when they did notice they did not interpret it correctly.
The practical result is that today the browser tells you nothing about the kind of certificate, and for ordinary browsing that is not a problem: the technical protection — encryption and domain verification — is identical in all three cases.
The consequence to keep in mind, though, is this: there is no longer any visual indicator of the holder’s seriousness. Judging the site’s trustworthiness rests exclusively on the domain name and the context.
The versions, and why they count
Encryption protocols have been updated several times, and the old versions have known weaknesses. Modern browsers refuse the outdated ones, and that sometimes produces warnings on dated sites.
There is nothing to configure: just keep the browser up to date, since it knows which versions to accept and which not. It is one of the ways the recommendation on updates supports this one.
What happens when a certificate is revoked
A little-discussed aspect that explains some apparently inconsistent browser behaviour.
A certificate has an expiry, but it can also be revoked earlier, typically because the server’s private key was compromised. From that moment it should no longer be accepted.
The problem is checking that: the browser would have to ask the authority whether that certificate is still valid, and that means an extra request on every connection. It is slow, it reveals which sites you visit, and it fails if the authority does not answer.
Two solutions are used today, both partial:
- revocation lists distributed with the browser, updated periodically and limited to the most significant cases;
- a confirmation attached by the server itself, which presents a recent statement from the authority alongside the certificate.
That explains a design choice with practical consequences: certificates today have short lifetimes, often a few months. It is not bureaucratic complication — it is the most effective way of limiting the damage of a revocation that does not get through: a compromised certificate stops working within a short time anyway.
For anyone browsing, there is a single effect: expired-certificate warnings are more frequent than they used to be, and in most cases they indicate a forgotten renewal, not an attack.
Why the browser remembers which sites require encryption
A little-known mechanism that solves a specific problem: the window between the first contact and the switch to an encrypted connection.
If you type only a site’s name, the browser would first try a connection in the clear, and the site would answer by redirecting it. It is a fraction of a second, but it is a fraction of a second in the clear — the window exploited by the downgrade technique.
The solution adopted works on two levels.
The site’s declaration. A site can tell the browser, through a header in its response, that from now on it must be contacted only in encrypted form, for a stated period. The browser notes it, and from the next visit no longer attempts a connection in the clear.
The preloaded list. The very first visit remains uncovered. That is why there is a list of domains distributed with the browser, containing the sites that have asked to be treated that way from the first contact. Most major services are on it.
The practical result: for important sites the window in the clear no longer exists, not even on a first visit. And the browser’s HTTPS-only mode extends the same behaviour to every site, closing the matter for good.
It is a good example of how this area has improved: a problem that ten years ago required the user’s attention is today solved by a default setting.
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Skills | Telling encryption, certificate and site identity apart |
| Awareness | Understanding why the certificate does not certify honesty |
| Secure Behaviour | Keeping up to date the browser the verification depends on |
Reference level: FL3 — Autonomous.
Summary
- There are two mechanisms: encryption protects the content, the certificate establishes who you are talking to.
- The certificate attests only that whoever answers controls that domain.
- Any modification in transit gets detected and the browser refuses the data.
- The content is protected; the destination stays largely visible.
One thing to do today. Click the padlock on the site you are reading and open the certificate details. Look at the domain field: that, and only that, is what the system guarantees.
Related content
- Browsing only over HTTPS — the recommendation this expands on
- How to check a website is safe — the practical procedure
- Traffic interception — what this mechanism prevents
- Signs of an unprotected connection — why certain warnings appear
Related resources
Short reads from the Resources section, for anyone who wants to stop on a single aspect:
Start with the first step: the Cyber Welfare Programme guides you free of charge, one recommendation at a time.
