Abstract
A few months ago I wrote about BygoneSSL and the 1.5 million domains with valid certificates owned by someone else. Domains change hands but certificates don’t know. The old owner keeps their private key, and the certificate keeps working.
It’s an industry problem, but it turns out it’s our problem too.
We purchased certkit.dev for internal development and demos. I randomly used it as an example for our Certificate Transparency log search and found a valid certificate issued by DigiCert.
Still valid for another 100 days.
Someone we’ve never met holds a private key for one of our domains.
How worried should we be?
Honestly? Not very. At least not in this case.
For someone to actually exploit this, they’d need to man-in-the-middle our traffic with this old certificate. We weren’t running anything sensitive on certkit.dev. It’s a dev domain. And thanks to Perfect Forward Secrecy, even if someone had the private key, they couldn’t decrypt any previously captured traffic. The key only helps you impersonate, not eavesdrop on the past.
The realistic risk to us is close to zero.
But that’s for a small dev domain nobody’s targeting. Now imagine this is your payment processor, like Stripe. The original BygoneSSL research found this exact situation on stripe.com, where someone held a valid certificate for a payment processing domain for over a year after the sale. Same vulnerability, very different stakes.
The uncomfortable truth is that this is incredibly common. The research found that 7% of all domains have valid certificates owned by previous owners.
Trying to get it revoked
So we have a BygoneSSL problem. Now what?
I didn’t issue this certificate and I don’t have a DigiCert account. I have no relationship with whoever owned certkit.dev before us. But I do own the domain now, and there’s a certificate out there that I’d like to not exist.
DigiCert’s documentation has an email address for exactly this situation: revoke@digicert.com. I sent them a clear request with the SHA256 fingerprint and serial number, explained that the organization no longer owns this domain, and asked what validation they’d need from me.
The first response came two hours later, addressed to “Tobb”, asking me to add a note under “this Order” so they could revoke the certificate.
What order? I don’t have an account. I didn’t place an order. That’s the entire point of this email. Someone else ordered this certificate for my domain.
I wrote back explaining the situation. This time DigiCert understood and gave me steps to validate that I owned the domain. Once complete, they said it would be revoked “shortly”.
From first email to revocation approval: about 4 hours across 6 emails. Not terrible once a human understood what I was asking. But the first response was a support agent reading from a script that assumed I was the certificate holder, not the domain owner. If I hadn’t known exactly what to ask for, or had given up after being told to log into an account that doesn’t exist, that certificate would still be sitting there untouched.
Certificate revoked, in theory
DigiCert said the certificate would be revoked “shortly.” So I checked.
It took about 24 hours for the certificate to be revoked on the Digicert’s OCSP and CRL. But as of this writing (72 hours later), the certificate is still trusted by every browser on the planet.
This is certificate revocation in practice. You can do everything right. Find the stale certificate. Contact the CA. Prove you own the domain. Get confirmation that revocation is happening. And the certificate keeps working anyway because the revocation infrastructure is held together with duct tape and good intentions.
Even when revocation eventually propagates to the CRLs, Chrome still only checks its own curated CRLSet covering a fraction of revoked certificates. Firefox’s CRLite updates on a delay. Safari does its own thing. Whether any given browser actually rejects this certificate after revocation depends on which browser, which revocation list, and when they last updated.
This is why certificate lifetimes are shortening
The industry knows this problem exists. Revocation has been broken for years and nobody has a realistic plan to fix it. Their answer is shorter certificates. Under the 47-day certificate timeline coming in 2029, maximum exposure from a domain ownership change drops from over a year to weeks.
Under 47-day lifetimes, our certkit.dev certificate would have expired before I even finished the domain purchase. Instead I spent an evening emailing back and forth with a CA, proved I own my own domain, got a confirmation, and the certificate is still valid in every browser.
47-day certificates won’t fix revocation. But they’ll make it matter a lot less.
What to do when you buy a domain
If you’re acquiring a domain, don’t assume it comes clean. Here’s what we’d recommend.
Search Certificate Transparency logs for the domain before or immediately after purchase. You’ll see every certificate ever issued. If there’s something current that you didn’t request, you know you have a BygoneSSL situation.
Set CAA records on your DNS right away. CAA (Certificate Authority Authorization) records tell CAs which authorities are allowed to issue certificates for your domain. This won’t kill existing certificates, but it prevents new ones from being issued by unauthorized CAs.
File revocation requests with any CA that has outstanding certificates you didn’t authorize. Be prepared for this to be slow and confusing. If it’s a Let’s Encrypt certificate, you can revoke it yourself by proving domain control through ACME. Commercial CAs will make you work for it.
Set up CT log monitoring so you’ll know if anyone issues a new certificate for your domain in the future. This is the one thing you can actually stay on top of.
None of this is hard. But none of it is something anyone thinks about when buying a domain. The registrar doesn’t warn you. The CA doesn’t notify you. You have to go looking, and most people don’t.
CertKit automates certificate lifecycle management. Search your domain’s certificates for free with our CT Log Search tool.
Comments