TLS and certificates

The server must prove it holds the private key for a certificate issued for the name you asked for. A wrong answer from DNS, or a machine in the middle, cannot pass without that key, so the client stops (curl exit 60). Clicking through the warning gives the protection away. The name still travels in the clear in the handshake (SNI).

How TLS works, step by step

TLS gives a TCP connection two things: encryption, and proof that the server is who the client asked for. HTTPS is HTTP inside TLS, on port 443. A TLS 1.3 handshake (RFC 8446) takes one round trip:

1. ClientHello. The client sends the versions and cipher suites it supports, a key share (its half of an ephemeral Diffie-Hellman exchange, usually X25519), the name it wants in the SNI extension, and the application protocols it speaks in ALPN (h2, http/1.1). This message is not encrypted, so the name is visible on the wire.
2. ServerHello. The server picks a suite and sends its own key share. Both sides can now compute the same secret, and everything after this is encrypted.
3. Certificate. The server sends its certificate and the intermediate certificates that lead to a root.
4. CertificateVerify. The server signs the handshake so far with its private key. This is the actual proof: anyone can copy a certificate, only the key's holder can produce this signature.
5. Finished. Each side sends a MAC over the whole handshake, so tampering with any earlier message is detected.

Between steps 3 and 5 the client checks the certificate:

• The chain. Each certificate is signed by the next, up to a root CA already in the client's trust store. Servers send the intermediates; roots are never sent, because a root is only worth anything if the client already has it.
• The dates. Now must fall between notBefore and notAfter. Publicly trusted certificates are short-lived on purpose: 200 days at most since March 2026, falling to 47 days by 2029, and ACME clients such as Let's Encrypt's renew them automatically.
• The name. The name the client asked for must appear in the Subject Alternative Name extension. Modern clients ignore the old Common Name field.

If any check fails, the client stops before sending a single byte of the request.

What it looks like on a Linux machine

In the TLS certificates lab curl -v prints the handshake and the certificate it checked:

$ curl -sv https://shop.lab/
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
* Server certificate:
*  subject: CN=shop.lab
*  start date: Oct 10 18:03:59 2026 GMT
*  expire date: Jan  8 18:03:59 2027 GMT
*  subjectAltName: host "shop.lab" matched cert's "shop.lab"
*  issuer: CN=Lab Issuing CA
*  SSL certificate verify ok.

openssl s_client -connect shop.lab:443 -servername shop.lab shows the chain as the server sent it, one entry per certificate with its subject (s:) and issuer (i:). openssl x509 -noout -text decodes a certificate file, and openssl req makes a key and a certificate signing request.

What goes wrong, and how you see it

Every certificate warning is one check failing. curl reports them all with exit code 60:

curl: (60) SSL certificate problem: unable to get local issuer certificate
curl: (60) SSL certificate problem: certificate has expired
curl: (60) SSL: no alternative certificate subject name matches target hostname 'staging.lab'
curl: (60) SSL certificate problem: self-signed certificate

Unable to get local issuer certificate most often means the server sends its certificate without the intermediate. Browsers that cached the intermediate elsewhere work, while curl, apps and some phones fail: the fix is to configure the full chain on the server. Expired means the renewal did not run, or the client's clock is wrong; a device with a bad clock finds every site broken. No alternative name matches is a certificate for another name, often production's copied to staging. Self-signed is a printer or router that signed its own certificate.

curl -k skips all of this. The connection is still encrypted, but to whoever answered, which protects nothing against a machine in the middle. The ARP spoofing lab and the DNS spoofing lab show the check doing its job: a lie in DNS sends the laptop to the wrong server, and TLS refuses it because that server cannot prove it holds the key.

Questions people ask

What is the difference between SSL and TLS? SSL was the protocol's name until version 3.0; TLS 1.0 succeeded it in 1999. Every SSL version and TLS 1.0 and 1.1 are deprecated. People still say "SSL certificate".

Does HTTPS hide which site I visit? It hides the path, the headers and the content. The server name still travels in clear in SNI, and DNS lookups and the server's IP address reveal it too, unless encrypted DNS and Encrypted Client Hello are used.

What is an intermediate certificate? A CA certificate between the root and the server's. Roots stay offline and sign intermediates, which sign servers' certificates, so a compromised intermediate can be revoked without replacing the root in every trust store.

See it on real machines