CertKit
Abstract
Turns out the scariest thing about SSL certificates isn’t when they expire. It’s when they don’t.
I wrote about the CA/Browser fight that led to the 47-day certificate mandate. CAs crying about lost revenue, browsers flexing their root program authority, enterprises stuck in the middle.
But nobody talks about the security research that started it all: BygoneSSL at DEFCON 2018.
Two researchers mining Certificate Transparency logs found something surprising. When domains change hands, the old owners keep their certificates. Still valid and still trusted. Over 1.5 million domains with stale “bygone” SSL certificates.
These domains came from startups that pivoted. Projects that got sold off. Subdomains delegated to vendors. Expired domains someone else bought. All with valid certificates owned by someone else.
This is why we’re getting 47-day certificates. Not because browsers hate us. Because certificates that last years are fundamentally broken when domains change hands in months.
The Stripe problem that should scare everyone
Stripe (the payment processor) bought stripe.com in 2010. Started processing payments. Built the payment infrastructure for half the internet.
The previous owner’s certificate was valid until 2011.
For an entire year, someone else had a perfectly legitimate SSL certificate for Stripe’s payment processing. Trusted by every browser. No warnings. No errors. Just a valid cert for someone else’s billion-dollar payment system.
They didn’t use it. But they could have.
This wasn’t a Stripe’s screwup. Nobody thought about old certificates when they start a new project. It wasn’t on anyone’s checklist to revoke the old certificates. BygoneSSL found them everywhere: Big companies, small companies, that side project you sold last year. All vulnerable to the same temporal trust problem.
Certificate validation checks if you control the domain right now. Not if you’ll control it next year. Or if you controlled it last year. Just now.
Then it gives you a certificate that lasts for years. And that’s the problem.
What BygoneSSL actually found
Ian Foster from UC San Diego and Dylan Ayrey (now CEO of Truffle Security) did what security researchers do. They were curious about how things worked. They analyzed 3 million random domains. Just a 1% sample of the internet. The results:
-
0.45% had valid certificates owned by previous owners. Extrapolating that out, 1.5 million domains globally where someone else has your keys.
-
2.05% shared certificates with bygone domains. Those multi-domain certificates everyone uses? If one domain changes hands, the new owner can revoke the entire certificate. Seven million domains vulnerable to denial of service.
-
41% of these certificates were still valid. Not expired. Not revoked. Just floating around. Waiting.
CDN certificates were the worst. One cert with 700 domains. One bygone domain on that list means one person can kill service for 699 other sites. With a single revocation request. That’s a massive Denial of Service attack waiting to happen.
Here’s the weird part. No documented attacks. No CVEs. No breach notifications.
Foster and Ayrey dropped this research at DEFCON. Released detection tools immediately. CertGraph to map certificate relationships. BygoneSSL scanner to find vulnerabilities. Modified CertSpotter for continuous monitoring.
Free tools. Open source. Available before any bad actors could weaponize the research.
The security community ran with it. Started scanning. Started fixing. Started freaking out about what they found.
But the CAs? They called it theoretical. A non-issue. Nothing to worry about.
Right. Tell that to the 1.5 million vulnerable domains.
Why revocation doesn’t save you
You might think: “Just revoke the old certificates when domains change hands.”
Yea, revocation doesn’t actually work. It’s been broken for years. OCSP checks fail open. Browsers cache responses for days. CRLs are too big to download. Chrome doesn’t even check revocation for most sites anymore.
Even if revocation worked perfectly, who’s tracking which certificates to revoke? The previous owner who sold the domain? They’re gone. The new owner? They don’t know what certificates exist. The CA? They have no idea the domain changed hands.
The only reliable way to kill a certificate is time. Let it expire naturally.
That’s why shorter certificates matter. Not for convenience. For security.
With three-year certificates, a domain could change hands and the old owner keeps cryptographic authority for up to three years. Add domain validation reuse periods and you get 4.5 years of exposure.
With 398-day certificates (what we have now), it’s better but still bad. About two years of vulnerability.
With 47-day certificates? Maximum exposure drops to 57 days. Domain changes hands on Monday. By the end of next month, old certificates are already dying. Zane Ma quantified this in 2024. His research showed 45-day certificates would reduce domain takeover attacks by 95%.
That’s why we are getting 47 day certificates.
Your certificates are everywhere
Check your Certificate Transparency logs sometime. You can use our free Certificate Transparency Log search. Count how many certificates exist for your domains.
Now think about where they all came from:
- That marketing agency you worked with two years ago
- The CDN you tried and abandoned
- Your previous hosting provider
- That contractor who set up your staging environment
- The vendor who managed your subdomain
- Your predecessor at the company
Every one of them might still have valid certificate for your domain. Right now. Especially if you have any multi-domain certificates.
What if your company sold off one of those domains?
This isn’t paranoia. It’s the reality of how WebPKI works.
Certificate management is now a requirement.
BygoneSSL didn’t replace the old problems. It added new ones.
You still need to prevent downtime. Certificates still expire. Sites still go down. The CEO still notices before you do.
But now? Now you also need visibility into certificates you didn’t even know existed.
That spreadsheet tracking expiration dates? You still need something like that. But it’s not enough anymore. Doesn’t show you the certificate your former vendor still has. Or the one issued to that subdomain you forgot about. Or the 15 certificates in CT logs that you definitely didn’t request.
Manual processes were already failing at the basics. Now they’re completely outmatched.
You need automated renewal. Obviously. 47-day certificates mean monthly rotations.
But you also need discovery. To find certificates you didn’t issue.
And monitoring. For the things that go wrong.
Used to be you just worried about your own certificates expiring. Now you worry about everyone else’s certificates not expiring.
Fun times.
What happens next
March 2026: Maximum certificates drop to 200 days.
March 2027: 100 days.
March 2029: 47 days.
The timeline’s set. Automation is mandatory now. The certificate that wouldn’t die is finally getting an expiration date that matters.
Time to make sure you’re ready.
CertKit automates certificate management because BygoneSSL proved that manual processes are a security vulnerability. Not because we love certificates. Because ignoring them is no longer an option.