Protecting your TLS private key

The TLS private key is the secret half of your site's encryption. Anyone who holds it can impersonate your domain and decrypt traffic, regardless of whether the certificate still looks valid. Keeping it private is therefore a few concrete operational rules, not a background concern.

Why it matters

A TLS certificate is only half the pair. The public certificate is public; the private key must never leave the machine that terminates TLS. If an attacker obtains the private key, they can present a matching certificate and run a man-in-the-middle that browsers validate, because the certificate chain itself is legitimate. This is why a leaked key is treated as a compromise equal to a mis-issued certificate (see the certificate hierarchy guide).

Permissions and access

• Store the private key where only the TLS process and the administrator can read it, and set owner-only read permissions: 0600 on Unix, with 640 used only when a group must read it.
• Keep the key out of source control, build artifacts, backups that leave the server unencrypted, and public config samples. .env-style files and Docker image layers are common leak points.
• Restrict who can read the key, and rotate access when staff leave or a shared host is accessed by others.
• Back up the key only when necessary, and then encrypted, because losing the key means re-issuing the whole certificate.

Check existing exposure

1. Confirm the file permissions on the key path, for example with a privacy-preserving permission check (stat -c %a /etc/ssl/private/example.key in Linux).
2. Search your repositories and public configs for private-key blocks that were pasted for debugging.
3. Verify the key matches the certificate so the running pair is what you intended, since a mismatched key and cert causes handshake failures (see the TLS handshake failures guide).

Suspected compromise

If you have any reason to believe a private key leaked, treat it as compromised and act promptly:

1. Generate a fresh key pair. Never reuse the old key.
2. Reissue the certificate with the new key through your CA. If you use a coordinator like an ACME client, the renewal checklist covers the flow.
3. Reduce reliance on a single key across hosts; a SAN or wildcard certificate concentrates risk, so prefer narrower scopes where practical (see the multi-domain certificate guide).
4. Monitor certificate issuance so a new certificate under a domain you did not request is visible quickly, since that can be a sign someone used a leaked key attempt (see the certificate transparency guide).

The operational guardrails around issuing and renewing certificates, including how to keep a working key pair while rotating it, are covered in the Let's Encrypt guide and the rate limits guide.