An RSA private key is one half of a key pair, and what it can do depends on the job it was given. It can prove a server’s identity to browsers (a TLS certificate), sign tokens (JWT with RS256), sign code or software releases, authenticate a GitHub App, or decrypt data meant for you. The same file format is used for all of them, so the first task is to work out which one you are dealing with. This page covers those cases. If the key is for logging in to servers, go to the SSH private key guide instead.
Check your GitHub account for leaked secrets — free
- Provider
- Other
- Severity
- Critical
- Impact
- Source code and build access
- Checked live by LeakWatch
- Yes
What an RSA private key looks like
An RSA private key is a text file in PEM format that begins and ends with a marker line:
-----BEGIN RSA PRIVATE KEY----- RSA, traditional PEM format
-----BEGIN PRIVATE KEY----- PKCS#8, any algorithm, including RSA
-----BEGIN ENCRYPTED PRIVATE KEY----- PKCS#8 protected by a passphrase
Between the markers is a block of base64 text; this page never shows one, and neither should you paste one anywhere. The matching public key (BEGIN PUBLIC KEY, or a certificate) is safe to share. A certificate file (BEGIN CERTIFICATE) is public too; it is the file next to it, often named privkey.pem, server.key or private.pem, that matters.
The marker alone does not tell you the use. To find out, look at the file name, the folder it came from and the code that loads it: a web server configuration points to a TLS key, an authentication library to a signing key, and a GitHub App to a key downloaded from its settings page.
How RSA private keys get leaked
- Web server and container configs. A
privkey.pemcopied next to a Dockerfile, a Kubernetes manifest or a Helm chart, then committed. - Token-signing keys in application code. A key generated to sign JWTs, embedded in a configuration file or a test fixture, then kept when the project went public.
- Downloaded app credentials. The
.pemfile a platform gives you when you create an app, left in the project folder. - Backups and archives. A zipped project folder or a server backup pushed to a public repository or bucket.
- Pasted for help. In an issue, a chat or a forum post, while asking why a certificate or a signature fails.
What to do in the first hour
- Identify the use. Search your code and configuration for the file name. A TLS key, a signing key and an app credential are revoked in three different places.
- TLS certificate key. Ask the certificate authority to revoke the certificate that goes with it, then issue a new certificate with a new key. With an ACME client, such as Let’s Encrypt’s, revoke through the client and request a fresh certificate. Reusing the old key for the new certificate defeats the purpose.
- Token-signing key. Generate a new pair, publish the new public key, and stop accepting the old one. Every token signed with the old key must be treated as untrusted, so expect to log users out. See the JWT guide.
- App credential. In the platform that issued it, such as a GitHub App’s settings page, delete the key and generate a new one. Then update the application that used it.
- Code-signing or release key. Contact the authority that issued the certificate, revoke it, and re-sign what you shipped with a new key. If users trust the old key, tell them to stop.
- Decryption key. Assume anything encrypted to the matching public key has been exposed, including past messages and backups. Generate a new pair, re-encrypt what you can, and rotate the secrets inside.
- Generate the replacement with a passphrase where the software supports it, and store it in a secret manager, not in the repository. Then remove the file and clean the history. See I accidentally pushed an API key to GitHub.
Not sure what else leaked from the same repository? Run a free scan.
Revoke it at the places that trust the key
An RSA key has no issuer of its own, so you revoke it by removing trust wherever the public half is used. For a certificate, that is the certificate authority. For a signing key, it is every service that verifies signatures with the public key. For an app credential, it is the platform’s settings page. There is no central list to query; the public key, or its fingerprint, is your search term. If you still have the private file, openssl rsa -in <file> -pubout prints the matching public key and lets you search for it.
How LeakWatch detects it
The rule is called Generic/RSA/SSH Private Key. It matches a block that starts with a BEGIN … PRIVATE KEY marker and ends with the matching END marker, with the severity set to critical. The same rule serves the SSH guide, because the format is shared. LeakWatch analyzes the key itself, offline, to tell a real key from a template or a truncated block, and to see whether a passphrase protects it. It cannot test the key against a server: a private key is proof of possession, and using it would mean acting as its owner. So it can tell you that the key is exposed, not what it still opens. Assume it opens everything it was used for until you have revoked it.
LeakWatch can check whether a detected key is still active with a read-only request to Other. It never reads your data or spends your credits.
FAQ
The key is protected by a passphrase. Is it still a leak?
Yes, but a less urgent one. The attacker has to guess the passphrase offline first, and a long random one makes that impractical. A weak one will not hold for long. Rotate the key either way, since you cannot know how strong the passphrase really is.
How do I know if it is a TLS key or an SSH key?
Look at where it was used. A key that a web server loads next to a certificate is a TLS key; a key in ~/.ssh or authorized_keys is an SSH key. If you cannot tell, treat it as both and check every system that trusts the matching public key.
Can I keep the same key and only change the certificate?
No. The exposed key is the problem, not the certificate. A new certificate for the same key is just as exposed. Generate a new key pair and issue the new certificate for it.