When Stripe's SSL Certificate Belonged to Someone Else

In 2010, Stripe bought stripe.com and started building the payment infrastructure that would eventually process billions of dollars. They bought their domain and ordered the SSL certificates.

Except the previous owner of stripe.com still had a valid certificate. Valid for almost 2 more years.

This wasn't a hack or a vulnerability in Stripe's code. The previous owner had a perfectly legitimate certificate issued by a trusted Certificate Authority. Every browser trusted it. No warnings or errors. Just someone else holding cryptographic proof they controlled Stripe's domain. This was just one example from the BygoneSSL research that found 1.5 million domains with the same problem.

Think about what that means for a payment processor.

The attack that could have happened (but didn’t)

Imagine you're a Stripe customer in 2010. You're sending credit card details to stripe.com. HTTPS shows the padlock. Everything looks secure.

But someone else has a valid certificate for stripe.com.

They could run a man-in-the-middle attack. Not through some complex cryptographic break. Not through a zero-day exploit. Just by presenting their legitimate certificate that says "I am stripe.com."

Your credit card number. Your customer's data. Your API keys. All flowing through someone who shouldn't have access but has the certificate to prove they do.

The previous owner didn't do this. We know because Stripe is still here and there wasn't a massive breach announcement. But the capability existed for months.

Who checks if previous domain owners have valid certificates? Nobody. It's not in any security checklist. Not in any compliance framework. Not in any startup playbook.

Certificate Transparency didn't exist until 2013. There was no way to even see what certificates existed for your domain. You could only track the certificates you issued. Not the ones someone else had.

The previous owner probably didn't even realize they still had a valid certificate. Just some files on an old server. A backup someone forgot about. A certificate that wouldn't expire for another year.

Both parties completely unaware of the security nightmare between them.

The payment processor's nightmare scenario

Payment processors are special targets. They're the keys to the kingdom. One compromised payment flow affects thousands of businesses and millions of consumers.

Here's what the previous stripe.com owner could have done:

Passive Collection: Set up a proxy. Pass traffic through to the real Stripe. Collect API keys along the way. Nobody notices because transactions still work.

Selective Targeting: Only intercept high-value transactions. Or specific merchants. Small enough to avoid detection. Large enough to be worthwhile.

Credential Harvesting: Forget credit cards. Collect Stripe API keys. Those are worth more. One API key equals thousands of credit cards.

Trust Destruction: The worst attack wouldn't steal money. It would destroy trust. Leak that Stripe's SSL was compromised for a year. Watch the entire payment industry panic.

None of this required technical sophistication. Just the certificate they already had.

This happens more often than it should

Stripe wasn't unique. The BygoneSSL researchers found this pattern everywhere:

Salesforce.com appeared on multi-domain certificates with domains that changed ownership. One expired domain purchase could have let someone revoke Salesforce's certificate.

Major CDNs had certificates with 700+ domains. Statistically, some of those domains change hands every year. Each transfer is a potential certificate compromise.

Enterprise SaaS platforms with custom domains for each customer. When customers churn, they take the domain. But the certificate lives on.

Domain ownership changes daily but Certificates last for years.

The fix no one wanted

When this research went public, the Certificate Authorities said it was theoretical. No documented attacks. Not a real problem.

But browser vendors did the math. 1.5 million vulnerable domains. Payment processors. Healthcare systems. Government services. All potentially compromised by anyone who previously owned the domain.

So revoke the certificates? Who’s going to make them? Certificate revocation is broken anyway.

The solution was obvious. Shorter certificates.

If certificates expire in 47 days instead of 3 years, the window for abuse shrinks dramatically. A domain changes hands on Monday. By next month, old certificates are already dying.

Certificate Authorities hated this. Shorter certificates mean more renewals. More automation. More work. Less revenue from multi-year certificates.

But the Stripe example shows why it's necessary.

The lesson nobody learned

The BygoneSSL research dropped in 2018. Six years ago. Yet companies still buy domains without checking certificate history. Still issue 398-day certificates. Still assume certificate management is just about preventing expiration.

Stripe got lucky. The previous owner was honest or ignorant. Not malicious.

Your company might not be so fortunate.