The Private Key Nobody Kept

A certificate that will not install

The site is moving to a new host, or the old server is being rebuilt. The new host asks for the security certificate, and someone finds the email it arrived in, with the certificate attached.

The host replies that the certificate alone is not enough. They need the private key that goes with it.

Nobody has it. It was created on the old server when the certificate was ordered, two years ago, and it never left.

Without it the certificate cannot be installed anywhere, though it has a year left to run.

How the pieces fit

• The private key, created on the server and kept secret.
• The signing request, made from the key and sent with the order.
• The certificate, issued by the certificate authority from that request.
• The intermediate certificates, linking yours to one that browsers trust.
• The account where the certificate was bought and can be reissued.

The first is the only one that cannot be downloaded again. The certificate authority never sees your private key, so it cannot send a copy; the rest can be fetched from the order at any time.

Why the key matters

The certificate contains a public key. Browsers use it to set up an encrypted connection that only the holder of the matching private key can complete.

That pairing is the point. Anyone can copy your certificate, since browsers download it on every visit; only the key proves the server is really yours.

So the key has to be kept, and kept private. A copy sitting in an email inbox or on a shared drive defeats the purpose.

Where the key lives

On most hosting accounts with a control panel, the key was generated in the panel's SSL section when the signing request was made, and it is stored there, inside the account.

On a Windows server it sits in the server's certificate store. It can be exported with the certificate as one password-protected file, if it was marked as exportable when created.

Wherever it is, it disappears with the account or the server. Closing the old hosting account before the move is finished is the usual way it is lost.

When it is needed

The key is needed whenever the same certificate has to be installed again: on a new host, on a rebuilt server, or on a second server that shares the load.

It is not needed for a renewal. Renewals are normally done with a fresh key and a new signing request, which is good practice anyway.

So the problem shows up mid-term, during a move, when everyone is busy with something else.

Keeping a copy safely

When a certificate is installed, export the key and certificate together into a password-protected file. Store it where the business keeps its other important passwords, never in email.

Record the details beside it: the names the certificate covers, where it was bought, the account login, the order number and the expiry date.

Limit who has it. Anyone holding the key, together with the certificate anyone can copy, could pass a server off as yours for as long as the certificate runs.

Reissuing when it is lost

A lost key does not mean buying the certificate again. Most certificate sellers allow a reissue, sometimes called a rekey, usually at no charge while the certificate is valid.

On the new server, generate a new key and signing request, submit the request through the original order, complete the validation again, and install the certificate that comes back.

Domain validated certificates usually come back within hours. Organisation and extended validation certificates take longer, because the seller checks the business again.

Once the new one works, ask the seller to revoke the old certificate if the old key might have been copied anywhere.

A worked example

A kayak builder makes cedar-strip sea kayaks to order in a workshop behind his house, and sells plans, kits and fittings through an online shop with its own checkout.

The shop had an organisation validated certificate, bought through the original host's control panel. Last winter he moved to a new host and closed the old account the day the new site went live.

The new host asked for the private key. It had been generated in the old account, and the account was gone.

For four days the shop took orders by phone while the certificate was reissued, because an organisation validated certificate meant the seller had to confirm the business again.

The key and certificate now sit in a protected file with the business's other important passwords, beside the seller, the order number and the expiry date.

On the next move, the old account stays open until the certificate works on the new server.

Certificates bought by someone else

A certificate bought by a host or developer may sit in their account, not yours. A reissue then needs their help.

Ask now, before any move, where your certificate was bought and in whose name. If it is someone else's account, ask for it to be transferred or plan to buy your own at renewal.

The domain and the certificate belong to the business, and so should the accounts that control them.

A reissue fixes old signatures too

Certificates using the older SHA-1 signature already bring warnings in Chrome if they expire after this year, and sellers stop issuing SHA-1 certificates after December 31.

A reissued certificate normally comes with the newer SHA-2 signature, so check which kind you have while you look for the key.

The counter-case

A certificate due for renewal within a month or two can simply be replaced: order the renewal for the new server with a fresh key, and skip the search for the old one.

And a host that manages certificates for you, generating and renewing them in its own systems, may handle the key entirely. The question then is whether you can get a copy if you leave.

For everyone else: find the key now, keep it safely with the order details, and reissue cleanly if it cannot be found.

Before the next move

1. Find where the key lives today.
2. Export the key and certificate into a protected file.
3. Store it with the business's important passwords.
4. Record the seller, order number and expiry date.
5. Check the certificate uses a SHA-2 signature.
6. Keep the old account open until the move is tested.
7. Reissue with a new key if it is lost.

Step six is what prevents the problem. A key is almost never lost while the old server still exists; it is lost on the day someone closes the account a little too early.

The server settings that sit alongside the certificate are covered in FREAK and the old encryption settings on your server.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.