TLS and certificates

Every https:// address runs on TLS (Transport Layer Security). It encrypts the data, detects changes to it and proves that the server is who it claims to be. Most web traffic, most API calls and many database connections use it. You may rarely write TLS code, but you will configure it, terminate it and get paged when it breaks. An expired certificate is one of the most common causes of full outages, and "TLS handshake failed" is an error you will see often.

The big idea: two jobs

TLS does two things, in sequence.

1. Agree on keys. The client and the server use the handshake to create a shared secret key. The key is made fresh for each connection, so an eavesdropper cannot learn it.
2. Prove identity. The server presents a certificate, which is a signed statement that binds its public key to a hostname. The client checks the signature by following a chain back to a root it already trusts.

Both jobs depend on the same idea. A signature from a trusted issuer is hard to forge, and a fresh key is hard to steal. If either one fails, the connection should be refused.

Concepts in this section

Read them in this order.

In practice

• Never disable certificate checks to make an error go away. Turning off verification removes the authentication. Fix the chain, or add the right CA.
• Automate renewal and monitor expiry separately. Certificate lifetimes are shrinking toward 47 days, so renewal by hand will not keep up.
• Know where TLS ends in your system, and what is plaintext after that point.
• Use TLS 1.2 as the minimum and prefer TLS 1.3. Turn off TLS 1.0 and 1.1, which browsers stopped supporting in 2020.
• Use mTLS with short-lived identities for traffic between services, instead of shared API keys.
• Test from the command line. openssl s_client -connect host:443 -servername host shows the chain the server actually sends. A browser can hide problems that other clients will hit.

Common mistakes

• Trusting a browser test alone. A missing intermediate certificate often works in Chrome and fails in scripts.
• Renewing on the last day. One failed attempt then becomes an outage.
• Assuming encryption is enough. Without the certificate check, a man in the middle can read everything.
• Forgetting internal certificates. Internal CAs and mTLS certificates expire as well.

Key takeaways

• TLS agrees on fresh keys with the handshake, and it proves identity with a signed certificate.
• TLS 1.3 needs one round trip for the handshake. Connection reuse makes the cost mostly one-time.
• A certificate is trusted through a chain of signatures from a root the client already has.
• Expiry is intentional, and it is the main safety net. Automate renewal and monitor expiry from outside.
• Use openssl s_client to check the chain, and use mTLS with short-lived identities between services.

Further learning

Practical Networking's video goes message by message through opening an HTTPS site, including certificates and key derivation. It pairs well with the handshake page.

Cloudflare: What happens in a TLS handshake?cloudflare.com