Every time you type an address that starts with https://, a short but sophisticated negotiation happens before the first byte of the page arrives. Understanding that negotiation explains a lot: why certificates expire, why browsers show scary warnings, and why the padlock icon means less than most people assume.
HTTP, HTTPS and TLS: sorting out the names
HTTP is the protocol browsers and servers use to exchange web pages. On its own, it sends everything in plain text — anyone able to observe the connection can read it.
HTTPS is not a different protocol. It is ordinary HTTP wrapped inside a secure layer called TLS (Transport Layer Security), the modern successor to SSL. People still say “SSL certificate” out of habit, but the protocol in use today is TLS.
That secure layer provides three things:
- Confidentiality — the traffic is encrypted, so observers see scrambled bytes.
- Integrity — tampering with the data in transit is detected.
- Authentication — the client can verify it is talking to the server it intended to reach.
What a certificate actually is
A TLS certificate is a digital document that binds a public key to a domain name. It is signed by a Certificate Authority (CA) — an organisation that browsers and operating systems have agreed to trust.
A certificate typically contains:
| Field | Meaning |
|---|---|
| Subject / Common Name | The domain the certificate covers |
| Subject Alternative Names | Additional domains or subdomains covered |
| Public key | The key clients use to establish the session |
| Issuer | The Certificate Authority that signed it |
| Validity period | Start and expiry dates |
| Signature | The CA’s cryptographic endorsement |
Trust works as a chain. Your browser ships with a store of root certificates. A root signs an intermediate, and the intermediate signs the certificate on the website. If the browser can follow that chain up to a root it already trusts, and every signature checks out, the certificate is accepted.
The handshake, step by step
Before any page content moves, client and server run a handshake. Simplified, it looks like this:
- Hello from the client. The browser announces which TLS versions and cipher suites it supports, plus a random value and the hostname it wants to reach.
- Hello from the server. The server picks a mutually supported TLS version and cipher suite and sends its certificate chain.
- Certificate validation. The browser checks the signature chain, the expiry dates, whether the hostname matches, and whether the certificate has been revoked.
- Key agreement. Both sides derive a shared secret, typically using a Diffie-Hellman key exchange, and confirm that the server holds the private key matching the certificate.
- Switch to encrypted traffic. From this point on, the actual HTTP request and response travel encrypted with fast symmetric cryptography.
Two design choices deserve attention. First, asymmetric cryptography is used only to set up the session; the bulk transfer uses symmetric encryption because it is far faster. Second, modern cipher suites provide forward secrecy: session keys are ephemeral, so an attacker who later obtains the server’s private key still cannot decrypt traffic recorded in the past.
Types of certificate
- Domain Validation (DV) — the CA verifies only that the applicant controls the domain. Issued automatically and often free.
- Organisation Validation (OV) — the CA also checks that the organisation exists.
- Extended Validation (EV) — the most thorough vetting of the legal entity. Browsers no longer display it prominently.
- Wildcard — covers all subdomains at one level, such as
*.example.com.
Crucially, all three validation levels give the same encryption strength. Validation level is about identity checks, not cryptographic quality.
What the padlock does and does not tell you
This is the most common misunderstanding in web security. The padlock means: the connection to this server is encrypted, and the certificate is valid for this hostname.
It does not mean the site is honest, safe or reputable. A phishing page can obtain a free DV certificate for a lookalike domain in minutes and display exactly the same padlock. Encryption protects the pipe, not the intentions of whoever is at the other end. Always read the domain name itself, not just the icon beside it.
Common browser warnings and what causes them
| Warning | Typical cause |
|---|---|
| Certificate expired | Renewal was missed or automation failed |
| Name mismatch | Certificate does not cover the hostname used |
| Untrusted issuer | Self-signed certificate, or missing intermediate in the chain |
| Mixed content | An HTTPS page loading images or scripts over plain HTTP |
| Clock error | The device’s date and time are wrong |
The “missing intermediate” case is a classic: the site works in one browser and fails in another, because some clients cache intermediates and others do not. Serving the full chain from the server avoids the problem entirely.
Good practice for site owners
- Automate renewal. Short-lived certificates are the norm, and expiry outages are almost always avoidable.
- Redirect HTTP to HTTPS so visitors never land on the insecure version.
- Enable HSTS to tell browsers to use HTTPS for your domain from the start.
- Disable obsolete protocol versions and weak cipher suites.
- Protect the private key. If it leaks, the certificate must be revoked and reissued.
- Fix mixed content so every asset loads over HTTPS.
Why this matters beyond websites
The same mechanisms secure mobile app traffic, email delivery between servers, database connections and API calls between microservices. Once the handshake makes sense, a long list of “how is this secured?” questions becomes much easier to answer.
If you would like to go deeper into certificates, key exchange and practical server hardening, the free cyber security and IT courses available on Cursa are a solid next step — the concepts here sit at the foundation of almost everything else in the field.
