TLS Certificates and Private Keys Explained

Every time you visit an HTTPS website, your browser and the server perform a TLS handshake that establishes a shared encryption key for the session. Central to that handshake is an asymmetric key pair: a certificate that is shared publicly, and a private key that never leaves the server. Understanding how these work together — and why the private key is so sensitive — matters any time you operate or deploy a service over the web.

What TLS does

TLS (Transport Layer Security) provides three things on a connection:

• Confidentiality — data is encrypted in transit so intermediaries cannot read it.
• Integrity — data cannot be modified in transit without detection.
• Authentication — the client can verify it is talking to the genuine server, not an impersonator.

Authentication is where certificates come in. The certificate allows the server to prove its identity. Without it, an attacker could intercept the connection, present their own key, and read all traffic — a man-in-the-middle attack.

The certificate

A TLS certificate is a digitally signed document that binds a public key to an identity (a domain name). It contains:

• Subject — the entity the certificate belongs to, typically a domain or a set of domains (Subject Alternative Names).
• Public key — the server's public key, which clients use to verify signatures and encrypt data during the handshake.
• Issuer — the Certificate Authority (CA) that signed the certificate.
• Validity period — not-before and not-after dates. Let's Encrypt issues 90-day certificates; commercial CAs typically issue 1-year certs.
• Signature — the CA's digital signature over all of the above, which allows clients to verify the certificate is genuine.

Certificates are stored as PEM files — ASCII text with a -----BEGIN CERTIFICATE----- header — and are safe to distribute publicly. Your web server sends the certificate to every client that connects.

The private key

The private key is the other half of the asymmetric key pair. It is mathematically linked to the public key embedded in the certificate, but cannot be derived from it. During the TLS handshake, the server uses the private key to prove ownership of the certificate — specifically, to sign a value that the client can verify against the public key in the cert.

Private keys are also stored as PEM files (-----BEGIN PRIVATE KEY----- or -----BEGIN EC PRIVATE KEY-----), but they must never be shared. Anyone who obtains your private key can impersonate your server — intercepting encrypted traffic appears legitimate to clients because they cannot distinguish your server from the attacker's.

Certificate chains and trust

Browsers and operating systems ship with a built-in list of trusted root Certificate Authorities — organizations like Let's Encrypt, DigiCert, and Sectigo that have been vetted. Your server's certificate is not signed directly by a root CA; instead, it is signed by an intermediate CA, which is signed by the root. This chain of signatures is called the certificate chain or chain of trust.

When your server serves a TLS connection, it should send the certificate chain — your certificate plus any intermediate certificates — so the client can walk the chain up to a trusted root. Missing intermediates are a common misconfiguration that causes certificate errors on some clients even when the certificate itself is valid.

Protecting the private key

• Never commit it to source control. Treat *.key and *.pem private key files the same as passwords.
• Restrict file permissions. On Linux, private key files should be readable only by the web server process: chmod 600 server.key.
• Use a passphrase for stored keys. Encrypting the key file at rest means a stolen file is not immediately usable. Automated systems that need to load the key at startup typically store the passphrase in a secret manager rather than leaving it unencrypted.
• Consider HSMs for high-value keys. A Hardware Security Module stores the private key in tamper-resistant hardware and performs signing operations without the key ever leaving the device.
• Automate certificate renewal. Short-lived certificates (Let's Encrypt's 90-day model) limit the exposure window if a key is compromised. Tools like Certbot and cert-manager handle renewal automatically.
• Revoke immediately if compromised. If the private key is ever exposed, revoke the certificate through your CA and reissue with a new key pair. Do not reuse the same private key after revocation.