Compromised Private Keys and SSL Certificate Revocation
Robert KimShare
A Private Key is the one part of an SSL Certificate that only you hold. It proves your website is genuinely yours, and it is never sent to Trustico® or to the Certificate Authority (CA).
If someone else obtains a copy, they can impersonate the website your SSL Certificate protects, and they can do so while presenting a valid SSL Certificate that browsers accept without complaint.
That is why a suspected exposure is treated as an emergency rather than a maintenance task. This article explains how to tell whether you have a problem, which of two very different paths applies to you, and what each one involves.
Lost Keys and Exposed Keys Are Different Problems
Almost every worried customer falls into one of two situations, and the correct response is not the same for both.
A Private Key is lost when you no longer have it, but nobody else has it either. A file deleted with no backup, a rebuilt server, or a decommissioned machine that was securely wiped are all losses. Nothing has been exposed.
A Private Key is compromised when someone else may hold a copy, whether or not you can prove it. A stolen laptop, a backup on a misplaced drive, a key committed to a code repository, or a server breach all count.
Note : A lost Private Key needs a reissue and nothing more. A compromised Private Key needs revocation as well, because the old SSL Certificate stays valid and usable in the wrong hands until it is revoked.
Where the two are hard to separate, treat it as a compromise. Reissuing costs nothing and revoking costs nothing, so the cautious choice carries no penalty beyond a little of your time.
Recognizing Possible Private Key Exposure
Compromise is rarely announced. In most cases there is no alert and no obvious symptom, so it is identified by reasoning about access rather than by detecting an intrusion.
Ask who could have reached the key rather than who did. Any answer beyond the people who should have reached it is enough to act on.
Circumstances That Warrant Action
A security incident on the server where the key is stored, or on any machine it was ever copied to, is the clearest case. So is a breach of a backup system, since backups frequently contain key material that people forget is there.
The departure of a staff member or contractor who held the key matters just as much, and this is the case most often overlooked. Access does not end with employment, and a copy taken earlier remains usable.
Keys handled carelessly are a category of their own. A key sent by e-mail, stored in a shared drive, pasted into a support ticket, or committed to a version control repository should be considered exposed even when the destination seems private.
Hardware that leaves your control without being wiped belongs here too, including a stolen laptop, a returned leased server, or a disk sent for repair. Learn About Where Private Keys Are Stored 🔗
Weak Keys and Generation Faults
A key can also be unsafe without anyone having taken it. A key generated by faulty software, produced with insufficient randomness, or created at a length no longer considered adequate may be computable by an attacker from the public information in your SSL Certificate.
Regulations treat this identically to theft. Where a method exists that computes the Private Key from the public key, the SSL Certificate must be revoked. Learn About Generating Keys Securely 🔗
What the Regulations Require
Revocation timelines are not set by Trustico® or by any individual Certificate Authority (CA). They are fixed by the CA/Browser Forum Baseline Requirements, which every publicly trusted Certificate Authority (CA) must follow.
A confirmed key compromise falls in the fastest category. So does a request from the subscriber, an issuance that was never authorized, and a case where control of the domain name can no longer be confirmed. Each of these must be revoked within 24 hours.
Other categories, such as inaccurate information recorded in the SSL Certificate, carry a five day window. Compromise is never in that slower group.
Important : The 24 hour clock begins when the Certificate Authority (CA) has what it needs to act, not when you first suspect a problem. Reporting promptly is the part of the timeline within your control.
Nothing about that timeline requires you to have proof. A credible suspicion reported quickly is worth more than certainty reached slowly.
Notifying Trustico®
Contact Trustico® as soon as you suspect exposure. Describe what happened, which SSL Certificate is affected, and how you believe the key was reached, as that detail is what allows the request to be acted on rather than queried.
Have your Certificate Authority (CA) Reference to hand, since it identifies the specific SSL Certificate rather than the order it was purchased on. Learn About The Certificate Authority (CA) Reference 🔗
Trustico® aims to respond to an enquiry within 24 to 48 hours across every contact method, and there is no fee for revoking an SSL Certificate under any circumstances. Contact The Trustico® Team 🔗
The Certificate Authority (CA) that issued your SSL Certificate also remains contactable directly through its own website. Contacting Trustico® first is recommended, because the license and the order history are held here.
Reasons Revocation Remains Manual
Revocation is deliberately handled by people rather than by a button in the tracking system or a call to an Application Programming Interface (API).
The reason is that revocation cannot be undone. An SSL Certificate revoked in error, or revoked by somebody acting without the permission of the license holder, takes the website offline for every visitor until a replacement is issued and installed.
Requiring a conversation removes an entire category of accidental and malicious outages, at the cost of a short delay that the regulations already accommodate.
Replacing the SSL Certificate
Your license is unaffected by any of this. Revocation ends one issued SSL Certificate, not your entitlement, so a replacement is issued at no charge for the remainder of the license period.
Generate a completely new Private Key and a new Certificate Signing Request (CSR) on the server where the SSL Certificate will be installed. Reusing the old key would carry the compromise straight into the replacement. Learn About Creating a Certificate Signing Request (CSR) 🔗
Submit the reissue through the tracking system in the usual way, or ask the Trustico® team to handle it alongside the revocation. Learn About Requesting a Reissue 🔗
Order the two steps deliberately. Requesting the replacement first, then revoking once it is installed, keeps the website reachable throughout, which matters when the exposure is suspected rather than confirmed.
Warning : Where you know the key is in someone else's hands, revoke immediately and accept the interruption. A brief outage is a smaller problem than an attacker holding a working SSL Certificate for your domain name.
Either order leaves you with a working SSL Certificate on a key nobody else holds. The difference is only whether you accept a short interruption to close the exposure sooner.
Consequences for the Revoked SSL Certificate
Revocation does not delete anything or reach into your server. The SSL Certificate file continues to exist and will still be served by your web server until you replace it.
What changes is that browsers are told not to trust it. Visitors then see a security warning rather than your website, which is precisely the outcome you want for an SSL Certificate an attacker may be holding. Learn About How Revocation Reaches Browsers 🔗
Because revocation is not instantaneous everywhere, installing the replacement remains your responsibility and should not wait for the revocation to propagate.
Preventing Future Exposure
An exposure is a reasonable moment to look at how keys are handled rather than only at the one that went wrong.
Keep every Private Key on the server that will use it, generated there and never transmitted. A key that has never travelled cannot be intercepted in transit or left behind in a mailbox.
Restrict file permissions so that only the account running the web server can read the key, and confirm that backups either exclude key material or are themselves encrypted and access controlled.
Replace keys when the people with access change, in the same way passwords are changed when someone leaves. Reissuing is free and unlimited within the license period, so nothing prevents this from becoming routine.
Shorter SSL Certificate validity periods already force regular replacement, which makes key rotation a natural part of an existing cycle rather than an additional task. Learn About Managing Shorter Validity Periods 🔗
Acting on a suspicion costs you nothing but a little time, while leaving a compromised key in place leaves a working SSL Certificate for your domain name in someone else's hands.
