A certificate request lands in your inbox: a vendor needs your client certificate, a new load balancer needs the wildcard, a colleague needs the signing cert to build a release. The file they are asking for may be harmless or it may be the private key that lets anyone impersonate your service, and the two often travel in the same bundle.
To share a private certificate through a secure link safely, first work out which half is actually needed, package the private key so it is useless without a password, send the file through a one-time link that is destroyed after one download, and send the password somewhere else. This guide walks through each step with the commands.
The certificate is public. The key is not.
A certificate contains a public key, the subject it was issued to, the issuer and the validity dates. It is designed to be handed out; every browser that connects to your site receives it. The private key is the separate secret that proves you own the certificate. Whoever holds it can decrypt traffic meant for you, sign things as you, or stand up a server that claims to be you.
So the first question is whether the recipient needs the key at all.
| The recipient wants to | They need | Sensitive? | | --- | --- | --- | | Trust your service or verify a signature | The certificate (and maybe the CA chain) | No | | Install TLS on a server or device they run | Certificate, chain and private key | Yes | | Sign code or documents as your organisation | Certificate and private key | Yes, highly | | Authenticate to a system with a client cert | Certificate and private key | Yes |
If the answer is the first row, send the .crt or .cer file any way
you like and stop reading. Everything below is for the rows where the
key has to move.
Check what is in the file before you send it
Extensions lie. A .pem may hold a certificate, a key, or both. A
.pfx or .p12 usually bundles certificate, chain and key behind a
password. Inspect before sending:
# what is in this PEM?
openssl x509 -in cert.pem -noout -subject -issuer -dates
grep -c "PRIVATE KEY" cert.pem # 0 means no key inside
# what is in this PFX? (prompts for the password)
openssl pkcs12 -in bundle.pfx -info -noout
Confirm the subject matches what the recipient asked for and the expiry date is in the future. Sending the wrong certificate is common; sending the wrong certificate with its key is a breach.
Package the key so it is useless on its own
If the key must travel, never send it bare. Put it in a format that is encrypted with a password you will send separately.
# bundle certificate, chain and key into a password-protected PFX
openssl pkcs12 -export -out service.pfx \
-inkey service.key -in service.crt -certfile chain.crt
# or encrypt a PEM key on its own
openssl pkey -in service.key -aes-256-cbc -out service.enc.key
Use a long password generated by a password manager. The password is the second factor: someone who obtains the file still cannot use it, and someone who obtains the password has nothing to apply it to.
Send the file through a one-time secure link
The link is the delivery step, and the aim is that no copy of the file remains in any message afterwards.
- Verify the recipient against a source you already trust: the ticket, the vendor contact on file, a call. A certificate request from an unexpected address deserves a phone call, not a reply.
- Create a secret link with the file attached. From a signed-in LinkPilot account, open Secret Links, choose New and attach the PFX or encrypted PEM. Files are limited to 9 MB each, which is thousands of times larger than any key bundle. The attachment is encrypted in your browser before upload and deleted the first time it is downloaded.
- Set the expiry to the real window. An hour if the recipient is waiting, 24 hours across time zones. The single download is the main control; expiry is the backstop for a link nobody opens.
- Set the view limit to one. Two engineers who both need the bundle each get their own link.
- Add a passphrase to the link on a Pro account if it will travel through a channel other people can see.
- Send the link with one line of context: which certificate, which system, when it expires.
- Send the file password by a different channel. A text message, a call, or a second secret link sent by a different route. Never in the same message as the file link, and never in the filename.
If the key is PEM text and small, you can paste it straight into the free secret link tool instead of attaching a file. The text is encrypted in your browser and destroyed on first open in the same way.
Tell the recipient what to do with it
Send the installation notes with the context message, not with the password:
- Which file to expect, its format, and the system it belongs on.
- Where to store it: the server's certificate directory with permissions limited to the service account, or the OS certificate store. Not Downloads, not a shared drive.
- Delete the downloaded copy once imported, and never commit it to a repository.
- Confirm receipt by filename and fingerprint, never by sending the file back:
openssl x509 -in service.crt -noout -fingerprint -sha256
Afterwards
Check that the link shows as revealed and that the recipient confirms the fingerprint matches. Pro accounts can see the audit timeline for the exact time of the download. If the link was opened before the recipient got to it, or the file went to the wrong address, do not wait for evidence of misuse: revoke the certificate with the issuing CA, generate a new key pair, reissue, and replace the certificate everywhere it is installed.
Record who received which certificate and when. Keep the record. The file should exist on the systems that need it and nowhere in between.