Private keys (.pem) on a web server: how it happens
The worst file to leave reachable
Most exposed-file findings are uncomfortable. A reachable private key is in a category of its own. A private key — typically a .pem or .key file — is the secret half of a cryptographic pair. Depending on what it is for, it can decrypt your TLS traffic, authenticate as your server over SSH, or sign data as you. If someone can download it, they can be you. So how does something this sensitive end up at a public URL? Almost never on purpose.
How a key ends up served
It is rarely one big mistake. It is a chain of small, reasonable steps:
- Generated in the wrong place. You create a certificate and its key right inside the project folder to get TLS working, then deploy the whole folder — key included — to a server that serves it.
- Copied next to the app. A key gets placed alongside application files for convenience, and the application directory happens to be the web root.
- Committed and shipped. The key lands in version control, and a later deploy copies the repository contents into a public directory.
- Backup leftovers. A
server.key.bak,id_rsa, or an archived config bundle with a key inside gets left in a downloads or backups folder that is reachable.
In every case the file itself is fine — the problem is purely where it can be reached from.
Why bots find it before you do
Automated scanners do not guess randomly. They request a long list of well-known sensitive paths and filenames on every site they hit — and private-key names are near the top of that list. Common filenames like privkey.pem, server.key, id_rsa and .pem variants are checked constantly. A key left reachable is typically discovered by automated crawling long before you would notice anything unusual in your logs.
What to do if a key is exposed
Treat it as compromised the moment it was reachable, even briefly:
- Remove it from anything web-accessible. Move it out of the served directory entirely — keys belong outside the web root, with tight file permissions.
- Rotate it. Generate a new key pair and reissue the certificate, SSH key or signing key. The old one is burned.
- Revoke the old certificate if it was a TLS key, so a stolen copy cannot keep being used.
- Check for misuse in access and auth logs for the window it was exposed.
Confirm nothing sensitive is reachable
The trouble with exposed keys is that everything looks normal from your homepage — the file sits at a path you never link to. An automated scan requests the paths a bot would and tells you if a private key, backup or config file is reachable. Scan your site and make sure your keys are where attackers cannot reach them.