Certificates and Trust

A TLS certificate is like an ID card for a website. It links a domain name to a public key, and a trusted third party vouches for that link with a signature.

A certificate (in the common X.509 format) mainly contains:

• Subject — who the certificate belongs to, for example example.com.
• Public key — the site's public key, used during the TLS handshake.
• Issuer — the Certificate Authority (CA) that issued and signed it.
• Validity period — a "not before" and "not after" date. Expired certificates are rejected.
• Signature — the CA's digital signature over all the above fields.

When your browser connects to https://example.com, the server sends this certificate. The browser then checks:

1. Does the domain name in the certificate match the site you are visiting?
2. Is the certificate still within its validity period?
3. Was it signed by a CA the browser already trusts?

If all three checks pass:

• The browser trusts the public key inside the certificate.
• The handshake continues.

Anyone could generate a key pair and claim "I am example.com." A Certificate Authority exists to stop that from being trusted blindly.

Before issuing a certificate, a CA runs a domain validation check. A common example: it asks the requester to publish a specific DNS record, or place a specific file on the web server, to prove they actually control that domain.

Once validation passes, the CA:

1. Takes the requester's public key and identity information.
2. Signs it with the CA's own private key (see the digital signature question in the previous topic).
3. Returns the signed certificate to the requester.

Your operating system and browser come pre-loaded with a list of trusted root CA public keys — companies like DigiCert, Let's Encrypt, and Google Trust Services are common examples. Because your browser already trusts those roots, it can automatically verify any certificate they signed, with no manual setup.

This is why installing a fake certificate on your own laptop does not fool anyone else: their browser was never told to trust your CA. Trust only spreads through certificates signed by CAs already on that trusted list.

A certificate is rarely trusted alone. Instead, browsers verify a chain, from the website's certificate up to a root the browser already trusts.

[ Root CA certificate ]        <- pre-installed and trusted by the browser
        |  signs
        v
[ Intermediate CA certificate ]
        |  signs
        v
[ Leaf certificate: example.com ]   <- sent by the server during the handshake

Why the extra "intermediate" layer? A root CA's private key is extremely sensitive — if it ever leaked, every certificate it ever signed would become untrustworthy. So root CAs keep their private key offline, in tightly controlled storage, and use it only to sign a small number of intermediate CA certificates. Intermediates then do the everyday work of signing website certificates.

How a browser verifies the chain, when it connects to a site:

1. The server sends its leaf certificate, plus any intermediate certificates.
2. The browser checks: is the leaf's signature valid, using the intermediate's public key?
3. The browser checks: is the intermediate's signature valid, using a root's public key?
4. The browser checks: is that root already in its trusted store?
5. If every check passes, the browser trusts the leaf certificate and the domain identity it represents.

Normally, a certificate is signed by a CA's private key. A self-signed certificate skips that step: the certificate's owner signs it with their own private key instead.

Normal certificate:      leaf  <-- signed by -- CA
Self-signed certificate: leaf  <-- signed by -- itself

The math still works — you can verify the signature using the public key inside the same certificate. But that only proves the certificate is internally consistent. It proves nothing about who actually controls the domain, because there is no independent CA vouching for it.

Browsers have no reason to trust a random self-signed certificate, so they show a warning like "Your connection is not private."

Good use cases:

• Local development, for example https://localhost while building an app.
• Internal tools, where you manually install the certificate as trusted on every machine that needs it.
• Testing TLS configuration before getting a real certificate.

Never use a self-signed certificate for a public-facing production website — visitors would see security warnings, and it is trivial for an attacker to also self-sign a certificate impersonating your site.

HTTP (HyperText Transfer Protocol) defines how a browser and a server exchange requests and responses. On its own, HTTP has no encryption.

HTTP:   Browser --[plain text request/response]--> Server
        (port 80 — anyone on the network path can read or change it)

HTTPS:  Browser --[TLS-encrypted request/response]--> Server
        (port 443 — wrapped in a TLS tunnel first)

HTTPS is not a separate protocol from HTTP. It is HTTP sent through a TLS connection. TLS runs underneath HTTP and adds three things HTTP alone does not have:

• Encryption — the request/response content is unreadable to anyone intercepting the traffic.
• Integrity — any tampering with the data in transit is detected.
• Authentication — the browser can verify the server's identity using its certificate.

In practice: on an HTTP site, a network attacker (for example, on shared public Wi-Fi) can read your login form data or inject their own content into the page. On an HTTPS site, the TLS layer prevents both.

Today almost the entire web runs on HTTPS. Browsers actively mark plain HTTP sites as "Not Secure," especially for anything involving forms or logins.