Certificates and TLS: How an HTTPS Site Proves Its Identity

In chapter 1 you learned that the padlock in your browser means the connection is encrypted and that the site is the one named in the address bar. Now you have the tools to understand how that works: a mix of asymmetric cryptography, hashing, a chain of trust and a short, clever conversation called the TLS handshake. After this lesson, the padlock will no longer be magic.

Lesson 2 left us with a question: if you encrypt to a public key, how do you know that the key belongs to the real owner and not to an impostor? Certificates are the answer.

The problem: trusting a public key

Suppose you connect to shop.example.com and the server sends you a public key. An attacker sitting between you and the server could hand you their own public key instead. Everything would be encrypted correctly, but to the attacker. You need a way to check that this key belongs to shop.example.com.

The solution is a digital certificate: an electronic document that links a public key to an identity (a domain name, sometimes an organisation) and that is signed by a trusted third party. A certificate typically contains:

• The subject: who the certificate is for, and the domain names it covers (in the "Subject Alternative Name" field).
• The public key of that subject.
• The issuer: the authority that signed it.
• A validity period: not valid before, not valid after.
• A serial number and the signature of the issuer.

The format used is called X.509. Remember lesson 2: a signature proves that the content was produced by the owner of a private key and has not been altered. Here the issuer signs the certificate, vouching "I verified that this key belongs to this name".

Certificate authorities and the chain of trust

The issuers are certificate authorities (CA). Your operating system and your browser come with a built-in list of root CAs that they trust, stored in a "trust store". Root CA keys are kept extremely well protected and are rarely used directly. Instead, they sign intermediate CAs, and the intermediates sign the certificates of websites. This produces a chain of trust:

Root CA (in your trust store)
  └─ Intermediate CA (signed by the root)
       └─ Server certificate for shop.example.com (signed by the intermediate)

The server sends its own certificate plus the intermediates. Your browser verifies each signature up the chain until it reaches a root it already trusts. If any link fails, the browser warns you.

How does a CA know that a requester controls a domain? In the commonly used validation, the requester proves control of the domain, for example by publishing a specific value in DNS or on the website. Here again, DNS from chapter 1 is a foundation. Some certificates also validate the identity of the organisation, but browsers have stopped emphasising that in their interface, so the padlock should not be read as an endorsement of honesty. That is why a phishing site can legitimately obtain a certificate for its own look-alike domain.

To improve transparency, certificates are recorded in public logs called Certificate Transparency logs. Anyone, including the legitimate owner of a domain, can look for certificates issued for it. Defenders use them to detect fraudulent certificates, and, as you will see in lesson 7.3, they are also a source for open-source intelligence.

What TLS is

TLS (Transport Layer Security) is the protocol that protects the connection. It succeeds the older SSL, whose name survives in common speech ("SSL certificate") although SSL itself is obsolete. TLS provides three guarantees:

• Confidentiality: data is encrypted.
• Integrity: any alteration of data in transit is detected.
• Authentication: the client verifies the server's identity (and, optionally, the server verifies the client).

The TLS handshake, in simple words

Before any web request is sent, the browser and the server perform a handshake. Here is a simplified view of a modern one:

1. ClientHello: the browser says which TLS versions and cipher suites it supports, sends a random number, and indicates the server name it wants to reach.
2. ServerHello: the server selects the parameters and sends its own random number, and its certificate chain.
3. Verification: the browser checks the chain up to a trusted root, that the name matches, that the certificate is within its validity period and has not been revoked.
4. Key agreement: both sides use a key exchange (typically with temporary keys, giving forward secrecy) to compute the same shared secret, without ever sending it across the wire. The server proves that it owns the private key matching the certificate.
5. Encrypted communication: from there, everything is encrypted and authenticated with symmetric keys derived from the shared secret.

This is hybrid encryption in action. Asymmetric cryptography authenticates the server and establishes a secret; fast symmetric encryption protects the data. In the packet capture of chapter 2, you saw the first messages of this handshake in clear text, then only unreadable data.

Looking at a certificate yourself

In your browser, click the padlock next to the address bar and open the certificate details. Look at the issuer, the validity dates and the covered names. From the command line, openssl can display the same information for a site you are allowed to connect to. An ordinary HTTPS connection to a public documentation site is no different from what your browser does; do not use this against systems that you do not own for anything other than viewing the certificate.

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

This connects, retrieves the certificate and prints its subject, issuer and validity dates. The -servername option sends the server name in the ClientHello, which lets a server that hosts many sites choose the right certificate.

Things that go wrong

Understanding the mechanism helps you interpret browser warnings and typical weaknesses:

• Expired certificate: the validity period has ended. Often just an administrative oversight, but users get trained to click through warnings, which is dangerous.
• Name mismatch: the certificate does not cover the domain visited. It can be a misconfiguration, or a sign of interception.
• Untrusted issuer or self-signed certificate: no chain to a trusted root. Perfectly normal in your lab (you create your own certificates for testing), but a warning sign on the public Internet.
• Revoked certificate: the CA has cancelled it, for example after a private key leak. Browsers have mechanisms to check this.
• Weak configuration: old protocol versions or weak cipher suites enabled for compatibility. Security assessments test for this, and public guidelines from ANSSI, NIST and OWASP describe good configurations.
• Compromised or misused CA: rare, but historical incidents led to stronger rules and to Certificate Transparency.
• Stolen private key: with the key, an attacker can impersonate the site, which is why key protection (lesson 4) matters.

Companies sometimes deploy an inspection proxy which decrypts and re-encrypts traffic, using a CA certificate installed on managed devices. It is legitimate in a corporate context with transparency, but it illustrates why you must never install a certificate authority from an unknown source in your trust store: whoever controls a trusted CA can impersonate any website to you.

Your turn: examine a certificate and create a lab certificate

First, examine the certificate of a public documentation site such as example.com in your browser, and note the issuer, the validity period and the covered names. Check how many certificates in the chain you can see. Second, in your lab, generate a self-signed certificate for a test name, to see what an untrusted certificate is:

openssl req -x509 -newkey rsa:2048 -nodes -keyout lab.key -out lab.crt -days 30 -subj "/CN=webserver.lab"
openssl x509 -in lab.crt -noout -subject -issuer -dates

Explain in your notebook why the subject and the issuer are the same, and why a browser would warn about this certificate.

See a solution

For the public site, you should see a certificate issued by an intermediate CA, itself signed by a root CA found in your trust store, with a validity period of a limited duration and one or several names listed in the Subject Alternative Name. For your self-signed certificate, the subject and issuer are identical because the certificate signs itself: there is no external authority vouching for it. A browser will warn, because the chain does not lead to any root it trusts, even if the encryption would work. The lab.key file is the private key; keep it protected (chmod 600 lab.key) even in a lab, as good practice. Delete both files when you finish if you do not need them.